Monday 27 June 2011

Test Automation: Let’s Break It Down

Whilst having a conversation with a friend of mine recently we got onto the topic of test automation. During the discussion on the topic they came up with the suggestion that if automation required a programmer to produce the code so that it could be executed, should a programmer not also be the person responsible for the creation of said code?

Now the person I was speaking to was not a tester themselves but it was precisely that thinking outside the box mentality that allowed them to come up with an idea that on reflection appeared to be a real no-brainer.

Why should the testers not be the ones to use their skill of working out areas to test, what to test and how? Likewise why should the programmers not be the ones who use their experience and their knowledge to produce the code to automate this?

As I had covered in my piece where I had examined what the real costs of test automation are, I raised the point that as individuals we most likely will only possess a single skill that we can truly consider our primary skill, our core strength, the area of greatest focus. To use the cliché, those who attempt to become a jack-of-all-trades often then become the master of none.

As such an approach that enables a development team to allow people to draw on their greatest strengths and areas of experience, an approach that through working together still produces the desired results, could potentially allow the team to amplify the quality of what could be produced.

How this could be broken up in terms of the development team could vary based on resources and skill sets within the team but where possible there could be the following groups within the team: the testers, the test automation programmers and the application/web programmers. Where resources are more limited the application/web programmers could potentially be used for the creation of the test automation suites.

In breaking the team up in to their core strengths it allows people to really focus on their responsibilities. It minimises the requirement for having a tester side track work they were in the midst of doing just to update an existing automation script or suite, causing them to lose focus and potentially overlook or forget something they might had otherwise covered.

It also reduces the risks created through having someone either less trained or focused on coding producing the automation code. As is often already the practice the automation that then requires testing could be still tested by the testers to verify that the intended functionality has been implemented (...and to ensure there is greater than zero degrees of separation between creator and tester).

Much in the way a good development team has testers working directly with programmers, in such an environment the testers and the test automation programmers would be even more intrinsically linked. As a tester often has an evolving knowledge of the product, its quirks and its re-occurring issues, they can feedback this knowledge throughout the process to the automation programmers. Likewise any feedback on issues encountered during automation could also be communicated.

This feedback loop will allow automation suites to continue to improve and provide more meaningful coverage without interfering in the responsibilities of the tester, will assist with reducing risks in the development process and through this approach allow all team members to really concentrate on their core areas and thus produce a superior product.