Many teams have either transitioned to Agile development or are in the process of doing so. It appears that transitioning a QA team is not an easy task. It requires fundamental changes in mindset and focus.
I have interviewed quite a lot of QA professionals and it became apparent to me that many in the QA community still operate in Waterfall fashion inside Agile teams. When asked exactly how they test differently in Agile, the majority of candidates answer by explaining the Agile process and how they are involved from the very start of the development process (meaning story grooming, Sprint planning, etc). It is encouraging that that aspect of Agile is well understood, but what is troubling for me is that for many it really ends there.
When it comes to the actual testing, it is the old fashion approach, depriving the whole team of the core benefits of Agile. In fact, failure to transition to Agile testing can turn testing into an obstacle because they won’t provide the quick feedback required.
Here are few signs that can help you recognize if your QA is Agile or not:
- Sprint test plan – if your QA writes test plans for sprints, then they are missing a lot. The focus should be on working software, not documentation. With some teams following weekly Sprints, test plans are really not productive, especially if you are following Kanban, where the priority of stories can change on a daily or even hourly basis. Further, the definition of the test plan is broader than a bunch of stories planned for a Sprint.
- Waiting for developers to finish coding – Agile testers work closely with developers, pulling code and testing iteratively, and at the same time pushing automated tests in parallel. Some even practice Dev-QA pairing to speed up delivery.
- Testing is one Sprint behind – the QA team is actually one Sprint behind so the normal Sprint is dedicated only for development. This is a mini waterfall that can lead to the following: context switching for developers who are already in different Sprints; defects that cannot be identified and fixed there and then; confusion in the definition of done and when the demo should happen.
- Automation is one or several Sprints behind – this is a sign that your team is building only one level of automation and therefore they need the code completed before they can write any tests. This approach leads to several unpleasant situations (poor unstable automation, less benefit from automation, less coverage, a huge backlog, less participation, etc). Obviously, you need working software to run automated tests, but there is so much you can do in parallel (implementing utilities, stubs, placeholder tests, setup/tear down functions, much more). You really should be wiring things up when you get the completed code, not starting to implement
- Test management system – if your team is using a traditional test management system, then you are disconnecting the QA from the developers; a minimum set of manual scenarios that cannot be automated may be tracked in such test management systems, and that should be it. QA should be spending time refining acceptance criteria rather than writing test cases in a system almost no developer will look into.
- Lack of interest in technology stack – Agile testers know and understand the underlying technology very well, including the code base, unit tests, and the build process. A typical black-box attitude is not helpful and this type of QA doesn't pick up issues at the right time.
Transitioning to Agile testing is a process that needs to be managed, and practical training and coaching are required. Do not expect the switch to happen automatically; this is a fundamental change and there is always a tendency to fall back to old habits.