Originally published in TestingExperience magazine of March 2009 issue and also on my blog at SQABlogs.com on { 12:48, 2009-Sep-8 } { Posted in Software Testing } { 0 comments } { 0 trackbacks } { Link}
In the last couple of months I have had many discussions, and many more arguments on the scope of Agile Testing in projects and the success rate of such projects. In most of these discussions, I feel that managers are trying to go for Agile testing by the half knowledge they gain from some not-so-authentic websites or through whatever they have learned from others.
I have attempted to observe and explore the five top-most reasons of failure in some agile testing projects and ways by which you can trounce these roadblocks.
1. Implementing Agile via traditional methodologies:
The biggest and most important reason of failure I have found is that people try to implement Agile testing keeping traditional methods in mind. They follow a waterfall, keep haphazard documentation, perform ad-hoc testing, listen to the project manager and fail in their testing. I have seen people telling me that agile testing is nothing but ad-hoc testing and they did not have to do any documentation. Well, I hope I know the reason they failed.
Further, there are Test Managers who believe in a no-strategy and no-plan for their agile project. Again, they are mistaken that an Agile project does not require any strategy or plan. One has to plan for an Agile Testing project. For example, Extreme Programming projects keep their planning, monitoring & tracking simple so that next steps can be defined and Project completion can be forecasted. The planning may include Test Driven development or Test First approach, Automated Acceptance Testing, Testing early and iteratively, Testing often and whenever required, Using methods like exploratory testing and finally following a context-driven approach to testing.
2. There are Separate Development & Testing teams:
..And that they are rivals as they are in traditional software development projects.
..and that testers should not spare Developers by finding and reporting each & every defect.
..and that testers should ask for each and every details from developers to test the builds otherwise they should tell them that the entry criteria for testing does not meet.
With these assumptions you cannot be sure of success in your agile project because agility asks for high level of collaboration and integration between developers and the testers. In some Agile projects you may not find any testers, as development teams prepare the automated Unit tests and Client provides Acceptance tests. As much testing is done before and during the construction phase, less testing is required during the End game.
Another important thing that our traditional, individualistic managers forget is, Agile is best succeeded in pairs. Whether it is pair programming or pair testing; agilistic groups work in pairs with the single aim of delivering quality product faster with their simple designs.
3. All we have to do is ad-hoc testing:
I was talking to one of the test leads and he was telling me about his projects. When I asked about the Test Strategy he was using for the project, he told me that it was an Agile project and all they have to do is ad-hoc testing.
How mistaken he was! I did not dare him explain the methodology as he was convinced of what he & his project manager were doing. It was not just he who thought agile testing is just performing ad-hoc testing. I have seen many experienced managers talking in these lines.
So what kind of tests we do in Agile testing projects? In his article at Dr.Dobb’s journal, Scott Ambler has suggested many testing types that can be performed throughout the agile life cycle. Some of these are Confirmatory Testing, Investigative testing, System testing and Acceptance testing. We do not have to forget the Automated unit testing that is an integral part of any agile testing project.
One may refer to “Testing Extreme Programming” authored by Lisa Crispin and Tip House to be acquainted with testing in extreme programming environment.
4. It does not matter who works in my team:
Here I am talking about the (over) confident managers, who claim that they can get the work done by anyone.
Indeed, Agile projects are the games of pairing and integration and require team spirit in all their team members. That is, not only your team members should be technically very sound, they should be sound socially as well. An Agile Testing project will fail if your team members are not socially communicative and have poor social skills.
Further, communication also plays an important role in Agile projects, as you do not have to play with heavy documentation as you do in traditional development methodologies. Here, all you have to do is to communicate, complete & deliver. Some Extreme Programming experts discourage having people scattered across, floors, cities or countries. They believe that face-to-face communication is more important to make the project successful.
5. All I need is proper requirement documents:
First of all, you are not delivering your project through some traditional development method, where all you need is bundles of written documentation of customer requirements thrown over the wall for the testing team to write their test plans and scripts.
Agile projects are different. They do not get you ferry load of requirement documents. You have an onsite Customer who has his acceptance tests ready and is clear about his requirements. He is available to give feedback and clarify acceptance criteria so that frequently delivered pieces of software remain in sync with what he wants.
As I said earlier, one of the fundamental principles of agile projects is that they need collaboration and integration. And this does not spare the customer too, because she is the one who is driving the project and defining the requirements. If your customer is bad, you will not be able to deliver
the good software.
the good software.
Basically, any project will fail if you do not follow the basic principals of the methodology you are using. All flavors of Agile emphasize on Collaboration, Communication, Integration, Simplicity, Respect, Feedback and Ability to adapt to the changing business requirements. If you miss any of these, your project may fail. The reasons of failure I have described in this article are not the only ones, there may be more reasons that can fail you. However, my experience is that by avoiding even these once, you can save your project.
Recent Comments