in our system test activities? Couldn't we use the testers to find defects earlier or differently?" Franny's defects, especially, were all found during system test. That means that more than one-third of all the high-priority defects were found in system test, via exploratory testing, not testing that could be planned out and described for other people to do.
If I were a manual black box tester, I'd measure my work like this, to see where I'm adding value to the project: Could I add more value by changing what I'm doing when? If I looked at the product architecture, could I test differently? What if I tested the equirements, or reviewed code-would that change anything? If I had inside knowledge of the field, could I become a better tester?
Amanda decided she needed to find the high-severity defects earlier, so she started Franny and two test developers, Bertha and David, doing exploratory testing with developers. The developers wrote some code, did some peer reviews (which included Franny, Bertha, and David), unit tested the code, checked the code in, and then the testers explored the code or wrote automated tests, all before system test officially started. At a test group meeting, Franny, Bertha, and David were very enthusiastic about their ability to get started testing much earlier in the project, and to find problems that the developers would have had trouble fixing later.
Harold, Edward, and Cameron, all manual black box testers, also wanted to
start testing earlier, but they didn't have the skill set to attend reviews, or start developing tests without the product's GUI. Harold, Edward, and Cameron are smart people, but they lack enough understanding of software architecture or how to read code.
Amanda realized that she'd rather have someone else like Franny, Bertha, or
David who could understand how the product was put together from the inside out.
Amanda decided to look for someone who understood code, looking for either an
exploratory tester or a test automator. For her organization, those were the high-leverage values that would most pay off.
Now let's look at another kind of high-leverage value. When I showed a draft of this column to a different test manager, he said, "For me, manual testers are more valuable because of my applications' complexities. I could lose the white box testers and not miss a beat." This test manager's products and problems are in a different domain than Amanda's. He wants black box testers who understand how each of the applications is architected and related, and who understand how their users will use the system. This kind of product or subject matter domain expertise is a very valuable skill.
Another kind of expertise is industry expertise. Do you understand how a particular industry works? Does that knowledge change what or how you choose to test?
If you're a manual black box tester, and your organization is evaluating tester worth, consider how you can increase your value:
- What do you need to do to find defects earlier?
- What do you need to do to discover high-severity defects and discover them earlier?
- What can you do to reduce the amount of test time needed?
- Is there another way you could test in order to increase your value to the organization?
People who can read code, write automated tests, or otherwise provide value closer to that of a developer, will continue to have their pick of jobs. Black box testers who are (and remain) subject-matter experts in their fields can also provide significant value to their organizations. And testers who use knowledge of their target user's industry to