Software testing, or quality assurance, is the process of evaluating software and comparing what it was supposed to do and what is actually does. To help you understand this concept I created a simple analogy:
In 1987 a legend was born, an arcade game called Street Fighter.
The game became extremely popular, especially after it’s sequel, Street Fighter II, launched in 1991. The reason for its success was the fact that besides having a huge choice of characters to chose from, each character had a repertoire of over 30 individual moves and fighting styles.
The game’s basic moves were assigned to individual buttons, however, special moves required the player to perform specific movement combinations with the controllers, a feature introduced since the original Street Fighter.
Since the internet was not what it is today, there were no wikis or forums for you to look up the special moves of your favourite character. Magazines would publish walkthroughs and cheats, but real players did not rely on such means. So, how did they figure out what commands corresponded to which moves?
Normally when you play fighting games you press a bunch of buttons frenetically trying to do some damage (What? Is that only me?). Sometimes during your frenzy pressing buttons, something cool happens. You then try to remember what sequence of moves you used when it happened. You experiment until it happens again. Now you have a sequence of commands that will result in something cool happening. You then try to narrow it down until you find out exactly what combination triggers the special move. You learn that pressing quarter circle forward + punch makes a blue fireball and Ryu says “Hadouken”.
Testing software is very similar to this. You poke the application until something cool happens, normally a bug, and then you try to repeat those steps to narrow down what is causing the bug. Knowing exactly what ‘moves’ are triggering your bug is helpful for debugging it as it narrows down where in the code a bug may be hidden.
But testing is no game, even though it may be fun.
Instead of clicking buttons frenetically, it is important to plan your steps. This way, when you do find a bug you can replicate it easily. Test scripts help you make sure you are following the same steps over and over again. This is particularly useful if you have to repeat the test at a later date or make sure you are testing as many possibilities as possible. Scripts may even be automated, saving you the trouble to run them yourself.
However, some bugs are like secret moves, they are hidden in the app and your normal scripts will not be able to catch them. That is where exploratory testing comes in. The tester becomes some kind of Indiana Jones and goes exploring the depths of the app for secrets. But just because the tester is exploring the unknown does not mean he will not map it for future exploration. When doing exploratory testing it is important to keep track of your steps so if you do find something you know what to do to replicate it.
Finding bugs before release makes them easier to fix (cheaper too). Also, as the name says, testing increases confidence in the quality of an app, increasing customer satisfaction and the developing team’s smugness.