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 URL for this entry:
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?
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
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 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
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.
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