Test-creators should maintain

I’ve had the opportunity once to work on a project where test-creation and test-execution were two activities performed by two entirely different teams. Interestingly this produced the problem of considerable test rework being required by the maintenance team on all newly created assets. The problem was that, while the tests were fit for purpose and passed on day 1, there always were enough slightly fragile components which gave newly created asset an embarrassingly short life-span. This was the result of some genuinely overly-complex actions, reliance on particular dates/times, and assumptions about existing data.

For a long time the execution team was responsible for these assets, but it became increasingly obvious that the creation team were not improving on the quality front. If anything they/we were getting worse over time, as we continued to build test upon test using our slightly dodgy implementations.

We ended up changing the ownership of assets by introducing a warranty period. In order for the creation team to appreciate and learn the onus of fixing broken assets remained with the creation team for several months after the script was declared ‘ready’. While productivity took a  hit initially, it wasn’t long before we ended up with considerable time-savings. Knowing what pain was in store resulted in a real shift in culture when creating assets. The amount of code-reuse increased considerably, and the overall maintenance effort decreased. The future tests we created were built with the knowledge of what went wrong previously; that makes for a pretty solid foundation.