After working for many years in the software industry, almost always using a methodology resembling Scrum, there are certain tensions that I've come to believe have no good solution--at least--I've never seen them solved elegantly.
One of those tensions comes from manual quality assurance. When sprint backlog items need to be manually tested by dedicated QA people, there is simply no clean way to do it in my experience.
Here are some of the issues that I've seen repeatedly:
- QA does not have time to test items where the development work is completed late in the sprint
- QA people are sitting idle for the first few days of the sprint with no completed development work to test yet
- If a bug is found, there is no time in the current sprint to fix it
Here are some attempted remedies that I've seen:
- Let's build some slack into the sprint for the developers so they can complete their development work with X days to spare at the end to allow time for QA
- Let's have the developers "work ahead" of the QA people, as in, the development work that we say is "done" within one sprint is actually tested in the next sprint
And here's where those remedies fall down:
- Inevitably, there is pressure to work more items into successive sprints, and development work starts creeping over the false "deadline"
- We end each sprint not knowing what is actually "done", and any bugs that are found have probably already been merged into whatever common branch the developers work from
QA people are in a really tough position as they are always sort of passively pressured to not "hold up" the sprint. They know that everyone wants to see a clean sprint where every item is signed off on by QA by the last day. And the double whammy is that they get heat when bugs are found in production.
This is one of those essential tensions in Scrum-based development that I've come to accept is not resolvable. I have never seen manual QA fit neatly into Scrum.
As I see it, there are two options to break the tension:
- Do manual QA, and abandon sprint-based methodologies (try Kanban, for example)
- Use a sprint-based methodology, and avoid manual QA (some teams fully automate testing)
