Solving complex testing problems

There are a number of testers out there who pose practice problems to the testing community (Matt Heusser, James Bach, Michael Bolton, and Ross Collard to name but a few). Attempting to tackle those problems can be a great way to develop your testing stills. There's three big reasons why this type of practice can help you develop your skills better and faster than if you just log four or five extra hours at the office:

• It's different than what you do everyday. Very likely if you're doing one of these examples, most of the time you'll be testing software that's significantly different than what you test every day at the office. That stretches your imagination, gets you away from your everyday biases and assumptions of what you can and can't test, and gets you focused on the mechanics of testing more than the mechanics of the product or the business problem. If you play chess, poker, sports, or even play in a band... you can get good by practicing with the same people all the time, but you can't get great. To get great you need a variety of experiences. You need to compete or play against people who are different than those you practice against. Testing is no different.


• It's designed to be more complex than your average test. If you're going to practice, you need difficult problems. Yesterday a fellow tester gave me a programming problem from college related to the fibonacci sequence. I was able to show him example code solving the problem on my first try in about thirteen lines of code. That wasn't practice. It was problem number four on his page of practice programming problems. He than gave me problem number 200 (or some other similarly high number). It was so complex if I really wanted to solve it I'd have to spend some time looking up the math and geometry terms involved in the problem. Then I'd have to actually stand at a whiteboard and design a couple of algorithms to make sure it would execute in the time allowed. That's a practice problem. It's something that stretches you to do something you've not done before. The first problem wasn't practice (for me), the second one was. As you become more skilled as a tester, you need harder and harder problems to solve. In addition to being more complex than your average daily work-related testing problem, these problems are also (typically) focused on a specific aspect of testing. They're designed to get you thinking about a technique or concept of risk or coverage that you don't use everyday.


• Feedback is built into the exercise. The most important aspect of these problems is that you get feedback. Sometimes you get direct and personal feedback from the people who presented the problem. James Bach for example is almost always willing to critique a solution you provide to a problem he presents. That's worth the price of admission right there! But it often goes farther than that. Often times you get to see your solution right next to twenty others. You see how other people solved it. That can be just as important as the personalized feedback. It gives you the ability to see and learn from others. It allows you to self analyze your own performance and work to make corrections in your technique or process.