What is testing in Agile? It’s analogous to three blind men attempting to describe an elephant by the way it feels to them. Agile is difficult to define and everyone has their own perspective of what Agile is. When it comes to testing and Agile the rules are what you make them.
Agile is ideas about software teams working together with no details. SCRUM is a framework for managing software projects. Extreme Programming (XP) has practices about making the product and coding. Agile says nothing about testing. SCRUM definitely says nothing about testing. There is no role in SCRUM called Tester, QA, or QE! Extreme Programming comes the closest, but the focus of testing is on developer focused TDD (test driven development) through unit testing. The work of traditional testers is not defined by any of these famous practices or frameworks. We are making it up as we go.
While Agile evokes images of happy, self-directed teams working well together, there are problems. The Agile manifesto has been around over 10 years. SCRUM has also been around long enough to have been tried, failed, succeeded, abandoned, and tried again.
Two dirty words to describe the practices of any team are Agilefalls and Scrumbuts.
Agilefalls is a practice that badly mixes agile and waterfall. Scrumbuts is the famous descriptor coined by Ken Schwaber (co-creator of SCRUM) of people adapting SCRUM as a loose process to suit whatever needs they have. SCRUM is anything but a loose process. As the 2011 Update (available at www.scrum.org) says, “The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself.”
No one can tell you there is a definitive way to test in Agile projects. There simply isn’t a best practice here. The better practices for your team are going to be based on many things. Among them; how much you automate, to how you implement Lean and the type of documentation your team writes, to the definition of done. How you test and how much you validate will probably be left up to you! Here is where we come in. We asked some insightful thinkers to share their perspective on testing in Agile to help you put together a test strategy or improve the one you have.
In this issue, IBM’s Scott Ambler discusses the role of discipline in your Agile testing strategy; Pankaj Nakhat talks about the paradigm shift test teams must undertake for successful Agile projects; Ralph van Roosmalen looks at how to better organize and track the Agile process; I address the misconception that Agile is about speed; John Roets presents alternative office layouts that can promote knowledge sharing on Agile teams; Madhu Venantius Laulin Expedith examines aspects of traditional testing that must be unlearned when switching to Agile development; Gunnar Peipman reviews the book Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin; and finally, I’ll look at the manager-specific responses from our 2010-2011 global survey.
Whether a true-believer or late adopter, there is no arguing that the tasks test teams used to do in traditional projects are not defined. So, what do we do? In true SCRUM style, we try things. Hopefully we fail fast. To fail fast is to try something full-speed. If it works, great. If not, recognize it failed and try something else.
Testing in Agile projects is evolving. What we do, how and when we do it, is maturing. We need to constantly reflect on our practices. Keep what works, discard what does not. Share experiences and continuously improve. I hope this issue gives you food for thought and that other opinions and experiences help improve your practice of testing in Agile projects.
Michael Hackett
Senior Vice President
Editor in Chief
Is it pure coincidence that LogiGear is an anagram of “Agile org”?