5 things QA testers wish programmers understood

Software developers need testers to be their shield in the fight against software defects. QA professionals want programmers to know how to strengthen this alliance.

Programmers know how to develop code that runs the machinery of the 21st century. Because of programmers, we have Netflix to stream movies and DoorDash to deliver food, and can we take a moment to appreciate how amazing this is? 

Yet, as software testers and QA professionals can tell you, programmers may know a lot. But they don’t know everything. And if you ask QA, hoo boy, they’ll tell you. 

QA is here to fill in the gaps of a programmer’s knowledge base—and to find the bugs that even the best programmers leave in their wake. So what is it that QA wished programmers knew? Several testing professionals made a list, then checked it, because that’s what they do.

We’re here to help you. Really.

QA tester Brad Mendenhall wants programmers to know, “We know how hard they’re working. And if they give us a chance, we’ll make their lives a lot better. We’re on their side.”

A QA tester’s job is to hunt for bugs that could negatively impact the user’s experience, as well as to report these errors so they can be fixed 

When programmers see testers coming to their cubicle door (assuming they’re lucky enough to have a door), they know the testers are not there to bring donuts. You’re there to tell them they have more work to do. This can unintentionally lead to a strained relationship, which isn’t good for productivity. “It helps when the developers are not scared of me,” Mendenhall says. 

Yet, points out Mendenhall, “When you’re avoiding QA, when you view them as being antagonistic, you’re not doing your best programming.” A programmer who avoids any kind of QA intervention won’t bring their A game (or C++ game) and perhaps won’t push features out as aggressively as they normally would, which slows progress. 

Mendenhall wishes programmers knew, “You’re going to make mistakes. There are going to be things that you don’t foresee. If I find [a problem] don’t worry. Let’s work on this together.” 

Mendenhall has a suggestion for QA testers who can spare a little time: Find a developer with whom you don’t have an established relationship. “And say, ‘Let’s spend 20 minutes so you get to know who I am.’” 

Sometimes, he even brings donuts. 

Programmer lesson: The QA tester is your friend. Also, there could be donuts.

Trust us. We really do see a bug here.

Let’s say that, as a software tester, you find an interesting, edge-case defect that you think needs immediate attention. Maybe it’s a big deal. For example, a special character (or lack thereof) can change a word’s meaning.

But when you walk over to the programmer to demonstrate the problem, you’re met with a mile of denial. 

“Sometimes we see a bug, and [programmers] will give a little pushback on it,” says Syam Patel, a front-end QA tester. For the most part, Patel’s product manager agrees with him on what needs changing. But, he says, “If they don’t think it’s a bug, they won’t prioritize it or accept it as a bug.” Ultimately, the decision as to whether the software’s behavior is a bug or a feature lies with the product manager. 

Programmer lesson: If the QA folks didn’t believe there was a bug, they wouldn’t have bugged you about it. Geddit? Ha ha. 

QA is helping you avoid future problems. You want your manager to be pleased with the smooth rollout of your next release, not asking you why they spent an hour that morning apologizing to a customer.

Please speak human, not programmer-ese.

For QA testers, asking a programmer a question may lead to an unwanted response: They actually answer it for you. In mind-numbing, line-item detail, where on a scale of 1 to 10, the boredom-meter is dialed to 11. And the more extraneous, unrelated details the programmers provide, the trickier it is for testers to winnow out the information they need.

The programmer and the QA tester may both share a common language, such as English. But some programmers tend to communicate in their second language: programmer-ese. This densely technical verbiage includes jargon like “literals,” “Boolean,” “fuzzing,” and other words, where on a scale of 1 to 10, the confusion is dialed to an imaginary number. 

“Programmers are so technical about what they know, and they explain things in such a technical way, on a granular level,” says Patel. He would rather coders speak to him in a way he—and other humans—can actually understand. 

Programmer lesson: If a QA tester asks you to explain a hitch in expected behavior, don’t dazzle them with the history of the database schema. Remember the KISS principle: Keep It Simple, Software-developer.

Keep your code up to date

Creating new features is sexy. Meeting regulatory requirements is not. But without meeting standards for security, privacy, and accessibility, your software will go down like an Iowa caucus app.

Another unsexy job in the programming world? One that the QA staff wants programmers to know? Keeping code up to date. 

When code becomes deprecated—that is, slated for the chopping block—it should be eliminated from the code base ASAP. “Keep your code up to date so that the framework can be easily upgraded,” says tester Sheri Byrne. “When you use a deprecated function, it makes it very difficult to upgrade the underlying framework.” 

All the old code can lead to issues for QA to find during the testing process. Seemingly small issues can tack on precious hours, days, and even weeks to the project release date. 

Programmer lesson: Keeping your code free from essential errors gives you time to fix the unintentional ones.

The sooner you bring in QA, the better.

Programmers get the best use out of testers the earlier they bring them in, points out Mendenhall. The best time to bring QA to the table isn’t during the beta or user experience testing. It’s during the planning phase.

Mendenhall has worked with companies where QA staff are included in the product development phase. When management describes its planned upcoming features, he says, “An experienced tester would say, ‘Just so you know, something I’ve seen that’s a problem in the past is this. This is how I’m going to test it. This is something you should think about during your programming process.’” 

With this sort of input, the software testers can help lay out a roadmap to help guide programmers to their destination, shining a light on a path before it’s even constructed. What mastery! Give them a raise immediately! 

“The easiest bug to fix is the one that isn’t created,” says Mendenhall. If they’re looped into the team’s planning, a good QA team can prevent those bugs from happening. 

It’s not every mortal who has the power to fix problems before they’re created. Only the worthy ones. 

Programmer lesson: Make QA a part of your development cycle, and behold the QA might.

It probably wouldn’t hurt for developers to know how to write a test case, too. Fortunately, we have a white paper that shares a little of that wisdom.

by Carol Pinchefsky

Carol Pinchefsky is a freelance writer who writes about technology, science, and geek culture. She lives in New York City with her husband and their books. She can also be found on Twitter, Facebook and carol pinchefsky.com