Do your team members spend a lot of time interpreting bug reports? The traditional waterfall QA model is broken. Testing is done months after code is written. Long after we’ve forgotten the context we have to go back and fix a bug. Scrum (and Agile in general) – taking a cue from ‘Lean’ – we integrate QA into the development team. We change the definition of done from coded to coded, reviewed and tested….
When bugs are discovered with hours (at worst days) of being written they’re much cheaper and quicker to fix.
In addition when QA is part of a development team the tracking system doesn’t need to be as formal, cumbersome and time consuming. Many bugs can be handled in person without being entered into a tracking system. Less time spent entering the bug, less time spent trying to understand the description means more time to fix the bug or move onto something else.
Now you say – my organization won’t include QA on my development team – how do I reap some of the benefit?
- Even if you can’t include QA formally do it by stealth – invite them to your planning/stand-up/review meetings
- Coordinate with your external QA, show them your task board, give them frequent updates of the software to test (at least daily). Use informal methods to track bugs.
- Get another developer to test your feature (without your guidance).