I was saddened to see that a meetup group that I managed for over two years was coming to an end because there wasn't anyone who wanted to take on the leadership role. When I started at a Northern Virginia startup as QA Manager I was tasked with taking on the leadership role of the DC Agile Software Testers (DCAST) meetup. When I took over we had 25 people and when I left the group two years later we had grown to a robust 450 and had developed a reputation as a place where QA professionals could meet to learn how they could be successful in an Agile environment.
I've always said that QA is the last to come around when organizations move towards Agile. Early on in my career in Agile the QA leaders would tell me 'yeah you guys develop however you want and when you are done, then we'll test'. The notion that QA couldn't test anything until everything was done (though in reality it never was) was strong. The feeling of power in finding defects that were typically not defects but mis-interpretations of requirements was palpable. The force was strong with us then. (cue the light saber sound).
With DCAST I saw quickly that the people who were coming didn't understand how they could engage in the process and more importantly they didn't understand how they could deliver 'quality' without having the entire feature delivered for testing. Iterative testing just didn't compute.
There are many things that QA teams need to understand in order to be successful in Agile. Some of the key elements include:
- Automation - For QA this needs to be a key focus of development. Automation builds what I call 'progressive regression'. Instead of thinking of regression as the final end to end activity, look at it as a growing entity. With waterfall development and more manual focused testing, you get an opportunity to perform a full regression test potentially just once at the very end of the development cycle. This leaves little time to deal with defects that arise from your testing. With automation and continuous integration you are effectively performing a regression test of your developed features every night.
- Behaviour Driven Development (BDD) - The two-pronged effort to quickly develop and manage your test automation suite utilizes example based test development like BDD as your test acceptance framework. What BDD does is ensure that the entire team is reviewing the acceptance tests that will ultimately be developed as part of the automation suite. This process ensures highly contextual user stories that clearly define the behavior of the feature and keeps everyone focused on exactly what needs to be developed (nothing more nothing less)
- Parallel Teamwork - With the use of BDD, QA can develop their automation code while feature development is in flight. If the teams are working from the same story specifications then when the code is checked in the automation should be able to run with few errors. This is a key process to develop in order for teams to deliver quickly. By not having parallel efforts, teams will typically fall into the cadence of having automation developed in the next sprint. Once you go down this road you will typically see automation efforts begin to fall further behind as QA will start manually testing in order to 'stay on top of testing'.
- Sprint Management - QA teams need to work with their team to ensure that work is being delivered throughout the entire sprint. A common problem teams face in Agile is that we fall into the 'mini-waterfall' process where developers deliver the features in the last day or two of the sprint. This leaves very little time for QA to perform ad-hoc and manual break testing along with fixing any automation breaks that have occurred once the code is checked in.
- Zero Defect Policy - This is key. Teams need to develop a working agreement that enforces a zero defect policy for new feature work in a Sprint. This means that the team does not receive credit for any stories that can't be closed out with zero defects. This focus ensures that the entire team is focused on delivering quality.
- Quality is EVERYONE'S responsibility - There is no such thing as 'toss it over to QA' in an Agile world. Hey Developers, you have to help test if you deliver something late. Don't let your software engineers tell you that they don't test. All great developers have to be good testers ( you know TDD kind of focuses on writing tests). The entire team is responsible for quality not just your test engineers. Note - QA Managers this concept in no way removes the need for your existent, rather like Engineering Managers your role changes. You should actually have time to be strategic and plan out future testing platforms and approaches for your team.
I'm glad to have led DCAST as it provided me an opportunity to help QA professionals grow their understanding of the activities and process all good Agile teams exhibit.