QA Engineering in Software Development: Dispelling the Myths

When people think of the job of Quality Assurance in software development, they often think of the role of a software tester, a person who finds and reports critical bugs, and signs off on the new release or update of a software product. A veritable “bug hunter” if you will. And while all of this is certainly true to a degree, the actual job of a QA Engineer and the role they play in helping to release high-quality software encompasses much more.

So What Exactly Does a QA Engineer Do, Anyway?

Well for starters, if we think of your project as a moving car then quality assurance is, in essence, the headlights of the vehicle. We make sure to light up the road ahead, point out any dangerous twists and turns, or spot potholes in the road that might potentially damage the car. 

It’s the “thinking ahead” part that QA brings to the table. We don’t have the means to fix your car when it breaks down; we’d rather it didn’t break down in the first place.

When it comes to QA work in a project, there are many ways to contribute. During planning, design documents can be checked for errors and the user experience flow scrutinized. Once development begins, new features are tested to make sure they function properly and are implemented according to design specifications.

As different components are combined together, testing is done to confirm that individual components play nicely with others. Once these new features are implemented, we test the general functionality of the entire app to make sure new changes didn’t create unintentional problems elsewhere in the application. We can even automate these tests to make general user testing much faster and more efficient!

While all of these areas are crucial to application development, it is equally important to check erroneous or improper behavior at every stage to make sure that the application correctly deals with these issues as well.

Let’s consider this example of a simple feature a client would like to implement, such as the process of logging in to an app. Starting with the most obvious, a user with a correct username and password should be able to log in without any issues and conversely, an incorrect username or password should not enable the person to log in.

But what about some less obvious cases? What happens when the user clicks the login button twice (or ten times)? You might not ever do that yourself, but your cat might. Mine has. What about when a user is logged in, closes that window completely and then opens the page 6 hours later; Should they still be logged in? What about 6 days later? Are user credentials visible to anyone who “looks under the hood”, or are they correctly hidden?

This is a common scenario for Quality Assurance Engineers. We check that the product or feature works as expected, but we also think of other less likely scenarios, such as if a user has a bad network connection or has accessibility issues, and ask questions to help define what the expected behavior should be in these types of situations in order to minimize risk. In other words, keeping our eyes on the road ahead.

Why Should I Have a QA Engineer Onboard?

Sometimes, these types of issues are not the end of the world. My cat hasn’t caused an international catastrophe…yet. However, what happens if many thousands of people try to buy tickets to a Taylor Swift concert at the same time, or an identity thief tries to hack into your bank account, or the lack of authentication exposes 900 million sensitive records, such as in First American Financial’s 2019 data leak? We might not be able to completely avoid these situations, but we certainly do our best to minimize risks your product might face.

Another advantage of having a QA Engineer in your project is that we become the ultimate power user for your app. By using and testing your app many hours each day, we learn to understand the app like the back of our own hand. As a result, we are able to identify problems or issues early on, which makes fixing them that much easier.

We also notice when a user process is awkward, confusing, or could simply be executed more logically, and thus become a huge advocate for clients because we are constantly focused on the user’s experience and try to understand the app from their point of view.

Developers are often focused on very detailed or specific aspects of the software—and that is very good when ensuring consistent delivery. Quality Assurance Engineers, on the other hand, are not immersed in implementing, so they get a much broader view of the app and notice issues that might otherwise be overlooked. These two roles combined, focused programmers and QAs with a bird’s-eye view, help achieve a scalable development environment.

A humorous take on the relationship between developers and QA Engineers

When Should I Onboard QA Engineers in My Project?

It is often important to get QA involved as early as possible in the planning and production process. While it may seem counterintuitive to have quality assurance participation before any code has even been written, one mantra that we preach repeatedly is to “find important bugs fast”. The faster an issue is discovered, the easier—and cheaper—it is to fix.

If you’ve got a QA Engineer pouring over design and business logic documents at the very beginning, we’re considering all of the ways something can be implemented, what problems might occur, and what the user’s experience will be like if it is implemented in a certain way. If we can find problematic areas before a developer starts working on a task, it becomes much more cost-efficient in the long run. We are essentially disciples of Captain Edward A. Murphy: “Whatever can go wrong, will go wrong”.

Do All Projects Need a QA Engineer?

There are some cases when a Quality Assurance Engineer might not be as imperative in a project. In some instances, a project might be rather small and only require one developer, or perhaps the app could be quite simple in its business logic and therefore easy to test.

Another instance would be if a client is looking to develop a proof-of-concept type app that is intended more to attract investors than it is to work flawlessly out of the box. If your app has an esoteric purpose with a very specific user in mind, such as an app that performs genetic data analysis, it might be more beneficial to enlist a group of beta testers to look at, for example, how the app analyzes rare genetic defects and get specific feedback on how to improve the app. 

Additionally, once the development phase of a project has been completed and most tasks are maintenance or bug related, a lesser QA presence could make sense. But in most situations, having a QA Engineer involved in your project should greatly impact the stability and robustness of the app.

Do QA Engineers Always Work Full-Time on One Project?

It isn’t a requirement to always have a QA Engineer full-time in a project, depending of course on the complexity of a project, the size of the team, what risks are on the client’s side, etc. What often happens, however, is that the time allotted for quality assurance in a project is rather too little than too much.

If the project is quite small and there are just one or two developers working on the project, having a QA Engineer for 16-20 hours per week (also counted as 0.4 to 0.5 FTE, or Full-Time Equivalent) ensures that new features will be tested and that the app works as expected, with some additional time typically set aside for general or exploratory testing to test overall app functionality and to make sure that a new feature didn’t accidentally break an existing one, or to test some improper usage of the app to make sure it responds appropriately. With larger projects, that amount of time simply covers checking tasks and performing some basic “smoke testing” to make sure there are no fires in the app.

If a QA Engineer has more time dedicated to a single project (let’s say 32 to 40 hours per week, or 0.8 to 1 FTE), it allows for much more extensive testing. This can include working more proactively with developers to debug the software, test features more thoroughly and especially check for less common edge cases that can be easily overlooked. Additionally, more time in a project offers an opportunity to write automated tests that will help cut down on repetitive everyday testing tasks and enable an engineer to test for less likely edge cases. It's also advantageous when software specialists get enough time to focus on a single project, as too much context-switching works against productivity. 

Summary

The role of a Quality Assurance Engineer encompasses much more than simply finding bugs. It’s a job that is at the same time client-facing and development-facing; we’re simultaneously focused on the client’s vision of their product while also lending our support to developers to ensure that both sides of the project are progressing in tandem. 

Although not all project scopes or phases demand a dedicated QA Engineer, when a project has enough dedicated QA involvement, it shows very clearly. From the daily work of the developers to the quality of the released product, QA Engineers play a key role in helping keep the project on track and avoiding potential pitfalls. In other words, keeping our headlights on the road ahead and even proofing products against overly curious cats.

Małgorzata Król, Łukasz Pawlowski, Katarzyna Gieroń and Carlos Oliveira contributed to this article.