testing and Agile

One of the problems regarding how to test in an agile development team is the area of system integration and I include performance testing as well. It is all well and good getting the designers to write tests for their pieces of work, but who can write the tests that cover those units being integrated into a working whole?
The plan we have come up with, and one that seems to work reasonably well is to have the integration testing done "one sprint behind" the development work. Of course, it is mostly automated scripts so that regression testing can be performed easily.
The difficulty of writing tests whilst the code is being developed can best be seen when trying to test user interfaces. It is quite possible that the position of buttons, selection lists and text areas changes whilst the program is being worked on, so writing tests that check for the operation of those items is best left until the work is done.

Testing in an Agile development team

I have been reading up on Agile development over the last few weeks, and one thing that has concerned me when looking at Xtreme Programming is the apparent lack of dedicated testing staff. Indeed some proponents feel there is no need for any specialists at all. The view is that each developer tests their own unit of code.

But, there is much more to testing than testing individual units. There is integration and system testing as well as performance, resilience and load testing. However, the developers feel that they are not skilled enough to do anything except unit testing.

I was happy to come across a couple of sites that to me at least, put forward a more balanced approach to development and testing. One of them, testobsessed.com I have found to be particularly helpful.

Discussion and Consultation

On a training course in Software Testing, and the topic came round to how testing staff should handle the process of informing the developers of the faults that had been found.

Suggestions ranged from "Here, you idiot, look what I've found in your code" to a more diplomatic "I have found a problem here and I am not sure if I have done the wrong thing in my test or there is a problem in the code. Can you help me?"

We all agreed that the more diplomatic way was best, as irritating the developers would not be the way to get their cooperation. I fell to thinking at the lunch break that this is not limited to dealings between developers and testers, but is applicable to all human interactions. I read a book some years ago called "Consultation" by John Kolstoe where he dealt with this and other aspects.

If in a discussion, the people offering the suggestions then detach themselves from those ideas, they will not become offended when the ideas are challenged. In that way it should be possible to reach an agreement without anyone being upset. It is only by holding on to "my idea" that I would become annoyed if it was not accepted.