By Jacqueline Vermette
Twenty five years ago, when I started my career as a young software engineer, there were very few professional testers. Only large, important projects had testing teams. For most projects, software testing consisted of having the lead analyst review the system just before delivery. Occasionally, the tests were even per formed together with the client during the acceptance phase, leading to unpredictable results. After a particularly painful client acceptance experience, the manager would call a meeting. He would declare: “For the next project, we absolutely need to test before delivery.”
”But, who’s going to test?” replied the project leader.
“Well, we have Bob and Jackie who are not very busy. They can test during the two weeks before delivery. Let’s ask them to find as many bugs as they can.”
“All right, let’s give a try.”
So in the next project, all the team members would work very hard during the last two weeks to cap the project. Our new testers, Bob and Jackie, would do their very best despite their limited experience. How- ever, Bob did not want to pursue a career in testing. He had no interest in performing tests all day and would eventually leave the project. Jackie found more bugs than Bob did. She believed in the process and would apply her learning experience to improve her contribution in their subsequent projects.
This was a very typical scenario and reminds me of a Dilbert comic strip published in March 2010. In it, Dilbert’s boss asks his help in quality testing a new software version. Dilbert gives all sorts of silly reasons to not become a quality tester and concludes his message by swatting his boss across the face with a binder, to the boss’s great displeasure. In this situation, it is clear that Dilbert has no interest in testing and most probably does not have the skill set to be a good tester anyway. Of course, this is a satire, but it is very close to reality. During the last few decades, development methodology and testing processes have obviously evolved. But even now there is still this tendency in the IT community to believe that anyone can be a quality tester – but can everyone really test properly? It is incorrect to think that anyone can produce good software tests. I personally think that you need the proper genetic make-up to be a great tester, but what qualities are we talking about here?
A natural-born tester:
1. Has the technical knowledge and deep analytical ability needed to create extremely complex tests. These characteristics, along with an innate need to break things down, add to the strength and reliability of the final product. Simple tests can find the most obvious bugs, such as formatting errors or missing boundary validations. But it takes more detailed testing scenarios to uncover errors of logic or cascading effects. For example, going through all cases of a state diagram, and especially from a state to a forbidden state, often reveals surprising results. For complex cases, documenting the tests to execute is essential. Using an old fashioned Excel sheet is always better than nothing.
2. Has an ability to learn. Testers may be asked to go from a limited understanding of a product to mastering that product in a very short timeframe. They must be able to memorize details and understand each module’s concepts while maintaining a general overview of the product. Testers must be willing to review and learn all the expected system behaviour by studying the technical documentation and spending time with the main analyst. I remember one particularly complex application for an aluminium smelter where very few people had an overview of the whole business process at the beginning. The management was not too sure whether the test team would be able to test adequately. But by reading all the available documentation and asking questions and more questions, we did a great job. Never be shy about asking questions in order to understand details about the application, especially if the specifications are not clear enough.
3. Can think outside the box, and takes into account assumptions and concrete facts. Not all conditions are necessarily stated in the functional specifications. It is like when you buy a car, you assume that the hood can easily be opened to check the motor. This criterion is not mentioned in the car’s features, but everybody expects it. Testers should try to test unwritten features. Some unwritten characteristics could have a significant impact on the quality of the final product, hence the need to read between the lines. For example, the system can support some required functionalities, but what would happen if I tried something a little different? Does the system support it? Does it crash? Does it corrupt data?
4. Cultivates a keen sense of observation and notes small details. Their perfectionism can unfortunately annoy programmers and developers, but good testers can find the biggest bugs in the least likely situations. If a sequence of system operations is available to the user, why are they not supposed to perform them, for example? Why does the screen have labels with different fonts? Report fields that are not properly aligned or inconsistent use of capitalization are other examples of small details that can negatively impact the quality of the product. Some people just notice this type of error more than others. They are probably like that in all their daily activities.
5. Cares deeply about the final product. They believe in their mission, which is to protect the company’s reputation. They love testing and are proud to find bugs. Finding a bug is highly satisfying and finding an especially tricky one surely makes their day.
6. Is organized yet flexible. They pay attention to the manuals and conduct the tests systematically. This is very important in order to reproduce a bug. A bug that cannot be properly detailed in order to be reproduced cannot be corrected. They can also adapt to changes during the course of a project and are willing to repeat tests over and over, if necessary. After a bug correction, a test case might need to be modified and re-executed to validate the quality of the system.
Even with all these attributes, no one can be a good tester if they cannot bring a positive influence to a development team. A tester must provide positive feedback, be able to motivate team members to improve the quality of their work and, in general, manage each team member’s self-respect.
The tester’s role is in constant flux. To stay competitive in today’s market, companies must now produce ever more complex software solutions, at an ever faster pace, and at a lower cost. Test management tools, system simulation, and automatic test case execution are now a must. We must adapt to these changes by developing our programming abilities or by working closely with developers. Promoting more completed unit tests and testing as soon as possible with the developers helps greatly to reduce errors early in the test process.
An effective tester cannot guarantee that a product is completely bug-free. However, choosing the right person for the role will lead to the best possible results by drastically reducing the impact of any remaining bugs.
In conclusion, for your next project, do not select a Dilbert to perform your quality tests. When selecting a software developer, you are trying to choose the right person to take on your project. You want the best one possible. Just apply the same principle when choosing a quality tester. An efficient software tester will help you to maximize your return on investment.
 PAGE Alan, How we test software at Microsoft, Microsoft Press, 2009
 PRATAP K.J., The Psychology of testing, The code Project, 2007