The Tester on Your Team Does Not Assure Quality
Having a tester on your team is no assurance of a Quality end product. That carrot dangles in front of all of our faces. It is a shared burden and responsibility by the whole team. Your Tester is simply highly trained in hunting bugs and keeping watch for potential issues that may lead to a weaker product.
The tester doesn’t believe in “bug-free” software and will never tell you the system under test has no bugs. An experienced Tester functions under the belief that the number of bugs in a product is infinite and that their job is to get the big bad ones exposed as rapidly as possible. They will report defects and show you things they tried in order to expose anomalies and will make every effort to find the bugs that matter expeditiously.
They will, however, assure you that they will put their best effort into finding issues and voicing concerns with the goal of mitigating risk and aiming for the highest quality reasonably achievable.
They are not magicians, software testing is a trade. Putting one on your project won’t magically make everything better. They show up and promise to do the best work they can. They don’t outright eschew or blindly embrace any particular form of testing. They take them all and decide which ones are appropriate for the project/feature/situation or not. Sometimes that is, in fact, verbose test cases (but those are sparing to tell you the truth) and sometimes it’s a well crafted Exploratory Charter. They might end up writing some lean test cases (those can be written in one line) or creating some MindMaps to help flesh out their approach. Their test plans will lay out the intentions and ideas and strategies but writing down every single thing they might do would be wasting everyone’s time and therefore money. They find that idea repulsive. Wasted time is not an option when you are on a deadline, a budget, and are facing down an incalculable number of defects. A Tester will document what makes sense to keep themselves organized and their team informed, but anything more rubs against their professional integrity.
In order for them to do a good job, they need to spend a lot of time learning about the product, its purpose, its technologies. This is one area where the ol’ Agile “working software over comprehensive documentation” is crystalline. A Tester needs to pool together every oracle, data point, and resource available. Once they have a foothold in understanding the large picture, they can dive in and start finding issues and getting a sense of the risks. The more a Tester learns, the deeper they can test. The more things they figure out that there are, the better a Tester can ensure they’ve made a reasonable effort to cover them.
They will not wait for permission or guidance, a good tester will dive in head first and start exploring. The developers probably started implementing features that weren’t quite fleshed out, to begin with (look at literally any PRD on the planet). So many bugs come from this lack of clarity. The Tester will turn that information firehose on and monitor it continuously; probably by watching commit logs in the repository or User Stories in the bug-tracker, likely both. They appreciate and will absorb any information you can give them but are comfortable in ambiguity and will self-direct their time and attention diligently. The tester will compose the best bug report they can in the shortest amount of time that they can. They know that sometimes they will not be able to reproduce the anomaly but will report it nonetheless, even if lack of details is to everyone’s shared chagrin.
They are more investigative journalists and archaeologists than button mashers. They study software testing specifically. They can’t assure quality. They get good at what they do and they report their findings and provide feedback but it’s up to others to take that information and act on it. All the boundary analysis and combinatorial testing, all the memory profiling and fuzzing, all the bug reporting in the world, any of it, all of it, it’s all noise if it’s not acted upon.
If you want your product to be of the quality that we’re all aiming toward it, get someone on your team who is trained at it. Process and act on what they find. Vow as a team to only put well-scrutinized bits and bytes out in the world.