Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Agile Testing

 
Mourouganandame Arunachalam
Ranch Hand
Posts: 396
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just read this definition for Agile Testing from the great wikipedia.

Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing. Since working increments of the software are released often in agile software development, there is also a need to test often.


My question is, when we open (released often to the customer) the testing as soon as the code is ready, will not increase the complexity of the development? Will it not create room for the user to think in multi dimentional on his initial requirement and keep on change his base requirement? I think this will lead to explode the initial requirement and ends with unmanageable project.

Just my thought......Any opinion or suggestion?

Mourougan
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mourouganandame Arunachalam wrote:
My question is, when we open (released often to the customer) the testing as soon as the code is ready, will not increase the complexity of the development? Will it not create room for the user to think in multi dimentional on his initial requirement and keep on change his base requirement?


Yes, if I understand you correctly, that is exactly what will happen. And that's a good thing - we will learn earlier what the user *really* needs. That puts us in a positition where we are able to produce what is actually needed, instead of what we initially thought would be needed.

I think this will lead to explode the initial requirement and ends with unmanageable project.


No, it's not unmanageable - it just needs to be managed differently. In fact, the idea is rather simple: you don't plan more in detail than the next iteration (the next one to four weeks). What happens after that is totally open to what you will have learned until then. (There is some less detailed planning for a bigger time span, but no commitment to details. Changing the plan then is not a big deal.)

With other words, requirements don't really explode - they just change, and change in priority.

Does that help?
 
Janet Gregory
Author
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We also have to remember that we are working with the customer right from the beginning. As testers, we question and try to make sure we understand the customers needs. We consider impact, and look for hidden assumptions. Programmers will question to make sure they can give feedback and encourage a logical way of approaching the requirements to take dependencies into account.

As a story is flushed out during the planning session at the beginning of an iteration, we can use examples to create acceptance tests that helps the team understand exactly what is being asked for. These tests become the basis of what is built and how we develop the rest of the tests for that story.

It sounds complicated, but it really simplifies the process. Expectations are clearly stated so the customer is hardly ever 'surprised' by what is delivered. They may change their mind because of what they see, but it is early in the process and not hard to adapt.

I hope that helps answer your question.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We once had a customer who already had spent two years with another company to create a requirements document for the system they wanted. Then they noticed that their money was running out, and that they needed some software quickly, so they gave us and our Agile approach a chance. We developed a plan on what features were most important to them and therefore should be developed in the first year.

We started with the most important and basic features and kind of "tricked" them into installing a first cut of the system after a few months. Once they had an installation, a couple of users actually started to use it. Halve into the project, the customer came to us and said something along the lines of "you know, while using the system we discovered that we could really make good use of feature X (which hadn't been mentioned at all until now). In fact we would prefer if you implemented that feature instead of what we had planned." Which we simply did.
 
Mourouganandame Arunachalam
Ranch Hand
Posts: 396
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ilja and Janet for sharing your views and experience. I really agree with you both.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic