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 they almost always have 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, once or twice a year, so that we can do full QA on each feature. The negative of this approach is you have a backlog of all this cool new stuff your developers are building that you cannot get to customers. How can we improve our time-to-market and not sacrifice quality? There are two keys to achieving faster release cycles with better quality:
- Ensure that you have adequate tests that formalize existing behavior
- Expose these tests to everyone on the team.
Most development groups fall short on both of these points - existing tests are not complete, and they are kept in silos 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 is, where test efforts should be focused, and what sort of testing provides the best ROI. But there really cannot be any 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 2016 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 quality in your software is to ensure that everyone on your team is involved in the process.