Hey Testers, Let’s Be Anti-Bottlenecks

I believe testers have the power to either slow down the rate of production deployments or speed them up, without adversely affecting their testing value.

1. My test career began as a “Quality Cop”.  I believed a large responsibility of my job was preventing things from going to production. 
2. After talking Michael Bolton’s Rapid Software Testing class, I stopped trying to assure quality, stopped being the team bottleneck, and became a tester.  At this point I was indifferent to what and when things went to production.  I left it in the hands of the stakeholders and did my best to give them enough information to make their decision obvious.
3. Lately, I’ve become an “Anti-bottleneck Tester”.  I think it’s possible to be an excellent tester, while at the same time, working to keep changes flowing to production.  It probably has something to do with my new perspective after becoming a test manager.  But I still test a considerable amount, so I would like to think I’m not completely warped in the head yet.

Tell me if you agree.  The following are actions testers can do to help things flow to production quicker.

• When you’re testing new FeatureA and you find bugs that are not caused by the new code (e.g., the bug exists in production), make this clear.  The bug should probably not slow down FeatureA’s prod deployment.  Whether it gets fixed or not should probably be decoupled from FeatureA’s path.  The tester should point this out.
• Be a champion of flushing out issues before it hits the programmer’s desk.  Don’t get greedy and keep them to yourself.  Don’t think, “I just came up with an awesome test, I know it’s going to fail!”.  No no no tester!  Bad tester!  Don’t do this.  Go warn somebody before they finish coding.
• Be proactive with your test results.  Don’t wait 4 days to tell your stakeholders what you discovered.  Tell them what you know today!  You may be surprised.  They may say, “thanks, that’s all we really needed to know, let’s get this deployed”.
• Help your programmers focus.  Work with them.  I’m NOT talking about pair programming.  When they are ready for you to start testing, start testing!  Give them immediate feedback, keep your testing focused on the same feature.  Go back and forth until you’re both done.  Then wrap it up and work on the next one… together.  When possible, don’t multi-task between user stories.
• Deployments are something to celebrate, not fear.  This relates more to Kanban than Scrum.  If you have faith in your testing then don’t fear deployments.  We have almost daily deployments on my Kanban project now.  This has been a huge change for testers who are used to 4 week deployments.  Enthusiastic testers who take pride in rapid deployments can feel a much needed sense of accomplishment and spread the feeling to the rest of the team.
• Don’t waste too much time on subjective quality attributes.  Delegate this testing to users or other non-testers who may be thrilled to help. 
• Don’t test things that don’t need testing.  See my Eight Things You May Not Need To Test post.

Every other development team is running around whining “we’re overworked”, “our deadlines are not feasible”.  Testers have the power to influence their team’s success.  Why not use it for the better?