Testing in Agile: How to Get Started

There is a lot of interest in organizations around a transformation to agility. However, the focus is usually on agile development, so it may not be clear how software testing is done in agile.

Let’s take a look at a common situation where an organization transitions to agile but leaves testing behind. Here’s how you can make testers part of the transformation, too—step by step, because this is agile, after all.

Suppose you have served for many years as a software test manager and gained a professional reputation at your previous employer, but now you are a recent hire in your current position at a company that is newly becoming agile. You have, as always, understaffed test teams, with two or three testers working with half a dozen or more developers. Five such teams form a division.

When it comes to test documentation, you and your team have something in the vault, but there have been no updates to the legacy test plan for quite some time. All in all, test documentation is not the focus of daily testing activities.

Your testers are keen to deliver—they hate being regarded as bottlenecks—but they’re not all on the same page about understanding requirements, defining testing deliverables, or acting like team members together. What needs to be delivered and how is only discovered during the sprint, often with rushing at the end.

The teams are working in two-week iterations, and testers keep being told to wait until there is something to test. They get the software late in the iteration, naturally failing to finish testing by the end of the cycle, so there is constant overtime. Testers are being held solely responsible for defects going live, dampening the already weak morale. In the review ceremonies, "Done, but some more testing is needed" is a regular phrase.

It’s not a nice place to be. What can you do to improve the situation?

First of all, you need to change your expectations regarding your position. From now on, you are not just an enforcer of testing methods; you will still do that, but the focus will be shifted toward an agile approach. Quality should not be checked in the last phase only, but built into the product from the first steps.

And instead of acting as a protector of the testing team, you need to let them self-direct. As testers progress, you have to be able to let them go, reducing check-ins to a biweekly or even monthly one-on-one meeting. Your focus should be to work with key stakeholders along the value chain.

You have at least two layers of responsibility:

• Focus on changing the mindset and capabilities of your testers, enabling them to become real agile team members
• Instill the quality mindset in stakeholders

Let’s focus on your testers first. They are accepted by their team members at various levels; there might be someone deeply embedded, and another who is just there, and a third tester who is reached only via ticketing systems. They all work overtime during the second half of an iteration. They are not really part of the planning sessions at that time, either, and when they can attend, not all testers are comfortable in a deeply technical planning session. But there is no slack time to learn any new, modernized approaches or techniques.

Your first action as the new test manager should be to go and see their daily activities. You find some activities and processes that can be improved, but you also should initiate some short meetings with the testers so you can gain an understanding of their pain points and set the appetite for change.

Make the first change you implement as a team a small one easily within possible reach, so that you can get a quick win and motivate the team to continue. Your protection and support will be needed for the next few months to reinforce the agreed-upon steps for the following changes, but make sure that the initiative is owned by the people who shall realize it.

These series of changes eventually will form a situation where test productivity has enhanced, resulting in less overtime. You’ll have the responsibility to protect this newly found slack time and use it well, helping testers invest in career development—and not just through testing training.

One of the principles of the Agile Manifesto says that face-to-face communication is the most effective way. To embed your testers more in their respective teams, you have to enable them to speak the same language as the developers. This means taking foundation-level courses on Java, .Net, databases, Apache, Linux, and anything else their teammates are working with. Make source control available to them, and reward their growing capabilities on technical aspects.

Now, the goal is not educating junior developers. We are here to build solid partnerships in the development teams by making testers technically capable, equally regarded team members.

A nice byproduct, of course, will be that the number of test automation scripts will jump up, as will interest from developer peers. You will begin to see full automation coverage as part of the definition of done, and enhanced testers becoming more and more embedded in their teams.

Now you can move on to instilling the quality mindset in other stakeholders.

Good product owners and ScrumMasters are hard to find. With the organization having just undergone an agile transition, you hopefully have people in these positions, but they will probably still be adapting to fulfilling their roles. Your product owner is driven by the quantity of delivered functions. Your ScrumMaster may be an ex-senior developer or an outside hire, and their aim is to satisfy (sometimes unspoken) requirements.

Sustainability, a potentially shippable product, technical excellence, and responding to change are all familiar phrases from the Agile Manifesto, and your expertise on quality assurance is needed to inform these aspects. Consequently, it’s important to create and maintain a good partnership with product owners and ScrumMasters so you can ensure quality remains top of mind.

The cornerstones of communication around quality in agile delivery are the definition of ready and the definition of done.

The definition of ready (DoR) is a quality contract between product owners and Scrum teams. Once defined well and followed, it lays the foundation of focused, quality-enabled development activities in the development backlog.

Your product owner should be happy to suggest a good chunk of functionality feasible for a sprint. But there are a lot more layers of quality assurance to be included, so it will be up to you to champion the values of performance, security, testability, and more when it comes to the DoR. A test engineer’s experience is also a valuable asset during product backlog refinement and sprint planning where the DoR is sure to be actively referred to, so make sure that they are present as well.

A misleading, igrnored, or nonexistent DoR leads to confusing and unproductive situations. For instance, if your development team is waiting for external dependencies to be solved so they can begin work on a sprint backlog item, then programmers will be rushing to finish it and testers will then be rushing to test it. If the technology to be used is unclear or missing from your DoR, your team will fall back to programmers searching for a good way of implementation for much of the iteration, then throwing over something to test, making life waterfall-ish again.

Give peace of mind and an opportunity of success to the development team with backlog items refined following a well-maintained DoR.

The definition of done (DoD) serves as another quality contract. If well defined and followed, it will serve your drive toward deliverables with quality insights.

Just like the DoR, when defined up front, the DoD eliminates frustrating and time-wasting discussions later on about when to leave automated testing out, or if we can make space for a new "must-have" function in the forthcoming release. What's written here is mandatory, so the cost, time, and resource needs must be determined and accepted before development begins.

Yes, there will still be some defects escaping to production, but when that happens, make sure that the DoD is regularly reviewed so you can keep the quality gates well maintained.

Understanding agile quality assurance is a continuous journey, but it yields great results along the way. It all starts with a first step, so here’s your roadmap.