This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
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.
Co-author, with Lisa Crispin: Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009) www.janetgregory.ca
Joined: Jul 11, 2001
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.
Joined: Oct 29, 2008
Thanks Ilja and Janet for sharing your views and experience. I really agree with you both.