Be honest with yourself – is your agile implementation really just waterfall in disguise? If you aren’t testing as you go, the answer is probably yes. Too many companies often approach agile as “waterfall without documentation”, leaving QA until the very end while reaping the short-term wins of staying on schedule. That would be great, except for one thing…
Agile was created in part to prevent the big, painful errors that can occur with waterfall implementations, where bugs written early but discovered late were really expensive to fix, both in time and money.
With agile, development occurs in tighter, more rapid circles, but those circles need to be complete. Testing performed by the end of each sprint ensures that bugs that could affect other parts of the product are caught and taken care of throughout the development cycle. Timely QA is critical to the success of any agile project. And if you do it right, testing won’t impede your process, it will accelerate it.
Where does your company stand on testing? If you can say yes to all of the following, you’ve got a true agile QA mindset:
1. Your team is cross-functional (yes or no)
Teams using a sequential development process like waterfall are slowed down by handoffs; programmers finish programming a feature before handing it off to testers. Cross-functional teams make handoffs very small and very often – agile’s tight, rapid circles. Your teams integrate QA into the process early and often in order to deliver the working software expected of an agile implementation at the end of each iteration.
2. You know “done” means more than “developed” (yes or no)
Ideally, each two- to four-week sprint should produce software that’s deployable, meaning testing has been completed just as it would have been with a waterfall deployment. You don’t view development as the finish line; sprints are scheduled so testing is complete when the sprint is. That way you minimize people touching something that doesn’t work in the next sprint.
3. You trust the process (yes or no)
Agile isn’t a silver bullet, but it is fundamentally different from what we thought were best practices 10 years ago. Acceptance of change versus rigid specifications. Self-managing teams instead of top-down managers. Collaboration versus silos. And it provides a definite framework that shouldn’t be cherry-picked by companies who aren’t comfortable with switching from traditional development processes. You implement the full agile framework, not your own brand of “agile lite.”
Don’t find yourself in a situation where developers are pumping out code without integrating QA every step of the way. It may look like agile, but it won’t succeed like it.
Download our ebook: Breaking QA Agile Bottlenecks.