How is Agile testing different from traditional testing?
What do you mean by “traditional testing?” Maybe a better place to start is “What do you mean by testing?” For me, testing is a process of learning information about a software application to answer questions and so I can provide information that fulfills my mission to the project and project stakeholders.
To do that, I need to find out as much as I can about the application. Sometimes there are a series of documents prepared in advance that I can refer to. These may be business or functional requirement documents, design documents, possibly a business needs analysis or in some cases, it has been a collection of email messages that were cobbled together.
The information in those sources allows me to frame my clarifying questions to the document authors and discussion participants on exactly what they intend or what the meaning is. These clarifying questions, for me, mark the start of “testing.” I have not made a plan or a strategy at this point; however, I have begun to gain an understanding of the project at hand.
This understanding will allow me to plan more thoroughly how I will exercise the application. That is, it will help me ask the application questions that will get information to pass on to the stakeholders.
I know some people find the idea of “doing Agile” or “Agile Testing” a bit unsettling. How do you deal with things you don’t know about? I suggest you find a good source of information and start there. Learn about Agile, either from books or online references, or testing groups and conferences. If your company or shop or group is moving to an Agile environment, learn as much as you can about that environment before they “make” you.
Some people will look at the idea of testing in an Agile environment and say, “When does phase X happen? That is when we work on Y document, and we need that to write our test cases.” I suggest they consider what the purpose of that document is. Does that document do anything to really allow you to make test cases? Maybe that document is a consolidation of the information that was found in the “phase” before? Consider the underlying purpose of why you prepared those documents or went through the steps that you went through.
I had much the same set of concerns the first few times I found myself on an Agile project team. Think about the purpose behind the actions, and I suspect you’ll come to the same conclusion I did: The tasks that you need to do as a tester are not terribly different from one environment to another. The way that you gather information may change, how you document that information may change, but overall, the changes are not as significant as some people would have you believe.
This was first published in August 2011