This is a guest posting by Nishi Grover Garg.
A hardening sprint is an additional sprint that some teams run to stabilize the code and ensure that everything is ready just before release. Agile teams vary in their opinions on using hardening sprints in Scrum, but if your team does agree on having one before your release, there may be a lot to be done and varied expectations from the product owner, testers and developers. It may also lead to other work being delayed, leading to accumulation of technical debt.
Here are some tips for how to optimize the hardening sprint and achieve the maximum quality before release.
for QA and Development Teams
Plan ahead
As you are planning the release and timelines, you generally have a count of the number of development sprints that will be needed, as well as their schedules. At the same time, plan for a test hardening sprint if you believe it will be needed.
The hardening sprint must be planned for after the last creation sprint and before the final release is supposed to be rolled out. It may be equal to or shorter than the other sprints. You should list the tasks that would be performed in the hardening sprint and set expectations for the outcome before the final release can be done. It’s important that no new features or development be planned or pushed for this sprint; only validations and additional pre-release checks should be performed.
Perform end-to-end testing
As in the development sprints, in a hardening sprint, we are mostly focusing on delivering working user stories and features, with a concentration on performing user story level tests, regression tests on relevant areas and integration tests. Once all development sprints are over, the hardening sprint can be a good time to perform end-to-end tests on the entire system.
Some teams define these tests at the time of requirement analysis using the business needs of the software, while others who are using behavior-driven development and acceptance test-driven development define these tests in their frameworks. The business-level scenarios derived from actual use cases can help us verify the real-time use of the application, touching on various features and components at the same time. This may also mean collaboration between different Scrum teams and testers to verify integration areas.
For example, let’s say we were working on an e-commerce website and there were three Scrum teams: one working on the website, one on the server and back end, and one on the payment gateways. During the creation sprints, each team worked on their respective features, developed and tested them, and passed on the functionality to the other teams that needed them. Most tests would be specific to the feature being developed, with some integration tests as needed.
So the website front-end team would test all menu options, search products using various criteria, check auto-suggest options when typing, and verify product details fetched for selected products. The team working on the server and back-end would be responsible for testing the database and storing and fetching product details from the database. And the payments team would test payments using various bank credit and debit cards, payments using e-wallets, and cash-on-delivery options, as well as verify that the correct payment was deducted based on product price and test refunds on order cancellations.
At the end of the release, the teams can use the test hardening sprint to perform some end-to-end test scenarios, like browsing the website, fetching the details of a product, adding it to the cart, and making the purchase.
Although it is great if these kinds of tests are planned and conducted within the creation sprints, it is a good idea to set aside time at the end of the release to perform such business-level test scenarios to observe the behavior of the system in its totality.
Perform non-functional tests
The test hardening iteration also can be used to perform non-functional tests on the ready system to verify abilities like performance, security, efficiency and usability. These types of non-functional tests need to be planned up front so that tools and expertise can be set up beforehand. This helps ensure that the maximum value can be achieved from the tests, so as to improve the system’s attributes.
Perform tests on other platforms and languages
As we plan the application’s supported environments, browsers and languages in the beginning of the release, there is always some cross-environment testing needed. We can utilize the test hardening sprint to run some planned tests on the environments, browser versions and other supported languages.
For example, a software I was testing had support for French, Spanish, German and English. While we decided to perform most of our functional tests during sprint testing in English and French, we planned to perform some sanity tests in German and Spanish in the hardening sprint before release.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Reduce lower-priority defect counts
During our development sprints, we focus on having the minimum number of defects, especially when it comes to critical or major defects being spilled over to the next sprints. Teams generally define exit criteria around user stories in order to not have any high-priority defects left unresolved when delivering the sprint. So, by the end of the release, the focus may now turn to lower-priority defects that may have piled up and need quick fixing.
Resolving, testing and performing regression tests around these defects may act as clean-up as well as a confidence-building exercise for the system’s overall quality. These tests may also be a part of fulfilling service-level agreements about open defect counts acceptable before release.
Use your sprint wisely
Whatever activities we perform during the hardening sprint, they all should be planned tasks based on the context of the application. We must not think of this time as a buffer zone for performing the slacked-off work, such as white box testing, refactoring code, fixing major defects, documentation or performing enough tests, all of which would lead to technical debt.
It is important that the team leaders and Scrum Master keep an eye on the exit criteria of all tasks and stories when they are delivered and that the team take ownership of not letting debt accumulate. Otherwise, we may lose out on getting value from the hardening sprint and spend the precious time filling in the gaps of quality.
I hope these tips help you optimize your hardening sprint to the maximum quality advantage.
This is a guest posting by Nishi Grover Garg. Nishi is a consulting Testing and Agile trainer with hands-on experience in all stages of software testing life cycle since 2008. She works with Agile Testing Alliance(ATA) to conduct various courses, trainings and organising testing community events and meetups, and also has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
Cross-Technology | Cross-Device | Cross-Platform
