One of the most common issues that I encounter with Scrum teams involves testing at the end of sprint. It is easy to say test as you go, or Scrum involves doing all the SDLC activities concurrently. Unfortunately it is often very difficult for teams to achieve in practice.
Successful Scrum teams work like this.
However teams that are new to Scrum will almost always try and compress a traditional waterfall approach into their sprint.
So their Sprint looks something like this.
At the end there is a mad rush to finish testing, and the testers are often working long hours to get the testing finished. This often leaves testers wondering if Scrum is such a good idea..
Without help a lot of teams stay in this state indefinitely. I have been to companies where this is still the norm and the team are at Sprint 20. Often at this point the testers have stopped doing regression testing because they can’t keep up. So now there is an unknown amount of work to do when the Product Owner wants to ship the software. Are we really producing Done features?
It happens like this. Each sprint the developers can produce this many features.
This works fine. In Sprint 1 the testers can easily test those features. Now in Sprint 2 the developers produce that many features again. However the testers also need to make sure that the features delivered in Sprint 1 haven’t broken. So now there is this much testing to do.
(You can see where I am going with this) Fast forward to Sprint 10
Can the testers still keep up? At this point someone suggests that they save regression testing until the customer wants to release the product. The problem goes away and the pressure is off. Unfortunately the team is now simply accumulating technical debt that must be paid, and telling a Product Owner that features are done when they have not been tested will result in a lack of trust when the regression bugs arrive.
There is a famous quote about Death & Taxes being life’s only certainties. I would like to add Test Automation to that list. The only way out of the problem that I have outlined is through ruthless automation of manual testing wherever possible.
Test automation needs to be a religion in the team. It should be in the Definition of Done, it should replace manual test cases, and it should certainly be done by everyone in the team.
One technique that is proving very popular with teams right now is Acceptance Test Driven Development combined with Specification by Example. They are topics for another post, but the crux of the method is to write the automated test before the code. More to come on this later.
I am going to be as blunt as I can. If your team is not taking advantage of automation for your testing, at some stage your testers will be unable to keep up. At that point they will either drop regression testing or quit from exhaustion. As certain as death & taxes.
Does your team suffer from the mini-waterfall problem? Need some help with Test Automation or ATDD? Get in touch at email@example.com