AUTOMATION ROLES

.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns

Pattern summary

Test automation needs many different skills, and people to take different roles.

Category

Management

Context

In a large organisation, there may be a team of people each with different skills and taking different automation roles.
In a small organisation, or where there is only one person currently working on automation, that person may have to take on all roles and have many different skills.

Description

There are different roles within automation, requiring different skills, ranging from the test automation architect who would design the overall TESTWARE ARCHITECTURE to a tool technical specialist, who would solve and/or report technical problems with the tool, install tool updates etc. There would also be test automators who would write and maintain scripts for testers to use.
Of course you don’t necessarily need to hire new people, but then you should make sure that people GET TRAINING in whatever is appropriate for them (e.g. tool vendor courses or internal training for your own standard ways of automating your tests)
In practice you will often have team members slip into different roles, but it’s important that the roles be clearly visible to the whole team.

Implementation

You need a pool of very different skills:

• Test automation engineers must have a developer skill set to be able to work with tools, do scripting and eventually to implement or maintain a TEST AUTOMATION FRAMEWORK and a LAZY AUTOMATOR mindset is definitely an extra bonus!
• Testers must have a profound knowledge of the Software under Test (SUT) and must be able to write good automated test cases but do not necessarily need to work directly with the tools
• An automation architect must make sure that your TESTWARE ARCHITECTURE is built to be long lasting and easy to maintain
• Depending on the SUT you may need various other specialists such as database administrators, network or security experts and so on. You should plan them to be available to help the team (PLAN SUPPORT ACTIVITIES).
• Last but not least you will need a TEST AUTOMATION OWNER, that is a champion that controls that test automation stays "healthy" and keeps an eye on new tools, techniques or processes in order to improve it.

Potential problems

Remember that skills alone don’t make a good tester (or test automation engineer). Also look for the right attitude and take care that team members understand and value each other.
If you have a team of people, they may be full time on automation (FULL TIME JOB). You may need MANAGEMENT SUPPORT to achieve this.
If you cannot have all the skills on the team all the time, try to organize a pool of experts whom you can ASK FOR HELP if required.

Issues addressed by this pattern

INADEQUATE TEAM
NO PREVIOUS TEST AUTOMATION

Experiences

Added by Jen Leger:
At our company we have divided the test team in two - manual testers who focus on test planning, test design, test execution, defect tracking, and test reporting; and automated testers who focus on developing/improving our test automation framework and writing automated test scripts. Just like the manual test team - our automated test team has a career path from junior, intermediate, senior, and lead. The junior level resources main responsibility are developing, maintaining, and troubleshooting the test scripts where as the senior resources are involved in the architecture of the framework, making sure it is constantly being improved and built on, communication and education, and planning. However, our two teams work very closely together and education between the manual and automated teams is key. If the test manager on a project does not understand what test automation can do for them, they will not plan for it in their schedule and there will be duplicate testing effort. The manual test team must understand what the automated test team needs in order to automate a test with enough validation points for the test to find issues if there are any. If those validation points are not communicated to the automated test team they will be missed. Our automated testers do not have training in test design - it is up to the manual testers to provide the details. When I recruit test automation resources I always look for someone with development background first, and test background an asset. This has worked out well for us - our test automation framework is very robust and our scripts are easy to maintain. We follow coding standards, do code reviews, track defects for our framework in JIRA, and keep our code in SVN.

The following is a breakdown of common activities for our test automation resources and the percent of time allocated to each:

Design/develop test automation scripts + framework: 60%
Test the test automation scripts: 10%
Maintain the test automation scripts: 5%
Code reviews (test automation code): 10%
Support for manual test team (kick off scripts, analyze results, communicate results, planning, etc): 15%

If you have also used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.

.................................................................................................................Main Page / Back to Management Patterns / Back to Test Automation Patterns