Hacking the Good Days...
Note: This blog post is more for the techkies. Please skip if you’re not interested in product management or agile… 
Been reading Manage It!, a product management book highly recommended by Phobeo (thanks! love it!) and I was particularly inspired by the roles of a first-class tester. Page 266 and paraphasing here. A first-class tester is someone who can
- Be sufficiently creative to assess the design and architecture of the system before the code is written
- When the code is implemented, design and implement their test harnesses, both automatic and manual, creating test the stress the system in ways the developers do not expect
- Measure what they’ve tested, assess the risk of what they have tested
- Know whether they have tested enough of the system to help you understand the risks of product release
- Keep up with developers, assuming the developers are using continuous integration and not checking in a week’s worth (or more) of code at one time
- Have a peer relationship with developers. They work as partners, not adversaries
- Alter the way the developers create the product
‘When testers help developers see their problems early, the developers are more likely to include the testers in other requirements and design discussions.’
This is so inspiring that I feel that I am suffering from first-class-tester-envy. Testing should not be seen as a tedious job on pointing out flaws in system. A great tester is not a doctor that tells patience what’s wrong with them. A great tester is a nutritionist and a fitness instructor or yoga teacher (whatever school you prefer) that keeps the system and the process ‘fit’. Ideally by the time you run automatic and system test, all readings should be healthy. A first class tester reduces the risks of finding big problems towards the end of the product development cycle and be the source of truth in the team. A great tester is an inspiration and part of the core fabric in a team.
If you enjoyed this article, please consider sharing it!
What makes a first class tester (from a developer’s perspective):
* Being able to document how to reproduce a bug/issue. This is killer – more development time is wasted in aimlessly trying to figure out how to replicate an error based on second/third hand information.
* Being able to explain what the correct behaviour should be
* Being able to focus on finding the right sort of bugs, not things that don’t matter to the user or are unnecessary trivialities.
* Preferably realising that it takes time to fix bugs, so raising them right before or after a code freeze isn’t helpful.
* Reports bugs as he finds them, not collect them all up and announce in one big go
The key ingredient: determination. One exceptionally good tester I worked with on Yahoo/Eurosport spent several weeks tracking down an intermittent bug that no-one couldn’t replicate in development or staging. He found a way to consistently replicate the bug, which meant being able to fix it quicker. That’s determination.
[...] This post was mentioned on Twitter by Gui Zühlke O'Connor, Cathy. Cathy said: Wondering what else makes tester great? http://bit.ly/foRsTa [...]
Wow, really good feedback Mike, from a developer’s point of view. Useful insight, thanks.