This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Programming skills can be taught through repetition. Pick a programming language and an exercise, for example, the Bowling Game Kata. Then, perform that exercise once a day for a few weeks, trying to get the code a little more concise, readable, and efficient each time.
If only it were that easy to teach testing.
Sadly, you can’t un-find a bug. It might be possible to come up with different charters, or risks to investigate, in the same software for day two and three, but repeating the process to find the same categories of bugs does not make sense. Once you have found the bug, some of the magic is lost. One way I like to work around that problem is to teach testing skills and principles through games. The games are fun by themselves, but there are testing lessons and behaviors embedded at each step.
Here are two games I like to use when teaching people software testing.
The Dice Game
The dice game is an infamous after-hours event at software testing conferences. The principles are simple, and the game is easy to run. The person running the game needs a collection of dice, any gaming store should be able to supply this. Get some normal 6-sided dice in different colors, finishes, and number markings. Then get all manner of other dice – different number of sides, electronic, and loaded.
The basis of the game is that the person running it comes up with a formula, such as 2 times the smallest even number plus one. To make the game more challenging, I could add some rules around the formula; for example, an error condition occurs any time a red die is used, if there is a 20-sided die the total is automatically 17. People playing form groups and roll the dice. Each time they roll the dice, the person running the game will tell them what their total is. They all roll all the dice at once, they can roll one at a time, and they can swap dice in and out of their set as they want to figure out the formula.
The players roll, the game master gives them a total, the players roll again and again, until the players figure out the manner of scoring.
At a superficial level, this game is a fun way to practice reverse engineering and some basic math skills. Groups start with a set of dice that show a value, and then based on that value they work backwards toward the formula. It is also a fun competition. People like to see which group can get the formula first. Look deeper, and you will find behaviors that are important for software testers to develop.
I first played the game in 2007. A tester I was working with attended CAST 2007, and came back excited about the game. I don’t recall the formula he used, but I do remember the flow of the game. Each group started with five dice, and rolled the entire set all together. We rolled, and the tester running the game gave us our total. We rolled again, and he gave us a total again. Full rolls were not teaching us any new information.
We started changing one die at a time, and noticed that the value was changing. Testing is about creating experiments and making observations. Changing one die at a time helped us create a more concise experiment, one where we could isolate variables and see how each variable affected the calculation.
At this point, we had 6 or 7 dice, and we were changing them one at a time to different sides to see what would happen. That is a lot of experiments happening one after the other. We found ourselves changing the same die to the same value several times in a row. The next step was to get a pen and paper to write down the dice we used, what the face values were, and what the resulting formula calculation was. Using our notes, we figured out which dice were changing the calculation, and eventually figured out the formula and the error condition. Testers use note taking often when working with multiple variables at a time. Seeing how shipping, tax, and a discount affect the final price of a product is much easier when there is a spreadsheet of values you have already used.
Try to run the dice game at your next company testers meeting, but don’t forget the retrospective at the end so people can discover and hone skills they are using every day.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Set
Remember the matching card game you played as a child? You’d take a deck of cards with images on them and flip them all face down so that you can’t see any of the images. One at a time, try to find a match in the deck; apples and apples, cars and cars. Set is a more challenging version of the matching game that will help testers develop pattern recognition and observation skills.
There are three different shapes in a card deck: squares, circles, and triangles. Each of these shapes can be different colors, or have a different fill (stripes, solid, or blank). To get a match, you need to find three cards where each attribute on the card is either all different or all the same. For example:
- One solid red triangle.
- Two solid yellow triangles.
- Three solid blue triangles.
This makes a set because each card has the same shape and fill, and each card has a different number and color.
New cards are laid out from the deck each time a match is made, or if no match can be found in the set of cards. The person with the most matches at the end of a deck is the winner.
What this game teaches is something called a consistency heuristic. A heuristic is a fancy way to say: “an imperfect method to find problems.” Set teaches us to look for things that follow a pattern; when software fails to follow an implied pattern, it is inconsistent, and there is often a bug.
Imagine a software product that has 7 pages to submit data. Every page has a submit button and a cancel button next to each other, both with rounded corners. You are at the end of a release, and most of the data testing has been done. You navigate through the pages quickly, just to do a final sanity check, and something seems strange but can’t quite figure out the problem. After a few more quick pass throughs, you notice that save and cancel are reversed on the third page. Furthermore, the cancel button has sharp corners instead of rounded corners on page four. If you wanted to have a more systematic look at the look and feel of a page, you could do visual scans from top to bottom or left to right.
Work your way through a Set deck with a group of testers. Winning isn’t the important part. Hold a debrief at the end of the deck. Have each person talk about the strategies they developed for finding matches, such as quick scans, top to bottom, bottom to top, left to right, right to left. Discuss how they changed their strategy over time as they discovered one worked better than others, or one was better at finding certain types of patterns. This type of observation is a skill that can be developed through practice and feedback.
Connect the Dots
The test training I’ve seen falls into a few categories; PowerPoint presentations that never quite cover testing real software, fun activities where people can compete and show off intellectual prowess, and open-ended bug hunts. All these options add value to some degree, but people may not put the lessons to use. Next time you have a training opportunity, or even a spare hour at work, try out a testing game, and don’t forget the most important part, the debrief and feedback loop at the end!
