distributedlife

Last year I had an experience working with four project teams as they tried to deliver 5 software products composed of 30 services plus UI components.

The way I attacked the problem was based on project priorities; the four project teams had overlapping release schedules but there was a rough order. So we focused on each project’s services in that order; testing and retesting as needed.

If we had respite from the number 1 priority we focussed on crucial services deemed so either via their importance or the number of consumers.

We were also trying to test our services as enterprise services.

We failed to get the level of quality we hoped for; in the end business signed off with no concern of quality. Something I’ll talk about another day.

Part of the issue was that as the projects approached the integration environment (for release) the number of new builds that were available was phenomenal. One project team had a stupid build process that would recompile and reversion all their services every day regardless of any change. Naturally they provided no documentation so we couldn’t tell if we should ignore that service build.

We didn’t take each and every build but the time it took to retest the services was more than we expected. The execution was automated but the analysis of each fixed defect and adjusting of existing test code still takes time.

This is what led me to change my approach to service testing.

What we do now is take a breadth first approach. We attempt to register some coverage aganst every single service operation before we retest any existing service.

Raising a defect and having it fixed but untested is better than having nothing tested at all.