Jan 3rd, 2011
Functional testing code is more often than not treated as a second class citizen. Delivery teams tend to ignore problems with test code over a period of time, and worry more about test results. This leads to poor code quality and bad test architecture, which in turn hurts the maintainability of a test suite. Its this negative feedback cycle that a team should be worried about. In my opinion, treating test code as responsibly as we treat functional code fixes this.
Understand the importance
The greatest benefit of a robust automation suite is the ability to deliver quickly, even continuously, with a known state of software quality. Given that business today demands quicker delivery of software to production, it seems quite imperative that teams take the one big block of code that enables them to do so very seriously.
Complexity
Lets face it, writing an effective and maintainable automation suite is not an easy job. Just like writing production code, it needs thoughtful design and care. Test infrastructure design is an ongoing process, and just like functional architecture it needs continuous re-design based on functional and non-functional changes. An ill-designed suite is a waste of time and money (no surprises there), it also influences decision makers incorrectly. You should be asking (some of) your best people to work on it.
Expertise
There are two parts to a maintainable functional suite, the framework (test infrastructure) which defines a DSL, and then the tests written using that DSL. The drawing below shows what I mean by this division.
Dividing coding responsibilities based on the lines above is quite necessary. Developers are your experts when it comes to writing frameworks and maintaining them. Testers are really good at writing intentions and maintaining functional sanity. In fact with this virtual ownership division, testers become customers for developers, which distributes responsibility quite elegantly.
Ownership
If developers don’t write functional tests, its imperative that they are not super-motivated to fix them when they fail as new features are added/amended. Having different owners of different parts of code not only increases cycle time, it also reduces the quality of feedback that the developers get from automation.
Work definition and process
When we write functional code, we tend to have well-written narratives, which have acceptance criteria, and are treated well. When writing the framework for the automation suite, or a new functional test, such narratives should be well defined and the same workflow should be maintained. Any work done on functional tests should not become a secondary process for the team. Such treatment de-prioritizes work on functional tests at the outset itself, and should therefore be avoided.
Conclusion
My conclusion here is that people who are skilled to write production code should design and write test infrastructure/frameworks, while analysts should write test specifications, as they are best placed to do these. And also, work on functional tests (stories etc.) should be treated as mainstream functional work.