QA: The Unsung Heroes of Development Teams

When Bill Gates and one of his associates were performing a live demonstration of Windows 98, an error occurred that produced an audible response of embarrassment from the crowd. And while it may have been just a slight error in the grand scheme of things, this hiccup certainly put a damper on the excitement and confidence surrounding the new product.

This moment, which you can still watch for yourself on YouTube, also shined a light on why development teams employ the work of Quality Assurance (QA) resources like myself. And it’s not just to avoid the “Blue Screen of Death” popping up during the debut of a new system claiming to revolutionize the world. The work I do reaches far beyond just ensuring a major demo runs smoothly.

Read on to learn more about the work I do as a QA specialist and the importance of this role in custom software development.

What is the Role of QA?

QA’s role is to prevent the users of a software system from experiencing defects (aka “bugs”). Defects can vary from pesky annoyances to revenue-draining catastrophes. My job is to squash those bugs before they get to production and make a mess.

To distill it down, my job as a QA Tester revolves a lot around crossing t’s and dotting i’s and making a list of things a feature is supposed to do and methodically checking them off.

I spend my days in the minutiae, the fine details, the what-ifs, and the edge cases; every way I can think of that a user might abuse the system. These are all important.

A typical day for me involves two to three projects, with daily meetings and varying timelines and delivery expectations. I meticulously manage documents to note the desired behavior of every feature of a piece of software. Then, if it starts misbehaving, we have a reference point to provide to the developers so they know exactly what is acting incorrectly and where the problem started at.

How QA Ensures a Great System

Step 1: Identifying Potential Errors

Let’s start with a place that we have all visited: the humble log-in screen. Technology has made it so there are multiple ways a user can log-in: system password lockers, password keepers or facial recognition software. So while the log-in process may seem effortless for you, there’s a lot of work going on behind-the-scenes that I need to do to ensure a seamless log-in experience.

So, expanding on this example, whether for workplace proprietary software, streaming platforms or government sites, as QA, we are the ones testing multiple functions of this innocuous first page. We don’t just test it once, we test it many times, to ensure by the time you use it, all you have to do is provide your information. Some of the things QA testers will evaluate with a log-in screen include:

• Can you log in without a password?
• Can you log in with someone else’s password?
• Can you log in when there are capital letters in your email address or username?
• Can you log in when there is a space after your email address or username?
• If the software is multi-platform, does the screen render on all browsers? All screen resolutions? What about mobile devices or different operating systems?
• Does the system have validation in place for if a user enters a new username or if they enter an email that already exists?
• Can a user retrieve or reset a forgotten username or password?
• Can the system be subverted using browser web development tools or malicious scripts?
• If the wrong email/username and password combination is entered, what does the screen look like? Is the error message clear?

Step 2: Seeking a Solution

If I find the answer to any of the above tests unsatisfactory, I write up a “bug card” in our ticketing system for the development team. This bug card contains as many details about the failure as I can find and think will be useful to the developer. This includes, but is not limited to: which operating system(s), which web browser(s), the steps needed to reproduce the error, screenshots or videos of the error, and, most importantly, what the expected behavior is versus the actual behavior that I’m observing.

Bugs can take many forms, such as:

• Logic errors. An example of this would be when changing one user’s password, the data updates to a different user’s information.
• Display errors. A display error includes incorrect fonts, having the wrong hex-code for a color, text spilling out of the display boundaries, screens rendering incorrectly on mobile devices, and more.
• Incorrectly wired buttons. An example of a bug in this form would be if a user selects the ‘log-in’ button, but the button doesn’t take you anywhere - or takes you to the wrong place.
• Database not updating. If the database isn’t updating correctly, various bugs can be found including an old password still working after a user has clicked a ‘reset password’ button.
• And many, many more!

Step 3: Test, Again

Once a developer has fixed the initial issue, it is passed back to me to test the feature again to ensure that the bug is fixed, but also to make sure that the changes to the code did not have unexpected results in other areas of the feature.

A Day in the Life

At the heart of it, my day revolves around finding and resolving bugs. That being said, my role isn’t as simple as the three steps outlined above. To fully appreciate a QA Tester’s impact on the development team, I think it’s important to dive into the work that QA does on a daily basis.

A standard workday for me begins with reviewing project boards to assess if any developers have pushed new features or if they’ve addressed bug fixes. On any given day I can have upwards of three projects, multiple bug cards, and a handful of new features to test. While juggling this variety of critical tasks, I attend daily 15-minute team scrum meetings as well, also referred to as “stand-ups."

I always seem to have a wide range of projects to work on—from big lifts to exciting feature updates to easily tested changes. Let’s imagine that I choose the biggest lift to work on—ensuring a bug-free testing environment for a product demo in the afternoon. I will then tackle everything from testing returned bug cards to coordinating with developers to make sure they tie up any in-progress bugs before the demo. If any of the bugs revolve around display issues, I will have to check on a number of browsers and mobile devices to confirm that it’s resolved. While I’m ensuring a flawless demo, I will update project cards in real-time so the Project Manager can see at-a-glance the real-time state of the project.

Not every day is just collaborating with my internal team members. As a QA Tester, at the end of a project sprint, I meet with our clients, typically the Product Owner and Subject Matter Experts, and demonstrate the completed features for them.

While the client will have seen a wireframe earlier in the process, or a visual mockup of what the feature or item will look like and function as, this is their first chance to see the feature in action. They have the opportunity to provide feedback and request changes when it is early in development, making it more cost-effective and easier for the developers to make changes to the code.

I enjoy bringing all of the elements together to make sure that a demo doesn’t run awry. Beyond that, there’s a certain joy in ensuring that common technological tasks are as simple as possible for users like you.

Being a QA tester isn’t for everyone, it takes a special personality. But, for the right person, the role is rewarding and provides a lot of value to businesses who get to use software without the frustration of defects.