Testing is an important step in the delivery of any piece of software. For those of you that have not written code or been an integral part of a software project, a project of any size rarely jumps from that idea directly into executable code without a few hiccups (call ’em whatever you’d like… explicative deleted, defects or problems). There are two basic ways to find these gremlins, 1) testing (including reviews) before implementation, or 2) letting your customers find them after implementation. The former is better for the long-term health of the company. In Agile, testing is still testing, however there are three major differences. They are the Agile mindset, the Agile context and differences in roles.
In the Daily Process Thoughts June 7, 2013, we discussed the distinction between Big “A” and little “a” Agile. The major distinction between the two was a value focus versus a process focus. Agile at its heart, while not eschewing process, is about doing what is needed to deliver the most value possible. The Agile mindset that is the core of little “a” agile provides the basis how testing will be performed. Testing in Agile embraces the philosophies of incrementalism, teams, delivering functionality that can be implemented at the end of each iteration and customer satisfaction. Those relatively simple concepts provide significant structures that form a mindset for Agile team members. Incrementalism is described through the cadence of sprints. Team structures change when they embrace the ideas of self-organization and self-management. Implementable functionality means that all tasks not just coding or testing must be done at the end of the iteration. A focus on customer satisfaction ensures that the functionality has not only been tested but meets expectations. In order to accomplish these goals testing has to be integral to the development process not just a gate or barrier between stages.
Testing in Agile feels different because of the context in which testing occurs. Several of the attributes of Agile projects affect how testing is typically approached. First, the duration of an short iteration and repetition (cadence) creates time constraints. Constraints define what can be completed during the iteration and put pressure on teams to embrace solutions, such as automation. Short iterations that are repeated are fundamentally different than the phases normally found in waterfall projects in which activities are far less constrained. Second, the concept of an evolving backlog means that building test cases is continuous and dynamic rather than a specific event. In waterfall projects requirements are created once at the beginning of the project followed by testing planning. The process creates events rather than continuous evolution of requirements and tests. One of the outcomes of public planning and public demonstration at beginning and end of sprints is to apply peer-enforced schedule compression on the team. This compression means that to be able to complete the iteration testing cannot wait for to be the last step as in waterfall methods. Rather, it is a set of tasks that either happen in parallel, are directly integrated into development tasks or are automated to run when development is not occurring (generally in the wee hours of the morning). The context affects how we test but not the goal of delivering quality software.
Who does the testing and the role of the trained Quality Assurance (QA) person is impacted by the team concept. In Agile, everyone on the team is responsible for delivery and the lines between who is a tester and who isn’t is blurred, whether they are a QA, coder, Scrum Master or a Product Owner. While it is never a good idea for someone to test their own code (except for unit testing), everyone can test in an Agile team. One of the exciting changes in many Agile teams is that the QA role becomes more of a quality coach, helping everyone understand how testing can deliver a better product. The coach role becomes even more important as the barriers between roles begin to erode and involvement in the testing process spreads throughout the team, so that everyone learns to perform testing activities more effectively.
Testing is the processes required to find and remove defects from functionality before that functionally is delivered into production. What is testing in Agile? Having been a tester and test manager, my experience is that the definition is the same for an Agile, waterfall or iterative project. What is different is the Agile mindset that embraces concepts of incrementalism, done and team delivery. Testing in Agile also is affected by the attributes of Agile projects such as sprint cadence, a dynamic backlog and compression, which changes how testing is addressed. The QA role that once would own testing and take the hand-off for testing now must become a leader, and as a leader, both perform testing and help fellow team members to perform the role as well. Testing in Agile is still all about delivering functionality, however the path to deliver has changed to meet a new paradigm.
Authors Note: When the question of Agile testing is first broached, I usually need to ask whether the question is “what is Agile testing?” or “what is testing in Agile?” The difference is more than just semantic. Both are important questions, but the answers are different. This week we will explore both.