January 13, 2005 - What is Agile Testing ?

A conversation on the agile-testing list made me think some more about the two types of testing that I blogged about in TDD and Agitation.

Historically, testing has always been about finding where the software breaks. In fact, when we talk about the qualities of a good tester we quote anecdotes about how "she was able to break my program in 3 minutes" or that "he found 27 bugs when running on Linux with Apache". In other words, testing was about finding bugs. Testers would get rewarded for and take satisfaction from finding bugs.

It seems to me that agile testing is more about keeping the bugs out than finding the ones that are in there. The (automated) tests that we write are more about showing that the software works the way we expect than about finding where it breaks.

I am not claiming that agile testers should not attempt to find bugs nor that pre-agile testers never write tests to show what works. My claim is more modest. I am claiming that agile thinking has introduced a change in emphasis.

Rather than make universal claims, I'll talk about my experience.

In my pre-agile days, developers would bang away on the code until they considered it done. Then they would throw the code over the wall to QA to find the bugs. QA's first task would be to find the places where it would break. They'd submit a whole bunch of bugs which developers would fix. This cycle would repeat until they couldn't find any more.

Testing now happens closer to the developer in space and in time. Testers design tests to show that the software works as expected. The developers and testers work together to expand the set of cases that works. The bugs should never get introduced in the first place.

In the old days the conversation might have gone something like this :

developer : Everything works.
tester : C is broken
developer : fixed C
tester : E doesn't work with X
developer: fixed E with X

and so on until the tester can't find any more bugs.

These days, it would go more like this :

developer : A is done
tester : A works
developer : B is done
tester : B works

and so on until every case works.

My boss, using terminology from mathematics, calls this *For All* thinking and *There Exists* thinking.

*For All* thinkers look for the general rule and then search for exceptions.
*There Exists* thinkers look for one special case after another until they have found them all.

This deal-with-one-case-at-a-time philosophy shows up everywhere in the agile approach to software development. We design systems one story at a time. We write code one test at a time.

Agile thinking is *There Exists* thinking.


Posted by Kevin Lawrence at January 13, 2005 06:13 PM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/135


Comments

Man, you should define first what is agile testing?

Posted by: hanip on July 1, 2005 06:28 AM

it ok but we want the exact definitation of agile testing.

Posted by: basant on April 12, 2006 11:44 PM

The notes given on Agile Testing was qiute impressive but as it has been told by the author that "Agile Testing is not about finding where the software breaks rather its about finding where the Software works" can you please explain this point in detail. As far as I know that software testing is to find where the software might breaks.

Posted by: Rakesh Kumar on August 17, 2006 10:17 PM

Perhaps we can agree that software testing is about discovering the boundary between /it works/ and /it does not work/?

Where do you start to test? Do you define the boundary from ths inside or the outside?

Posted by: Kevin Lawrence [TypeKey Profile Page] on August 18, 2006 08:07 AM

I would like to thank you for giving some response to my comments at the first place.
As all know that Software Testing is to discover, where the Software works and where it does'nt. But I would like to know more about Agile testing. Yes we define boundray from Outside conditions. And if possible can you please give me some website address which explain more about Agile testing.

Posted by: Rakesh Kumar on August 18, 2006 10:24 PM

Hello,
Looks like you are off the track,
I haven't got any clue on what is Agile testing as heading indicates.

Posted by: Kots on September 8, 2006 06:33 AM

still cant get what agile testing is based on all you've said

Posted by: agatha on November 23, 2006 07:02 AM

Agile Testing to me, seems as if giving a hockey stick to a blind man and asking him to play and win. If this is Agile Testing, then how do we differentiate in BlackBox and WhiteBox testing.

Aren't we doing the same in Agile.

Posted by: Nippun Gupta on November 30, 2006 07:41 AM

Hi Every one,

I was wondering if some one could tell Me the best method for testing (generally Speaking). I am familiar with the V-model Methodology, but I noticed testers use agile

Posted by: OLA on December 5, 2006 12:56 AM

Wonderful page, this added to my knowledge

Posted by: Kamran Shaukat Ali Khan [TypeKey Profile Page] on December 5, 2006 10:04 PM

hey, still i donot get properly

i am tester, like to apply agile methods


pls reply me by mail

thx

Posted by: jay on January 8, 2007 07:52 AM

What is Agile testing was the question......You never actually gave an answer,hence i'm still lost

Posted by: Yem on January 15, 2007 10:01 AM

I would like to thank you for the notes given on Agile Testing. But I would like to know more about Agile testing.

thanks
srinivas

Posted by: Srinivas on January 18, 2007 05:59 AM

agile testing is more about keeping the bugs out than finding the ones that are in there. The (automated) tests that we write are more about showing that the software works the way we expect than about finding where it breaks.

guys read this again, it will help you.

its a wonderful article

Posted by: prateek on January 25, 2007 08:48 AM

Post a comment




Remember Me?