How Walmart Global Tech is revamping the QA role
By: Joon Park
Tags: Leadership, Engineering

What it means to be a QA engineer

The quality assurance (QA) role in the context of software engineering evolved quite drastically since the boom of consumer applications.

In its core sense, QA engineers provide some form of confidence in the software as it evolves. In its simplest sense, this means manually testing the software to ensure no regression issues are found. As software continued to evolve from something as simple as a command line tool to multi-billion dollar ecosystems, so did the role of the QA engineer.

Even with the birth of automated testing, there were still large gaps to fill with manual testing as the automated tests didn’t provide enough confidence. Imagine you are responsible for delivering updates to an application that generates millions of dollars daily. Would you purely place your trust in some automated tests? Naturally no, because it’s a better investment to hire resources to manually test and catch issues than to face the consequences of actually releasing major bugs to users. Through this reasoning, businesses continue to hire QA engineers to manually test every iteration of their product. We’ve lost sight of our goal in search of temporary relief.

Putting the QA role back into perspective

There shouldn’t be a need for QA engineers to manual test as part of the job description. Every developer should be a QA. Every developer should write tests wherever they see a user scenario, even if it’s not something they wrote. Every developer should hold responsibility for the application they help build. The first step is to discard the antiquated notion that a developer should build and a QA should test. Have you seen anyone write their first line of console.log(“Hello world”) and never execute it because they didn’t feel the need to test to see if it works? The concept of increasing manual testing capacity is a sham, and we need to drive the change to build great products with confidence, quality, and at scale.

Redefining the QA role at Walmart Global Tech

In the past couple years, various engineering teams within Walmart Global Tech have been experimenting with the QA engineer role with the ultimate goal to redefine its role to exclude manual testing. We couldn’t immediately remove all manual testing as there would be nothing to fill the gap for what was currently being manually tested. Instead, we tried shifting bandwidth to create more automated tests, rotating QA engineers between products and teams, removing QA engineers entirely for smaller greenfield projects, and many other variations. There have been mixed results from every experiment, and they all lacked a common keystone: a decisive decision from leadership. We needed to formally allocate resources to building high confidence automated testing suites with the intention of deprecating the need for any manual testing. Any leader would agree with increasing automated test coverage, but it’s been more of an implied expectation rather than a concrete directive that impacted the developers.

Recently, with the start of many new large scale projects and the leadership of our CTO Suresh Kumar, we have doubled down on high confidence automated testing. For some of the QA engineers, their focus has shifted to improving the infrastructure and tooling to automate our testing. For others, they are participating in a pilot program to transition into developer roles, opening up a vast set of new opportunities for their careers. For developers, their focus has also shifted to integrating tools to automate testing between every stage of development. This has given our organization an opportunity to improve our engineering at an even greater scale.

Structuring the QA to dev transition

We planned the QA to dev transition to take approximately 2 months such that starting with some basic JavaScript knowledge, a QA engineer can become a self-sufficient developer that can pick up tickets from the backlog and know how to “figure things out” from others and online resources (that’s a skill too!). For our pilot runs, we paired each QA engineer with a senior developer who acted as a mentor and guided the mentee in the right direction.

The mentor should identify key points of learning in whatever areas make sense for their team. For us, our mentees already had basic JavaScript knowledge, so we picked a few JavaScript fundamentals and decided to focus more on our specific JavaScript tools and libraries, such as React, Next, and GraphQL among others. In total, we picked around 30 topics: 10 for fundamental JavaScript, HTML, and CSS, 10 for JavaScript tools and libraries, and 10 for networking and performance optimizations. From these 3 segments, the mentor created a milestone project plan for each segment with the input of the mentee. In my case, we decided to build a clone of the Apple AirPods Pro interactive scroll experience.

For the first milestone, the mentee would build out the basic HTML, CSS, and JavaScript to render the images as you scroll. For the second milestone, the objective was to convert the first milestone into React, Next and other relevant tools such as TypeScript. For the last milestone, we added custom GraphQL and REST endpoints as well as some performance optimizations.

Mentor expectations

Throughout these milestones, the mentor’s primary role is to guide the QA engineer through the plethora of subtopics they will have to learn in order to complete the projects in approximately 2 weeks per milestone. The mentor should also set up regular 30 min sync ups with the mentee (I recommend every other day) and longer working sessions for cases in which the mentee is stuck on a particular topic. At the end of each milestone project, we review the mentee’s progress with their manager and the transition program manager. This gives the mentee an opportunity to demo the hard work they have put in to their projects and also allows the managers to objectively track their transition progress.

Mentee expectations

For a smooth transition, it’s ideal for the mentee to work on the milestone projects during downtime from their regular duties as a QA engineer. The mentee should review and read about the topics for each milestone, then plan how they would incorporate each topic in their milestone project. To further facilitate the milestone demos, the mentee should also create a document detailing each topic and how it was implemented in their project. Throughout the milestones, the mentee should also maintain the mindset of only reaching out to the mentor when they are uncertain of their direction or if something cannot be answered with a quick search on the internet. This isn’t to discourage the mentee from taking guidance from the mentor, but to encourage putting themselves in the shoes of a full fledged developer and learning things through experience rather than hand holding.

In the regular sync ups, the mentee should show the mentor the progress they have made and if they face issues that can’t be solved easily with a few searches, such as how to optimize image preloading for images shown on scroll, the mentor should aim to spend no more than an hour helping the mentee understand the root issue and guide them to the right solutions.

Closing thoughts

After these milestones, I can confidently say that my mentee has the fundamentals in place to be a junior developer. My mentee was eager to dive into 5 story point features that could exercise the new skills they had learned in the past weeks. I was more than happy to welcome them as a peer in my team. More importantly, it seemed that they already had a solid foundation of web development and just needed a push to pursue this career transition.

I can’t wait for our QA engineers to continue their transitions and for our developers to further embrace their sense of ownership for automated tests in the same way they feel ownership for the features. This doesn’t mean the QA engineer role will be phased out, it just means that we’re finally realizing that developers own writing the tests, while allowing QA engineers to focus on building the tools to support that.