Alida Arteaga, Regional Coordinator

25 May 2021

What does a QA specialist do?

Quality Assurance specialists may not strictly be considered part of the development team, but they are a key piece to a product’s successful growth. One can launch a raw Minimum Viable Product but scaling up requires quality, and this is what QA delivers. Let’s see how.

How QA is (not) different from software development

Despite the difference in titles, both QA specialists and software developers take part in the execution of a software product. Both work against time constraints that prevent the job from fully getting done. The 80/20 rule is real: just as software developers can’t afford to spend time on cleanest implementations, QA can’t realistically find ALL the issues, even if some checks are automated.

On a fundamental level, the main difference between QA and software developers perhaps lies in agency. The quality assurance team can find hundreds of bugs but it’s on devs to go through the report and fix issues. Naturally, developers can address only so many issues in their limited time away from developing new features.

Note that this chain does not invalidate the work of Quality Assurance specialists. Their input is required and appreciated even if the rest of the team cannot respond instantly. The video game industry is a prime example of that. You have companies like Rockstar Games who can spend years polishing details like horse anatomy in Read Dead Redemption 2 to release a very immersive product (even if the gameplay is dated). On the other hand, the likes of CD Projekt RED have devs scramble to finish barebones of the game before a deadline and fix bugs in the following months. This way, CDPR ultimately benefits from QA effort, as their story-driven games have a second wave of sales when the community consensus is that the product is no longer raw.

One may get an impression that QA only starts to kick in at the end of development, while Front-End and Back-End developers have things to do throughout the project. Luckily, it’s not the case. Modern software development usually runs on two-week sprints with deliveries presented every other Friday. There’s no need to wait for a finished product: individual modules (e.g. payment system on an ecommerce website) can be tested separately.

Testing, formalized

On the surface, testing software products is a rather trivial process. You click all the buttons that you can find and see if the outcome matches the expected result. Unfortunately, things are not quite simple. The button’s stability may depend on the hardware you’re using, there are text fields that accompany these buttons, interactive elements behave differently depending on various things…

To further tackle this chaos, QA specialists create test cases. They help narrow down different scenarios to see whether, for instance, a certain piece of app functionality works as intended. Let’s imagine we, a software development team in the UK, are creating a global mobile application that requests people’s name on signup. Some of the test cases would include:

  1. Create account entering English first name and surname
  2. Create account entering English first name and Swedish surname (e.g. Oskar Wahlbäck)
  3. Create account entering Russian first name and surname
  4. Create account entering first name only

Naturally, we would expect the first three cases to work fine and the last one to cause error, since our product needs both first name and surname. In real-life scenarios, I would expect both Case 2 and Case 3 to go wrong. Incorporating non-English characters is a basic thing these days, but something you may still not get right in the first product iteration.

Suppose our backend indeed fails to register people with non-English characters or even a combination of English and non-English characters. Here’s how we would reflect the test cases on Excel or a test case system.

Test Case ID

Test Steps

Test Data

Expected Result

Outcome

Pass/Fail

TC1

1. Open app sign up

2. Enter first name: John

3. Enter surname: Adams

4. Submit

John
Adams

User signs up successfully

User signs up successfully

Pass

TC2

1. Open app sign up

2. Enter first name: Oskar 

3. Enter surname: Wahlbäck

4. Submit

Oskar
Wahlbäck

User signs up successfully

Error

Fail

TC3

1. Open app sign up

2. Enter first name: Иван

3. Enter surname: Иванов

4. Submit

Иван
Иванов

User signs up successfully

Error

Fail

TC4

1. Open app sign up

2. Enter first name: Steven

3. Submit

Steven

User can’t submit the form (missing surname)

User can’t submit the form (missing surname)

Pass

Filling out the last two columns and potentially taking screenshots/screen capturing will help generate a test case report. QA specialists can use them to file bugs into a issue tracking system (e.g. JIRA), while developers can easily replicate the issue by using relevant test steps and test data. The Project Manager will also have an easier time assessing the impact of these bugs and prioritizing them for upcoming development sprints.

Now, you just wait for developers to come back and tell you they have the issue(s) that you raised—recently or otherwise. Once the good news arrives, you run the test again and the outcome (hopefully) matches the expected result. Phew!