Testing inside your timebox: Death to the hardening sprint

Insight Main Image


Hardening sprints may wind up adversely affecting the quality of released software.


The emergence of agile methods has been heralded in the software development community as a preferable alternative to traditional waterfall practices. However, some aspects of waterfall still exist among quality assurance teams as organizations continue to grapple with making the full transition to agile. Even features that have become synonymous with the agile movement may have traces of waterfall in them. One such example is the misuse of hardening sprints.

As software development expert Jim Bird explained on his Building Real Software blog, utilizing hardening sprints can be a contentious topic since there is no consensus on what the process should entail and when it is appropriate to use. At its core, a hardening sprint typically involves QA team members focusing all of their attention to finalizing a product for release. This often requires project participants to stop adding new features to an application as all available resources are devoted to stabilizing the program.

Don’t put off testing
While ironing out flaws and ensuring that software functions properly is absolutely critical to the development process, hardening sprints may be an inefficient way of going about this. The concept of a hardening sprint shares a lot in common with the mindset that underlies waterfall methods. The mere presence of such a task could perpetuate the notion that testing is ultimately something that is done at the end of a production cycle. One of the basic tenets of agile testing holds that QA processes should be conducted throughout the duration of development with programmers and testers working together to continually create a better product. Hardening sprints can undercut this idea and leave teams scrambling to address defects and stabilize an application as a release date nears.

Industry expert Anand Vishwanath outlined some of the tangible drawbacks that can result from relying too heavily on these types of sprints. He noted that software flaws become more expensive to fix the longer a team waits. This is partially due to the fact that as development continues, the application becomes more complex, and the defect becomes more difficult to remove without affecting functionality. In addition, Vishwanath stated that it’s often difficult – if not impossible – to predict how long a hardening sprint will last. QA managers may not be fully aware of the extent of the issues affecting in-development software because comprehensive testing has not been conducted throughout the production cycle. This could mean that teams must rush through these sprints in order to meet looming deadlines and running the risk that something slips through the cracks.

A solid test management strategy should make QA a continuous process and not something that’s put off until the end of development.

Related Articles: