Discusses the need for a clear cut exit criteria for a planned feature and how a test is one way to go.

In the project I am currently involved in, we release software once a month. We have currently released the first increment of work, and one of the activities we start after a release like this is to start some more formal tests of the software, performed by the project’s test lead and test engineers.

These tests discovered defects that really shouldn’t have made it in to the release at all. These defects revealed that we missed to implement some details in the requested functions for the release; things like missing to display a column in a list view etc. These were things that were clearly described in the user stories and in the tests performed by the testers. All the info needed was there. How is it then that we missed to implement them?

We did our best to avoid these misses within the project. All team members; software developers, leads, testers, and documenters sit together all the times. We have also made sure to involve all team members in all aspects of the project from day one so that we all have good knowledge about why we’re doing the project, how we’re designing and developing the software, and when things are ready for release. Besides delivering software once a month we also work in one week iterations, making sure to deliver a new chunk of functionality every week that can be demonstrated to team members and project stakeholders. We practice TDD to get a good adaptable design and to find all glitches before we hand stuff over to test and project stakeholders.

With all this in place the formal testing done by the testers should just be a formality, right? Well, the tests were quite successful. We found very few defects in the software delivered by the project; there were no major crashes or completely misunderstood requirements. We were pretty close to the target altogether. But what made us fail to implement some parts of the requirements?

The problem was that it was up to each pair of developers to decide when they were done with a feature. From time to time a pair would proclaim a feature done in the stand-up meeting one day only to report that they “performed some cleanup” of the same feature at the next meeting. It is so rewarding to be able to go up to the project whiteboard and be able to move a post-it from the “in progress” field to the “done” field. It is quite addictive really. Seeing the burn chart move closer to the finish line gives you a warm sense of accomplishment that sometimes make you miss a “minor detail or two” as you are so eager to step up to the whiteboard and get your reward.

To prevent this, we need a clear cut criterion for considering a feature ready. From this release on, we make sure that the test is available before the feature is implemented, both as a manual and as an automated Fitnesse test. The idea is that implementing a feature with the tests ready before hand should be like taking an exam and have the answers available before you start.

As a developer you have to make sure that the test for the feature in question has passed before you can consider it to be done. This will both give feedback on how well the implementation matches the expected result as well as verify that the tests make sense.