I have been working on Agile projects for years know and I have seen it evolving over the years. I have made mistakes in the past and always learnt the Hard way. I thought it will be worth sharing my experience and learning in Agile testing.
Mistake 1: Not getting involved early enough in the Sprint. So often I have seen teams falling in this trap. And consequences are expensive – QAs not getting involved early fail to provide important feedback on the requirement. Its that missing perspective which can add lot of value early on. Viz looking at the testability of the requirements, and collaborating with different stakeholders to gain valuable context in to the story. I can go on here and talk about so many obvious and non obvious cost of not doing this right.
However, there is one aspect worth talking about – Why do teams fall in this trap , where QAs are not getting involved early enough? I am highlighting someone of them from my experience
- Catching up on testing from previous iteration – Its a common symptom where teams leave QAs to deal with the stories delivered at the fag end of the iteration. And I personally think that leaving testing problems to just QAs in the team is a sign of broken process. Team should look to rectify this and come together to try to get all stories to done (Properly ) before the end of the sprint. That may require people from cross discipline need to roll their sleeves up. Doing this will enables team to have a greater disciplines and control over their iterations and most importantly avoid that ‘catch-up’ mode problem.
- Testing as seen outside the scope of sprint – And again I have seen it often in projects, where progress is shown/claimed based on development complete stories. However in true sense it does not matter if story is dev complete, Half QA done or not started at all. In Scrum/Agile model stories are considered Done only when all required phase of work is done or in other terms definition of done is met (DOD I will referring it as DOD in rest of my post). Coming out of this mindset helps team to focus on real value of work rather then claiming false sense of progress.
- Loose definition of Done – I spoke about definition of done in previous point. Now how important is it to have definition of done and what consequences can it bring if not well defined? I am not going to talk about what DOD is and how is it defined. DOD is a yard stick against which a requirement is said to be measured and upon successful meeting the criteria, it is said to be DONE in the process. DOD usually have attributes like – Acceptance Tests Passed, Exploratory Testing done, No Red builds, NFR met etc etc. So in first place not having a DOD does not help team in measuring themselves against some standard quality tools. So, it does help teams to be consistent with their approach in terms of delivering different piece if functionality. Result is obvious – Inconsistency in Quality and Communication breakdown which then leads to poor product.
- Other scenario being not following DOD religiously for various reasons like delivery pressure, assumption of quality or may be anything else. which results in similar consequences as mentioned above.
I will continue with other reasons on my subsequent post.