It would be helpful to quantify the amount of time spent for defect fixing as KPI. This way, you could systematically monitor the effectiveness of your improvement measures.
An early warning system would be perfect that tells you about future defect risks, for example, because of:
- Blind spots in the test automation
- Increases in technical debt
- Team fluctuations and bad knowledge distributions
- Requirements that induce broadly scattered changes in the code architecture
Light-weight but effective risk-mitigating activities should be integrated into the daily doing of the developers. For example:
- Determining how well a work item (story, change request) is secured by test automation and adding an appropriate code coverage threshold to the definition-of-done for work items.
- Remark: This requires a profound analytics approach that determines the code units that are changed in the context of a work item and calculates code coverage by tests for exactly these code units.
An effort stream monitoring would be helpful to steer towards the sweet spot between working on test code versus production code.