Recruiting Test Automation Engineers

Introduction

Test Automation is often a complex, time-consuming job. Its success depends on many factors such as planning, designing, wise use of tools etc. But as in any software project or for that matter any project the most important deciding factor for its success is the people.

Recruiting bright people, motivating them is always a challenge. What makes it more difficult for Test Automation is the nature of the work. In a typical software development organization you have 2 different groups namely Development and QA. Test Automation is an area, which lies in between these two groups. An ideal test automation engineer needs to have some experience in test planning, test case authoring and also needs to have programming background to design and develop test automation frameworks, test scripts etc.

Let’s try to see what problems you could have when you recruit a person whose background is either totally in development or QA. The problems and solutions mentioned here most of the time applies when you have to form a test automation team by recruiting people from your existing development and QA organizations either temporarily or permanently.

Software Engineer as Test Automation Engineer

For the sake of this article, Software Engineer is the one who is involved in design, development of software. He generally does unit testing of his code, fixes bug found by QA but beyond that is not involved in testing activities.

  • Developers typically consider Test Automation or QA as a secondary job. A developer with such a mentality may join you because of the circumstances but he never has his heart in his job. He is always looking out for the first opportunity to jump out of this.
  • COTS [1] tools used in Test Automation are not up to the Developer’s expectation. For e.g. the IDE or Debugging tools in Rational Robot are primitive when compared to Visual Basic. This can be frustrating because it hampers the Developer’s productivity.
  • The main reason to recruit a developer is to take advantage of his programming background. But an unmotivated and disinterested person may not do a good job defeating the very purpose of his recruitment.
  • If the development Managers are volunteering people for your group or they have been forced to give up some people it is very likely that they are going to give you their average engineers and not the best. By average I mean both technically as well as soft skills. Even if this did not happen and you were given the best people it is quite possible the engineers will feel otherwise. There is a good chance that this folks may feel they are victim of office politics or otherwise.

QA Engineer as Test Automation Engineers

For the sake of this article, QA Engineer is the one who writes Test plans, Test cases and executes the Test suites. He does not have any programming background and is generally involved with black box testing.

  • These are the folks who feel threatened by the very word ‘Test Automation’. It is well known fact that Test Automation can augment but never replace manual testing. This needs to be communicated to them clearly.
  • A few QA Engineers with a little programming experience may see this as a golden opportunity as a stepping stone to becoming Software development Engineers. There is nothing wrong with this in theory. Practically you can’t run your test automation project with this kind of people mainly because
  • These people do not have the experience to build a technically sound and solid framework for test automation. To build a software product you would always want highly experienced bright people on board so same logic applies here.
  • Test Automation like any other software is required yesterday. With very tight schedule and budget, you cannot afford a lot of luxury.

Possible Solutions

  • If your test automation project is getting staffed from the Development, let the Software Engineers know how important this activity is to the company. If possible get them involved in test tool selection because these are the people who any way will be using it.
  • If Software Engineers are being recruited on a temporary basis, let them clearly know the plan. Tell them how long they will be involved in this and what exactly they will do after it.
  • Clearly communicate that the performance reviews will be based on their work and their contribution in test automation will be treated at par with their contribution to the product development itself.
  • QA is a customer of your test automation effort. They are the one who will be running and executing your scripts on a daily basis. So it is not a bad idea to have an enthusiastic with a little programming background to be involved in design and scripting. The advantage with this is that he can be the person who can maintain the scripts and trouble shoot little things that may come up during test script execution. The other advantage is it gives QA a sense of ownership and responsibility in test automation project.
  • If you have a choice recruit from outside. When recruiting from outside you have a choice of recruiting a candidate who has a profile matching with software engineer but you could be very clear in defining job responsibilities. An internal software engineer transferred to your test automation group can be more vocal in his dissatisfaction with his new job.

Finally

As seen above people are crucial then technology. Recruiting smart people is critical to your test automation project. Keeping them motivated is more challenging. If your tools are not up to the mark you can live with it, take frustration on your vendor, force him to give what you want or switch to another vendor. But you can hardly do any of these with your team.

1

Rajesh Kanade (

[1] Commercial off the shelf