Making Testing Visible
Most testing work is invisible—something that happens inside your head and leaves no artifacts behind. Software developers have code, databases, and configuration files to show that they have been productive. Designers have mock-ups and data from user studies. Product people have a living conversation that teaches the technical team what needs to be made. A tester might have nothing to show at the end of a workday. This generally leaves testers feeling like no one understands what they do all day.
How do you make your testing work more visible and easier to understand?
One of the reasons testing work is invisible is because literally no one sees it. Testers get a new build, hide in their cubicles for a while, and then emerge with a few bug reports (or sometimes nothing at all). The work isn’t observed by anyone.
I prevent this is by making sure my work is seen by other people. I collaborate closely with developers, from when a change request is reviewed until the change is ready for production. That means helping design and write unit tests, observing code that is being written and occasionally discovering bugs in that process, and, yes, exploring the product in a browser, too.
This is fairly radical in terms of how most teams collaborate. A good intermediary step is frequent demonstration and conversation. Every morning in your stand-up, rather than saying, “Today I am testing the new report; no blocks,” actually talk about your work. What risks are you exploring? What platforms are you concerned about? What would help you perform your job more effectively?
When you are testing, try to do it with a developer sitting with you, or at least nearby, for some part of the day. This will allow them to see how you are performing testing work, and you will have the opportunity to demonstrate bugs when you find them rather than having them get lost in a bug-tracking system. I usually find it helpful to ask the developer about their concerns while they are around. They know the implementation and how it integrates with other parts of the product, so they may have some suggestions of what to test or what risk idea to explore next.
I’ve heard people suggest adding a sort of accounting practice to their testing work. Each bug has some potential cost to the business, so the theory is that a bug report should relate back to its financial impact. Relating testing work to business results is great, but I’m not sure most people are prepared for or have time to do financial analysis for each problem they find. I have only seen this be approachable in e-commerce, where a bug might prevent a sale.
If you want your work to be understood, then make it visible. Work more closely with your developer friends. Demonstrate the testing you have done, tell them about the test ideas you want to perform, and describe the risks and bugs you have discovered. Visibility is the first step.
