© 2010 - 2015 Scrum Solutions. All Rights Reserved.
Five Tips to get Testing Done in a Sprint
Customers frequently ask me how they could fit testing into their sprints. Well, there isn't a "one-stop solution" that fits all, but in this article are many tips which can aid you in getting testing done in a sprint, says Mandy Schoeman, founder and MD of Scrum Solutions.
Countless companies are not capable of building a complete increment within one sprint, as they don't have the automated testing infrastructure to complete all the testing. Testing adds knowledge during the backlog grooming, assisting the product owner with defining proper acceptance criteria as well as finding poor written backlog items with inconsistencies.
In each of these instances, testing assists the product owner and the team to focus on value.
Tip 1: Testing knowledge in the team
This is actually not a tip, but a must. It might look obvious, but it's not that common and is the hardest thing to accomplish. If you don't have testing skills available in your team, you're breaking an important rule of Scrum, not to mention the rate of failure is high. Now, it isn't that easy to achieve this collaboration mainly because testers and developers are so different. Developers think testers are pencil-pushing, nit-picky quality geeks, while testers simply need to get software that works right the first time, and think that developers forget about who they're building software for. In this highly charged circumstance, I think wrong assumptions and lack of communication are more to blame for the problems than software weaknesses. In merging these two worlds into a single team, you need three important factors: trust, a collaborative culture and non-financial rewards.
Tip 2: Testing on the Scrum board
It seems obvious that you've got tasks in the sprint for your testing activities, but when there is no risk or business value then you don't have to test it; for all other systems… you need test tasks on the Scrum board. I've seen multiple teams working with a Scrum board that didn't have any testing activities; testing was actually a completely separate activity. These test tasks could possibly cover the test activities the team require to build a BPI and conform to the definition of done. Teams often get scared at the sheer volume of testing activities that has to be done and try to minimise them. Bad idea; this is the primary reason why one can't finish testing within the sprint.
Tip 3: Regression tests and automation essentials
Many teams rerun each test every sprint; this is time-intensive and isn't really worth the effort. Having a clear understanding what tests to execute during regression testing provides more time to specify and execute test cases for the functionality implemented during the current sprint. Collating and setting up a quality regression pack is vital and raises the return of investment of the testing effort. Automating your test execution is a must in order to get your testing done during the sprint. Automation shrinks the time needed to execute the tests, which leaves more time for the team to specify new test cases. With test automation, you also must take into account that the test cases are automatable, maintainable and have many returns on investment. The decision of what test cases are candidates for automation depends on several choices, like risk classifications and business value.
Tip 4: Logical acceptance testing criteria
During the release planning meeting, make sure the acceptance criteria are captured and added as logical test cases to the PBI. This will help the team to understand and clarify the discussion. However, more importantly, help testers be involved at the early stages of the software cycle. You might think this is a very small tip, but it's very successful in getting testers involved in a sprint.
Tip 5: Accounting for unfinished sprint items
End-to-end testing is not an agile-specific testing practice; it's a common sense testing practice. This testing is seen as a challenge in agile environments because systems under development aren't always ready for end-to-end testing. Not every service is finalised to test the complete end-to-end business process, and when the system is ready, there isn't the proper amount of time to rerun all of the end-to-end tests. Scrum solves this particular problem of not being compliant on the definition of done at sprint finish, by defining ‘undone work'. The ‘undone' work is the part that will need to be completed at a later stage. ‘Undone' work is added to a product backlog item named ‘undone work', so it accumulates and correctly reflects on the Release Burndown graph. While this technique creates transparency in progress towards a release, the ‘inspect and adapt' in the sprint review should also be as accurate as this transparency.
The fact of the matter is, how much effort your organisation invests into testing and automation will ultimately govern how successful you become at delivering a releasable piece of software at the end of your sprint, says Schoeman.
26 August 2015: Article by Mandy Schoeman of Scrum Solutions