Improving an organization's competency in automated testing requires skilled engineers - explore the options with pros and cons of each.
Improving an organization's competency in automated testing requires skilled engineers - explore the options with pros and cons of each.
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.
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.
Pros
Cons
Organizations can look straight to their existing developers to take on automated testing responsibilities.
Pros
Cons
Hiring new staff to fill automated testing needs is always an option.
Pros
Cons
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.
Pros
Cons
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.
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!