Agile Testing: Getting things Done!

For some years now I have been working as a tester in agile projects. In our projects we are trying out new ways to integrate testing into the development cycle and ideally to offer a complete project solution to our customers. In my vision the perfect offering would be to create working software with each development cycle, which has the actual ‘Done’ status. Not only ‘Done’ from a development point of view, but actually ‘Done’ from the customer perspective as well.

In practice we have reached this point already, but for a paying customer testing is a responsibility you just don’t put in the hands of strangers. So an independent test team in a separate location is put in place that makes the final judgment. In the project I am currently working on, we do unit-, system- and functional testing within each development cycle and no functionality will be released without thoroughly acceptance testing it first. Doing a complete acceptance test seems like a bit of overhead, since our client will do its own acceptance testing after we have delivered. But it has definitely proven to be beneficial.
We are working on a project for a large railway organization in the Netherlands and the requirements analysts working for the client, initially did not see the added value of an extra tester in the development team. But after some time they became used to being questioned on all the details of a requirement, making them clearer and less ambiguous along the way. After I gained more understanding of the system this even started to become two-way traffic. The analysts will now come to me to discuss and brainstorm new features.
In the beginning the work done by the clients test team was very intensive, but because of our extensive testing efforts this seemed to be almost useless. The number of issues coming from the customer is negligible and severity of all issues is minor (the amount of issues has been <10 with each two week release). Currently the client still has its own acceptance test team in place, but time spend on testing our software has been reduced to a minimum, this way gaining resources that can be used on testing other applications.
When I first started out, even our own developers were skeptical about my added value. But along the way they got comfortable with my role in the project. We found out that by thinking about the testability of a feature and working out the test fixtures together, problems with the chosen technology or the requirements are found in a very early stage, when adjusting strategies is still very simple. Also the understanding of the client’s wishes grows during this process, enabling all of us to do a better job. I think that as a tester I am very focused on the entire system from a functional viewpoint, whereas most developers are focused on a specific part of the system that is affected by their work and from a more technical perspective. Needless to say, combining these views is of great value for the overall quality of the product.
I believe our approach is working because of our efforts to work with the customer rather than for the customer. This idea is however entirely build on trust and is I guess something people need to find out in practice, before they will actually dare to rely on it. But with more real life cases to back our strategy, we can soon fulfill every project manager’s wet dream and create high quality software without the hassle of the additional time consuming acceptance test phase.