You don’t need bugs to feel pride about the testing service you provide to your team. That was my initial message for my post, Avoid Trivial Bugs, Report What Works. I think I obscured said message by covering too many topics in that post so I’ll take a more focused stab at said topic.
Here is a list of things we (testers) can do to help feel pride in our testing when everything works and we have few to no bugs to report. Here we go…
- Congratulate your programmers on a job well done. Encourage a small celebration. Encourage more of the same by asking what they did differently. Feel pride with them and be grateful to be a part of a successful team.
- If you miss the ego boost that accompanies cool bug discovery, brag about your coolest, most creative, most technical test. You were sure the product would crash and burn but to your surprise, it held up. Sharing an impressive test is sometimes enough to show you’ve been busy.
- Give more test reports (or start giving them). A test report is a method of summarizing your testing story. You did a lot. Share it.
- Focus on how quickly whatever you tested has moved from development to production. Your manager may appreciate this even more than the knowledge that you found a bunch of bugs. Now you can test even more.
- Start a count on a banner or webpage that indicates how many days your team has gone without bugs.
- If the reason you didn’t find bugs is because you helped the programmer NOT write bugs from the beginning, then brag about it in your retrospective.
- Perform a “self check”; ask another team member to see if they can find any bugs in your Feature. If they can’t find bugs, you can feel pride in your testing. If they can find bugs, you can feel pride in the guts it took to expose yourself to failure (and learn another test idea).
What additions can you think of?
Finding perfects- team recognition. See http://jlottosen.wordpress.com/2012/02/02/perfects-in-testing/
ReplyDeletecool post, straight to my favorite ones. like Lis Hendrickson says, do away with traditional and often punitive metrics, focus on metrics based on accomplishments.
ReplyDeleteLoving points 2 and 4, I wish more testers realised how much value they can add to the start of the process rather than just reporting everything that breaks at the end.
ReplyDeleteI always keep in mind the saying that 'if you really want something to happen then you shouldn't care who does it' - testers need to get on board the delivery mindset.
"Start a count on a banner or webpage that indicates how many days your team has gone without bugs."
ReplyDeleteI assume by this you mean "how many days your team has gone without bugs having been found in Production"?
We test (and find bugs in our test environment) so that our customers don't find bugs in Production.
Exceptional post. Very unique content and topic. I remember one such mail wherein QA testing team wrote back to Devlopment team about their sucess rate. Look forward to see you next post.
ReplyDelete