Test Automation Problems (3) – Resource Allocation
Parent page: Test Automation Problems
Resource Conversion
When starting up in-house Test Automation, companies often look for internal resources. While the benefits are obvious, there are some snags on this path.
Problems and impact
1) Converting manual testing QA resources to test automation
- Strong programming skills and technical mindset are mandatory requirements, and must be considered when choosing a candidate: either previous working experience in programming or strong academic knowledge combined with quick learning abilities.
- What must be arranged prior starting of test automation project: training on Test Automation principles as well as training on the specifics of Test Automation Tool
- Test Automation is a time-consuming work and it doesn’t bring immediate results (especially when starting from scratch), so former manual testers can not participate in the both activities without losing efficiency, therefore additional manual testing resources should be allocated for the project
2) Assigning developers to test automation
- What must be arranged prior starting of test automation project: training on Quality Assurance methodologies, including requirements and coverage traceability, investigation and reporting. In short: have to make developers realizing that testing is not data-entry, and Test Automation is not “happy path” automation!
- What must be arranged prior starting of test automation project: training on Test Automation principles as well as training on the specifics of Test Automation Tool
“Set-up consultants”
Another popular approach is hiring consultants to set up the process. However, the main problem would be giving up all the initiative as the beginning is the most critical part.
Points of consideration
- Make sure the consulting company is well-established with the proven record of services provided successfully. Success must be measured first by convenience in ongoing execution and maintenance of tests
- Distinguish Testing Tool consultants and Test Automation consultants. While knowing all the features of a particular Tool is important in implementation, the knowledge and experience on what and how to implement is much more critical
- A proven, experienced consultants will perform the investigation of Client’s needs, including specifics of Test Cycle, Test Coverage requirements, Timeframe and Turnover requirements. These must be documented along with translation of the requirements mentioned above into Test Automation Requirements, specific for this project
- Make sure documentation is provided and knowledge transfer sessions are conducted. Two important aspects must be covered: operations to conduct automated testing, and body of knowledge on maintaining existing scripts and creating new ones based on the framework provided by consultant
One response to "Test Automation Problems (3) – Resource Allocation"
Hi Albert, I like this summary. I’ve seen all three of these done in a way that failed. I think the points you make here may have helped to improve on these scenarios.
[Albert’s reply.
Hi Trish.
I appreciate your response and thank you for the examples]
1) Manual tester hired and told to learn automation. The strange logic by the manager here was “I learned German from a book and it wasn’t that hard, so she can learn Java from a book.” Automation was eventually abandoned.
[Albert’s reply. I guess, the point that manager missed is that learning German from a book didn’t teach how to write a book in German. ]
2) Assigning developers to test automation. This worked to an extent, but the quality of test cases was not as good as automation testers would have made them. The scripts didn’t hold up well against unexpected application changes and the choices of tests to automate were not always ideal.
[Albert’s reply. A more or less satisfying [project’s needs] example I’ve seen was programmers following requirements designed by testers for testing scripts. But it was expensive time- and resource-wise; plus filled with redundancies, as automated testing flow closely followed manual test cases]
3) Set up consultants. A consultant was brought in to create an automation suite for the test team, who were unfamiliar with the tool. He recorded a small suite of tests using the record and playback tool. The team ran the suite once at the start of the project, and then tried running it again at the end of the project – everything failed with errors that nobody could comprehend. The suite was quietly discarded.
[Albert’s reply. Unfortunately, such organizational fails are counted as test automation fails…]