Quality assurance professionals are a bulwark against broken code, bad math and inadequate documentation. Just as importantly, though, they're strong critical thinkers who know how to ask the right questions of the right people.
Quality assurance is an essential part of every software development and deployment pipeline. It ensures that all software engineering practices meet an organization's specific requirements and standards. A QA team can help developers avoid problems or errors before they occur.
Those who land a QA engineer role typically have a university degree in computer science or related subjects and have worked a series of IT jobs to build experience. However, these degrees aren't prerequisites for the role.
The road to a QA career
Emily Thomas, a software QA engineer at Vonage, an international voice over IP (VoIP) provider, took a different route. Instead of an engineering degree, Thomas pursued a degree in Latin and German. While these disciplines are certainly different from engineering, the skills you acquire learning spoken languages are transferable to code languages, according to Thomas. "Because, in many ways, you're basically communicating with a computer," she said. "I don't think a lot of people agree with me on that."
Although Thomas' first tech job in college was in the university IT department -- servicing classroom and lab equipment -- she spent her time post-university at recruiting firms doing unfulfilling work.
That's when she looked back at IT. "A lot of my technical skills are self-taught, or [came from] asking my family members [or] co-workers questions," Thomas said, noting that her parents also hold diverse positions in the IT field.
Mentors vs. advocates
Mentors can be invaluable to someone's career growth. Career progression, however, isn't just about skill building -- it's also about visibility. Thomas recommends IT professionals find an advocate in their organization if they want to advance. "A mentor is going to help you build skills, but an advocate is going to push for people to see those skills and push for you to get the recognition you deserve," she said.
Thomas started at Vonage as a technical support specialist and spent eight years picking up skills and mining her connections for guidance. "Working my butt off was only half the job of getting to the position I am today," she said. "The other half was talking to the right people -- knowing the right people inside our company so that I could [say], 'Hey, this is what I'm doing. This is where my skills are.'"
After speaking with these people, Thomas was able to use their feedback to move out of her role in technical support and into QA.
An average day in QA
Thomas primarily works with rating and billing microservices at Vonage. With VoIP services, some calls have permanent charges attached. A rating microservice applies these charges; billing microservices aggregate those values and apply taxes for users across the globe. Her day-to-day activity equates to a lot of math. Thomas manages these tasks by writing a wealth of Python scripts and learning Java for more intensive CPU processes.
Thomas does primarily back-end testing and works in a command-line terminal most of the time. However, she also uses integrated development environments, such as PyCharm and IntelliJ, and manages automation through Concourse CI.
Emily ThomasQA engineer, Vonage
Thomas has a process to be prepared to perform load testing, and to test different mathematical functions and the different applications of taxes. "I make scripts that send data packets to our applications, either through proxy servers, or directly, depending on what I need to test," Thomas explained. "And I check the outcomes ... with scripts. Occasionally, if it's a brand-new application and we're still building the scripts, I have to do it manually with a calculator."
The other half of Thomas' QA duties is a little different: "I break stuff so that other people can't." Although Vonage has begun to investigate chaos engineering, it hasn't implemented it fully yet. "Chaos engineering is a little more complex than what we're doing," Thomas said. "It is useful for some of our applications, like our data storage applications and especially our public-facing [apps], like APIs and web tools."
Chaos engineering is only as effective as the human creating the test -- and humans make mistakes. "So if you make a test suite, and it doesn't include a test that a user finds, that's OK; add that test [to the documentation] and now you can go."
In her day-to-day QA role, Thomas primarily interacts with developers. Although Vonage has a site-reliability engineering team, an ongoing company initiative has combined the dev and IT ops teams into one cohesive DevOps group.
To build a rapport and trusting relationship with her team, Thomas had to learn the dynamics of how different people and groups record and relay information. Effective QA means knowing what questions the dev team won't ask and what questions they won't answer preemptively in documentation -- as well as how to get that documentation from them.
"There's a lot of social engineering that comes with QA testing," Thomas said. "To force a developer to really think about what they're saying, what they're documenting, how they're documenting and what they're telling everyone else around them. Because part of QA is that we are essentially Accountability, the Team."
When it comes to front-end and public-facing documentation, Vonage employs a collection of technical writers. However, developers are responsible for their own back-end documentation efforts.
One potential challenge for developers stems from the fact that many processes are explained verbally at in-person or virtual training meetings. As a result, things are inevitably said that aren't written down in the accompanying documentation, which means steps or configuration items might be missing from that set of directions.
But part of effective QA -- and teamwork -- is setting and reinforcing expectations and guidelines that help developers experience fewer complications. This requires consistent and insightful conversations with teams to ensure that those procedural steps described during in-person meetings are captured and recorded in formal documentation. Quality assurance involves much more than just testing code for bugs. It requires critical thinking and communication skills, as well as a willingness to stand one's ground when requesting additional information or enforcing a requirement.