As a tester, I've been asked to provide some concrete input regarding unit testing - with regards to the overall product and process quality.
Our current situation is as follows:
- Organisation has known explosive growth over a few years, there are two-week sprints with a production release a week later (after acceptance phase).
- There are quite a few unit tests in place, but certainly not (sufficient) for every module or calculation.
- Unit tests are being written occassionally at best, when the developer feels that its useful and that the test setup effort isn't too time-consuming.
- Due to the complex nature of the application, said test setup is equally complex and has never been done for certain modules.
- A new version of the application is being written (mostly front-end and middle layers), so a part of the current code is kind of legacy but will go a long way still.
Here are some of my thoughts so far, but I'm looking for any experiences or ideas that can help me construct a good proposal:
- Immediately "forcing" developers to unit test to a given degree doesn't feel right, as I believe it should be a cultural mindset. But how to achieve that step by step?
- When reading some Agile books, it's mostly about TDD but I fear that's too big a step.
- Code coverage: could be a baseline percentage to strive for, but of course it's not indicative of having useful tests. Although it's easily made visible and an incentive to write tests nonetheless.
- To decide whether we should invest a lot of time in test setups, could we look at how many defects could've been detected by unit tests (rather than testers)? In other words, would the ROI be positive? (Yes, I know early detection is always cheaper, but what is the cut-off to determine if very complex testing efforts produce equally useful tests in return?)
So my current proposal would be this - to slowly introduce the mindset:
- If any defects found by a tester can be unit-tested, implement a test when fixing the defect
- Same for production bugs
- At each retrospective, go over the resolved stories that don't have unit tests and discuss if they are missed opportunities
- Set a feasible code coverage standard for new code
- During planning, have a tester and developer pair up to discuss possible test cases for unit tests.