Agile Demands a Holistic View of Testing and Automation
Are you or your team struggling to transform your traditional testing methods, techniques, and tools in the context of an agile culture? Are you running to catch up with automating tests? Do testing and test automation continue to be an afterthought not incorporated into sprint planning? Is there still a sense that testers do functional testing and developers develop?
As I work with teams, I’m troubled by these examples, and others, that indicate we still have some work to do in expanding our mental models of testing and automation in the context of an agile mindset. I often hear, “Help me find ways to get all of my functional tests automated,” “How can we complete nonfunctional testing within each sprint?” “Coach me on getting developers to … (fill in the blank),” or “Tell me which tools are best to use in an agile environment.”
These are not bad questions—they deserve some thought—but I respectfully assert that these are the wrong questions, or at least questions that should not be the primary focus of the discussion within an agile environment.
In agile, the accountability for the right level of quality delivered at the right time belongs to the collective team. The team should embrace the best skill sets of each contributor and plan for quality and testing at every step of the release and within each sprint. And the tasks of verifying and validating are just as much a part of the sprint plan (and each sprint) as the stories that implement the user requirements.
The team should think holistically about the testing and automation strategy, plans, and tasks. I’m a firm believer that automation is a key element of any successful agile team. Operating with speed, agility, and excellence simply cannot be sustained without a sound automation strategy.
Let me expand on that last point, thinking more holistically. Rather than continuing the traditional thought of “Testers do the testing,” the collective agile team must think broadly about what testing needs to be done and what the most beneficial areas are to automate for the overall release and within each sprint. The greatest value, highest risks, or significant pain points should be addressed first, with this work assigned to anyone who has the expertise to do it.
This means that automating functional testing may be a lower priority than getting a unit test framework in place and a unit test created, or that implementing static and dynamic analysis may be more useful than spending lots of time on nonfunctional testing, or that automating the build process and getting some automated story test in place might be a higher priority than automating regression tests, or that automating the provisioning of environments or test data may be crucial.
All these decisions are context-dependent and must be made by the collective team. The critical change in thinking is to look across all the verification, validation, and automation work and decide what’s most beneficial at any given point in time.
