Even in Agile, what has a beginning must have an end

By 8th February 2013 Agile

When working on an Agile project each iteration must be completed before continuing onto the next. No matter what the nature of the work being carried out is, when something is considered as completed, it must really mean it is completed. Apart from having features that depend on others, each completed feature must be in a state that is ready to be deployed.

The most common assumption is thinking that when the development part is done, the project is actually completed. The feature or module would not have been tested and styled in a way that the product owner or sponsor will accept it. It would only mean that the coding part is ready. How about testing it? What about the design and visual aspect of the product? Is this what our client wants?

Once I was working on a very large scale web based project. Being a large project, the team that was recruited consisted of a number of developers and testers. Obviously, the more you are in a team, the harder it is to conserve working harmony between all the members.

That said, everyone was assigned his or her own piece of work and was given clear instructions by our project manager: do not move on to other modules without having had your current work signed off.

We kicked off various modules in parallel as is customary for large projects. But as we progressed, we realized that certain modules were dependent on others. I and the rest of the testing team were identifying a lot of missing functionality and bugs that could not be fixed at that point in time. Hence, these modules could not be completed unless their dependencies were. As a result, some of the developers got stuck and could not do any more. The continuation of the project was depending on the testing team.

Having to test unfinished work is definitely a no-go. We were unable to replicate all our planned scenarios as a lot of the functional aspects were missing. Most of the results wouldn’t match what was expected and a number of test runs were failing. All this was happening whilst having a lot of work considered as ‘completed’.

In the planning phase of the project, it was crucial to fully understand the functional requirements of each and every module. Then, all the work would have been designated in such a way that certain features would have been ready and signed off before more work that depended on them even started. In Agile projects, what’s done has to really mean ‘DONE’.  

 

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.

Leave a Reply