“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” (Mosher’s Law of Software Engineering)
As long as there is software programming there will be software testing.

In today’s Agile and Continuous Integration world I guess we could add automated software testing to the list of perennial must haves. While this is generally acknowledged it is sometimes not as widely appreciated that the test automation suite is also a product in itself. This “test automation” product demands a different approach all the way through and not treating it as such could invite the risk of failure. Among the early indicators that the effort may be “at risk” is the composition of the test automation team. Here’s what we think an ideal test automation team should look like – taking the product approach into consideration.

1. Get the business involved: A key input into the early planning and design of the test automation suite (or test automation framework) should be the business need. What is the product under test trying to achieve, how it is slated to evolve, the features and the use cases are all critical pieces of the puzzle that will reveal the shape and size of the automation framework when put together. This is especially important in the context of Agile since the sprints are so short. Thus one key member of the crack test automation team should be a representative of the product or the business.
2. Designing it: There is the software architect who will design the core of the automation framework – as we have mentioned the need is to look at this as a product in itself and design the architecture keeping scalability, agility and maintainability in mind. Given what the framework has to achieve a key member of the team will be the test architect – what tests to automate and at what stage they should come into play is all within the wheelhouse of the test architect.
3. Technology talent: There is a significant technology element to the automation suite and this means the team should ideally have an expert on the platform / technology of choice. Your choice may be Selenium or it may be QTP or something else. In each case understanding what can be achieved with the technology is essential and perhaps even more essential is knowing the limits of the technology of choice and building a “Plan B”.
4. Build it: Developing the test automation suite is a job for, well, developers. That being the case it is essential to staff your team with developers capable of translating the vision of the architect into a working suite using the technology available.
5. Maintaining it: Like we’ve mentioned a few times – the automation suite is a product. That implies it needs to be supported and maintained over its useful life cycle. The need, therefore, is to make adequate provision for bandwidth of resources for these tasks even after the initial suite has been created and deployed.
6. Putting it to work: What good an automation suite that doesn’t get fully utilised right? Last but definitely not the least among the members of your test automation SWAT team are the testers who will actually put the suite through its paces in the real world. The aim is to test more, test faster and go-to-market faster – it’s the testers who will achieve that.

Conclusion:

It’s important to know that each member of the team has a key role to play but in the end none of them can do the task alone. Like legendary basketball coach Phil Jackson said, “The strength of the team is each individual member. The strength of each member is the team.” He may have been talking about the idea test automation team actually.