One of the challenges that all software development groups face is the trade-off between time-to-market and adding new features. Software is so malleable that it is tempting to make changes right up until the day of release; when we think of one more feature that’s too cool to ignore. The problem with last-minute changes is that you almost always get unintended side effects. And so we’ve all learned over the years that last minute changes are not a good idea. This results in longer release cycles of once or twice a year, so that we can do full QA on each feature. The result of of this approach is you end up with backlog of cool new stuff your developers have built but that you cannot release to customers.
How can we improve our time-to-market and not sacrifice software quality? There are two keys to achieve faster release cycles with better quality:
- Ensure that you have tests to formalize existing behavior
- Expose these test to everyone on the team for editing and execution
Most development groups fall short on both points. Existing tests are not complete; and they are kept in silos that are maintained by different teams. The developers, integrators, and QA engineers all have separate sets of tests, and these tests are rarely shared between the groups. We could argue forever about what complete testing means, where test efforts should be focused, and what sort of testing provides the best ROI. But there really is no valid reason to not share tests.
When tests are kept in silos, it leads to an adversarial relationship between team members. New features are marked “done” by the developers only to get “stuck” in QA for weeks. Why are they stuck? Is the QA team evil? Are they sabotaging the developers? Of course not, they get stuck because the developers are delivering changes that have not been tested adequately. Why are the changes under-tested? Are the developers lazy, or uninterested in quality? Neither, the changes are being judged by a “hidden” set of criteria – the QA tests that the developers cannot access – so, it’s not surprising that new features break these tests.
Make this the year that you blow up those test silos and start sharing tests. And ignore the excuses you hear from the naysayers: “We don’t have enough hardware”. “Only Tom knows how to run those tests”. “Only Sally knows how to interpret the test results”. “Some of those tests always fail, but they’re not real bugs” …
One of the best things that you can do to improve the quality and time-to-market of your software :
Ensure that everyone on your team is a tester!