Development team: User Stories, when to test them?
When should a developer team test its productions? Read on to find out when – and under what conditions – developers should test the work they’ve completed in a development sprint.
As part of an agile method and more particularly the Scrum method, when is it most appropriate to perform functional testing of the application that’s being developed?
To begin with, let’s take a look at what to avoid during testing phases.
“Freeze time” just before the Sprint Review
The first point of caution is to avoid “freeze time”. Freeze time occurs just after the development sprint, that is, when the developer team has processed all the user stories contained in the sprint backlog. Freeze time refers to the stage when the development team will test the user stories developed during a given period of time – a day for example. Then, at the end of the freeze time, the Scrum team presents the completed and tested features to the project stakeholders.
The problem that is very often encountered during a freeze time is that developers realize during the course of their testing that certain things are not right, and need to be changed. Unfortunately, the development team will probably not have time to modify all the errors found before the Sprint Review meeting. The team will then present a product that’s unfinished.
This situation can be all the more disruptive as developers may try to directly modify the errors on the product during the freeze time, and thus generate more errors.
As a result, the product might even perform worse at the end of the freeze time than it did at the beginning, as the changes will have been made to the software in a rush.
Manage tests in real time: just in time
The best test management approach is to test the developed functionalities in real time.
The developer team can then elect a team member that has strong testing skills to be responsible for testing right after functionalities have been developed. It’s important to avoid waiting for all the features of the Sprint Backlog to be finalized before testing, at all costs.
Waiting to test all features in one go amounts to following a cascade (Waterfall) project management approach, and can no longer be considered agile. Under the Scrum method the process to follow is therefore the following:
- Step 1: the development team selects the user story they want to develop in the backlog sprint,
- Step 2: developers create the user story,
- Step 3: a developer with testing skills is chosen by the team to test the user story,
- Step 4: developers process the corrections reported during the test,
- Step 5: the user story is re-tested, and finally validated when everything is OK,
- Step 6: developers choose a new user story to process.
This cycle then repeats until the tester has validated all the user stories. It is therefore a question of testing the developments as they materialize, and to correct them as they progress through a sprint – not to test them all in one go at the end.
The longer you wait to test a feature set, the larger and more complicated feedback will be, and the longer it will take to implement it.
It is also important that it is a member of the developer team that has testing skills that is assigned the task of testing the application – not someone outside the team. The tester needs to be ready to immediately test, and shouldn’t be someone that will have to be called, and potentially waited on to test. This is especially true for Product Owners.
In conclusion: the tests are not done at the very end of the sprint, but in real time.
Find out how Bocasay applies the Scrum method in its projects.
Source: agiliste.fr, laminuteagile.com
