Learning through exploration

It seems common for many people wanting to learn a new skill to go through three main phases, deciding what to learn, going through a tutorial on the subject, then deciding it’s too hard and thinking the skill isn’t really the best one for them, and then either giving up, or moving onto a new skill that might be easier to learn.

When I first started programming back in the late 90s’, I too went through these phases, asking myself if I should spend my time learning this programming language or perhaps a different one. Is this really the best way to structure my code, or do I need to do more reading first?

This cycle of self-doubt can debilitate for a lot of newcomers and makes it seem impossible to get past those early stages and onto a level where you feel confident in your abilities with your new tool.

We should all be in a constant cycle of upgrading our skill set to become the best people we can be. And I don’t just include testers in this statement (even though the world that we work in is constantly evolving). But everyone, no matter your industry, job title or background. If we are not learning, then we risk being left behind.

In recent years, I have discovered that applying testing methods to my learning, especially exploratory testing, has really helped to guide my learning from the beginning, to the end, and gives me a greater understanding of the subject.

For those who do not know what exploratory testing is. It is essentially an activity in which testers traverse a piece of software and test out the various functions without a particular test script or test case in mind.

Exploratory testing is usually performed once a test case has been concluded and is sometimes performed in groups with a prize going to the person who finds the most bugs.

Exploratory testing is one of my favourite activities as a tester as it really promotes logical thinking and provides me with the opportunity to learn more about a piece of software through trial and error. Also, it encourages testers to be creative to locate those hidden bugs that are undoubtedly present in the system.

So how can you apply this method to your learning?

What do you want to do with your new skill?

The first step in deciding what to learn should always start with the end goal in the question. Having a goal to work towards will not only make remind you of why you are spending all this time to learn your new skill. But it will also provide you with a motivating factor to think about through the learning process.

Get started

Let’s say your goal is to write a Selenium framework for automating UI checks of your website. But what do you write it in? After a bit of research, you find that there are many languages that can do the job.

Do you choose Java, C#? or Python, maybe? You don’t know how to use any of those… so maybe doing a tutorial on them all and then coming back to this decision in a month would be best…

I’ve written automated checks in all of those languages (examples here, here & here) and I can honestly say that it does not matter what you decide.

It’s probably a good idea with writing automated checks to use the language that the developers write your application in so they can help you with any problems. But if you are learning for learning’s sake, pick one and dive right in.

Now what?

This is where the fun begins! Now the learning takes on a mostly exploratory route where you have an end goal in mind and you know that this tool in front of you will help you get there. But you aren’t sure of the journey you are about to take.

In the instance of a Selenium framework. It’s probably best to start with a simple test and then work back from there. Fleshing out the different parts of the framework and build the layers of abstraction as you go along.

So what I would do is perform a Google search looking for a simple test script that goes to a webpage and clicks on a single button and run that on your own machine.

Seeing something working with your own eyes vs just knowing that it’ll work is quite a powerful thing when you are learning and I can attest that it always helps remind me that what I am setting out to do is possible. I just need to learn more first.

Then after seeing it working, try to break it. Delete a line or two of code, change parts of it around, maybe add some new functionality and instead of clicking on a button. Make the script do something else.

You probably have a nasty error displayed that you do not understand. Ok, so Google that error until you find the solution and can fix the script again.

Now you have something different from the original you copy and pasted from a random website but does what you want it to do.

Now move onto the next bit of the framework you want to add and go through the same process over and over until you are complete.

We can apply this method to anything that we want to learn. What to take-up oil painting? Awesome, get the things you need, then start exploring what you can do. Don’t worry if you are doing it the right way and don’t be discouraged that your friend thinks your sheep looks like a fluffy cat.

Your cutting your own path, exploring what’s possible and learning along the way.

• Category: Software Testing