Be Efficient: Reduce Effort for Defect Fixing

Context

Regardless of the kind of software development, independent of process methodologies (waterfall, agile, scaled agile, V-model, …) or type of software systems (IT applications, SaaS, mobile apps, embedded systems, …) companies devote a significant portion of developer resources to defect fixing. This is wasted time that could have been used for implementing valuable features instead.

Pains

You can only observe the developers' fight against the defect backlog but you don’t see recurring patterns and neuralgic points that cause the defects. Hence, you cannot pinpoint and eliminate the root causes. For example:

• Are there hotspots in the code landscape that need to be fixed over and over again?
• Do these hotspots contain complex code (“technical debt”) that is difficult to be understood?
• Are these hotspots only weakly secured by automated tests?
• Do developers have to enter into unfamiliar code that is additionally complex?
• Do developers perform code changes that are largely scattered across the architecture?

To reduce this wasteful defect fixing you would need to trigger improvement measures in multiple dimensions. But which ones and where to start?

• Focus on code: reducing code complexities and optimizing architecture decomposition
• Focus on testing: increasing test automation
• Focus on team structure: finding the sweet spot of code-ownership and harmful knowledge monopolies

Gains

With Seerene, you can quantify the amount of time spent for defect fixing as KPI. This way, you can systematically monitor the effectiveness of your improvement measures.

Seerene can serve as an early warning system 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.

Seerene helps you with effort stream monitoring to steer towards the sweet spot between working on test code versus production code.