Transforming legacy quality assurance teams

Ensure the foundations are in place before jumping straight to automation

09 qa expert
Thinkstock

In “Legacy QA in the devops age: reskill them or release them?” I outlined areas in which the legacy QA teams can be reskilled to support a combined-engineering devops team, and potentially other teams in your organization. In this article, I present the first chapter of a general training outline that can then be modified for your needs, keeping in mind that both you and your QA team have a regular 40-plus-hour job to attend to.

Back in 2014, I attended the Society for Information Management’s Simposium event. In one of the workshops during a dialog session, the speaker asked an attendee who her biggest competitor was. After thinking for a few seconds, she answered, “The status quo.” It was a carefully crafted answer on her part to not name a real competitor, but her answer is also true for many companies and teams. Resistance to change can be strong, but as a manager you must motivate your teams to adapt and learn. Hiring and retaining talent is arguably a manager’s most important job, after of course the safety and security of the team. Retaining talent is not just retaining people, but retaining people who can support the business needs of today and the future.

Command prompt

The Linux readers are most likely cringing as they read this, but many Windows or Apple users are not skilled in, or have never used the command prompt. For someone who started using computers in the 1980s and 90s, command prompt usage was mandatory. But today, I see three-year-old children using iPads, so it is no surprise than many younger team members have never needed to learn it. Very few nonprogrammers need to edit the path environment variable these days, nor are they running system utilities or PowerShell scripts to create users in Active Directory. One mistake I have made is assuming that everyone on my teams knew it. It is best to take an anonymous survey first to get an overall view, and later identify those whose skill set does not yet include this to create a plan for them.

The command prompt is not that hard to learn. Provide some basic instruction/websites along with setting the expectation that though they may not need to use it today, they are going to need to know it to remain employed in many future IT roles. Remind them that though manual testing may never go away completely, there will be fewer and fewer roles available. Linux, cloud, scripting languages, and other technologies all rely heavily on the command prompt. As a manager, help lead your team and your company in the right direction and let your team surprise you with their success. They might like it once they find out how fast they can work by typing instead of moving the mouse.

Web skills

Many manual testers are great at interactively testing websites, but they need the next set of technical skills. Instead of referring to these team members as “404s,” help them learn what an HTTP 404 response is, aside from an insult. Teach the other responses and requests, page caching, the HOSTS file, TCP/IP, SSL/TLS, DNS, and whatever is needed in your environment. After this, teach the basics of XML, JSON, SOAP, and REST because many are testing web services through the browser but they don’t understand what’s happening below the UI. Get one of the team members to document what is needed in your company into a knowledge base or wiki.

Source control

Next, the transforming teams need an understanding of the source control systems you use. Git is common, but it may well be another system such as Mercurial or Team Foundation Server. Given the team members’ new command-line understanding, create a test repository for them. Initially the team probably needs to have a 3 out of 10 skill rating to start having success. The rest they will learn as they come across more advanced needs, but too much now will overwhelm them.

Though there are many YouTube courses on Git, you may choose to assign someone on your team to teach. As everyone wants an exceeds expectation rating on his or her yearly review, volunteering to be the Git trainer could be one step of many toward that rating. I have tried to teach class myself with everyone following along using their own computers, but I have since changed to an approach where only the instructor interacts with the test repo, and the students work on their assignments after class. Too many novices pulling and pushing code at the same time without completely understanding what they are doing breaks the flow of the teacher’s instruction.

After the team members are comfortable pulling, pushing, branching, and merging code, they are ready to graduate to your actual source-code repository. Some might insist on read-only access but I prefer the same general rights as everyone else. Set the expectation that they are not to change code outside their scope of responsibility and trust them not to. When I worked in the Microsoft Office 2010 code base, we could have changed nearly anything in the whole Office repository, but we didn’t. I like starting off with the belief that the team members can be trusted, and so do they.

Encourage the QA team to pull the latest code daily and start looking at the changes. Pair each of the QA team members with a developer and ensure that they can see the check-ins in the source control system and review the code. As they progress toward learning to code, reading code will help teach them.

This article is published as part of the IDG Contributor Network. Want to Join?