GM Financial is driving the evolution of legacy QA roles

The quality assurance (QA) role in software engineering has traditionally been a siloed part of the development lifecycle. However, as development becomes increasingly agile, organizations have asked themselves: Is there a more effective and efficient way to improve code quality other than throwing it over a wall to a segmented, specialized team?

Thomas Sweet, Vice President of Cloud Services at GM Financial, is helping his organization answer the question. Having started his career in QA testing himself, Sweet sees how today’s QA practice stands at a crossroads. In the long term, he believes (as does much of the industry) that the function of QA will need to be absorbed by DevOps.

What this means to individual QA analysts is up to them. But Sweet is driven to provide as much upside as possible to those who want it.

In this episode from the first season of the Network Disrupted podcast, Sweet shares his empathic way of re-skilling his QA team with host and BlueCat Chief Strategy Officer Andrew Wertkin. That includes embracing automation, catalyzing development skills, and dedicated time for learning. And a complete re-thinking of how success is measured.

QA must ‘shift left’ toward automation

Wertkin is known for pointing out that many of the goals today’s technology leaders must pursue have historically been mutually exclusive. Under the old waterfall method of software development, speed necessarily came at the expense of quality and vice versa.

Just like Rich Penkoski at Deloitte sees a shift away from traditional project management, Sweet sees that today’s business landscape demands that technology leaders bake their cake and eat it too. For Sweet, that transition is all about “shifting left,” or moving towards more automated methods. In order for QA to improve their quality, they must go faster—and the only way to do this is by automating work.

As a result, Sweet says, QA must adopt a modern software development mindset. Instead of judging success by finding errors, for example, QA ought to focus on leveraging automation to reduce the introduction of errors in the first place.

A supportive way to shift team balance

When Sweet started at GM Financial, the capital finance subsidiary of automaker giant General Motors, the company had five automation engineers and 130 QA analysts. Now, they’re at 60 QA analysts and 40 software developers. He sees the balance continuing to swing towards development.

Sweet has facilitated this shift with a two-pronged strategy that he shared with Wertkin:

1. Don’t backfill those who leave. When QA team members leave, he doesn’t look to backfill roles. Instead, he opts to hire more software developers who either served in QA roles previously or are fresh out of college.
2. Help those who want to stay to do so. With a “pretty intense” internal training program, Sweet is able to train his QA team members to move into more of the software developer and automation role. He’s also big into reinvesting in his team and creating a culture of continuous learning.

A one-hour-a-day approach to upskilling

Sweet wants to make sure he’s providing a way for his team members to get better in their roles—or to transition into new ones.

So, Sweet encourages his team to spend an hour each day learning something new or working on innovation. It’s a practice the leadership at GM Financial has blessed as well.

For the QA experts, this might be learning a new language. For the software developers, it could be gaining new certifications.

However, Sweet recognizes that making the leap from being an expert in one role to being a beginner in another can be daunting. He wants to be sure he’s striking the right balance for his team between encouragement and leaving space for independent career-related decision-making. Sweet reminds himself that it’s up to a team member to bring their desire to learn to the table.

All he can do is provide them with enough awareness to make an informed decision about the future of their career and the opportunities to evolve. Sweet explains this in more detail in the clip below:

Measuring success by overall value delivery

It’s hard to measure developer productivity objectively.

Originally, Sweet measured his team using Google’s Four Keys open-source project. This is an approach that measures performance through four DevOps metrics:

• Deployment frequency,
• Lead time for changes,
• Change failure rate, and
• Time to restore service.

But Sweet felt like this wasn’t quite the right fit. Since he was working towards a more unified engineering team, he thought that the metrics should be more about delivering overall value, not specific benchmarks.

His goal is to use metrics that reflect the whole, interwoven process, from development to QA to monitoring. He explains this further in the clip below:

However, some successes are impossible to measure in any way except a good story. Recently, GM Financial’s Cloud Center of Excellence asked to borrow some of his team members. A few months later, they asked to borrow some more. Sweet was impressed by how much these team members learned and saw how they were exercising new skills.

He knows he probably won’t get these team members back, but that means he’s done a good job. He’s taken people who were once in a legacy role and opened up a world of opportunity for them.

Catch the full episode on Network Disrupted below.