Improving an organization's competency in automated testing requires skilled engineers—just like when improving software engineering and craftsmanship competencies. It's essential for organizations to understand the options they have for building up teams staffed with great automation engineers.
Many people see the phrase “automated testing” and immediately think about user interface or functional testing. Automated testing, depending on the organization’s needs, can be much, much more than that and could include automation tasks for testing security, performance, accessibility, system integration or APIs, unit testing, database testing, etc.
Regardless of the scope of what automation is needed, organizations can use the same basic approaches for growing competency across their teams. Every option must consider the pros and cons.
Educate and Train Existing Manual Testers on Automated Testing
If an organization has existing "manual testers," one option is to work with those testers to teach them automated testing skills. Growing tester skills requires, in most cases, teaching testers the most basic fundamentals of software development: how to write simple classes, understanding build/compile/interpreter chains, libraries and dependencies, etc. Testers will also have to learn the fundamental tenets of software craftsmanship to build out maintainable test automation suites.
- Existing testers are already domain subject matter experts. They know the organization, its users/customers, and they deeply understand the system under test. This expertise is a tremendous value for the organization.
- Those testers are already there and working. There’s no delay in finding them, and training them in automated testing can be part of their everyday work task. They can continue adding value while learning. Investing in an organization's people sends a clear, positive message to those people: they're valued. This investment is a significant motivational step that can lend a big morale boost to everyone, not just the testers.
- Training takes time and effort. Time is both direct (away in classes, e.g.) and indirect (productivity decreases as testers incorporate new, unfamiliar skills in their work).
- For many different reasons, some testers may not be able to make the transition into effective coders. Testers rarely understand software craftsmanship principles. There is a significant risk of an unguided team building unmaintainable, low-value test suites.
Have Developers Write Automated Testing Suites
Organizations can look straight to their existing developers to take on automated testing responsibilities.
- Good developers know how to write concise, maintainable code. This skill directly translates to automation suites built around high-value, maintainable test scripts.
- Developers know the system under test. They understand how to leverage internal APIs and other capabilities as part of writing valuable test scripts.
- Not all developers are "test-minded." While most developers do well at happy path testing or basic boundary testing, many lack the experience and mindset of more in-depth testing. They'll need guidance and time to develop these abilities.
- Time is needed for developers to build expertise with the test tooling.
- Some developers may resent doing what they feel is low-value, unimportant testing work.
Hire New Automation Engineers
Hiring new staff to fill automated testing needs is always an option.
- Gain competence without having to spend time training or growing existing staff.
- If an organization’s hiring processes are sound, then newly hired staff will have substantial knowledge and experience.
- Hiring experienced automated testing staff reduces the risk of poorly written test automation suites.
- Good automation engineers are hard to find. VERY hard to find.
- Due to the previous point, the organization may have to raise salary expectations to attract great candidates.
- On the same line, finding great new automated testing staff can take a long time.
Outsource For New Staff
Outsourcing engineering efforts have long been an attractive option to management. It's certainly an option, albeit not for all organizations. Outsourcing may involve offshore, remote staff, or it could involve hiring subcontractors to work more directly with your teams.
- Outsourcing means fast, easy acquisition of skilled workers without spending time and money to train or hire them.
- Outsourcing eliminates, or at least vastly reduces the management effort of finding, training, and change management for employees.
- Outsourced workers almost always lack subject matter expertise in the organization’s domain and systems.
- Outsourcing to augment staff means you are essentially adding expensive employees.
- Remote outsourcing, particularly offshore workers, adds additional delays and handoffs into the process.
- Expectation and communication mismatches for outsourced work introduces new risks.
- Outsourcing always brings additional friction into the picture.
A Hybrid Approach
Some companies mix the approaches. For example, you could bring in contractors while training the employees, with the intention to have a limited contract engagement of nine to 18 months. Or bring in a coach or other expert to “skill up” the team, again on a limited basis. Perhaps you hire one automated testing engineer full-time. It’s hard to list the pros and cons of these, as there are so many combinations.
I will add that it’s naive to expect such engagements to be anything less than full-time for anything less than six months. Further, sometimes contract automators do their work without getting the organization’s team prepared to take over the suite of automated tests. The world of software development is littered with stories of similar messes.
My colleague, Matt Heusser, told me that he has been brought in to consult in organizations that have made multiple attempts at this short-sighted strategy (work he turned down), with enough management turnover that people forgot the attempt had been tried before.
Carefully Consider Your Options
All the options above allow organizations to build up their test automation expertise. Not every option is available for every organization; in some cases, teams may not have the choices they'd prefer.
My preference, built up after years' experience working with all these options in many different organizations, is to build up expertise by training and growing manual testers into team members able to contribute to automated testing efforts. It is time-consuming, it can be extraordinarily frustrating, but the long-term payoffs are huge. Challenges motivate good testers, and I've always found them appreciative of the organization taking time to invest in them. Moreover, being able to apply the testers' subject matter expertise straightaway into test automation suites is a considerable benefit.
Some testers might not make the jump. Matt Heusser, mentioned earlier, points out that putting people in a position where they cannot be successful creates an obligation for management. That means finding places for manual testers who cannot make the change. These testers might remain focused on exploratory testing. Alternatively, the organization might work to transition them to other roles, like customer success. To paraphrase Peter Drucker, organizations that fire large numbers of manual testers are punishing the workers for the long-term, consistent, systemic and shameful failures of management(*).
That said, you need to determine what works for your organization. Weigh your options, approach the decision as an experiment and adapt as you move forward!