What Are QA Engineers and Why They Are So Important?

While negative reviews can be helpful to users, they are highly disliked by app owners. Unfortunately, the latter cannot avoid this situation when there is a need to fix some issues that arise. The thing is to do it before users find at least critical ones and give them a bad review or a low rating that can cause serious damage. It's no secret that people are more hesitant to deal with a business or service with negative reviews. So what should the app owners do to avoid it? Before launching an app, it should be thoroughly tested.

Luckily, there are superheroes known as Quality Assurance (QA) engineers. They are always ready to come to the rescue and fight the bugs or other critical errors. I am proud and happy to be one of them.

In my opinion, the QA engineer plays a crucial role in the software development and distribution lifecycle. My main task is to find bugs before the user finds them. I interact with a new feature as a user and look for possible bugs, so when the feature is finally deployed, the user will experience the error-free version.

What does my work process look like? Let me give you a step-by-step guide.

General Steps of Testing Process

Understanding New Feature

At first, I should understand the major functions of the new feature, the purpose for adding it, and the requirements it needs to meet. This information helps me to test the new feature effectively.

In the company where I work, I receive all my tasks directly from the developers who, in their turn, get tasks from the customer. Usually, I get a specification that contains all the requirements: what the new feature of the app is for, how it should work, how it should look like.

After the developers finish working on the new feature or making modifications to the existing one, I ensure that the actual outcome matches the intended one. How do I do that?

Initially, I check if the visuals match the developed design. I take the design mock-up, a visualization of what the final result should look like, and meticulously check fonts, colors, indents, etc. to ensure perfect alignment. Nothing should escape my eyes.

Then it is time to proceed with functional testing. I have to make sure that the new feature works according to the requirements. For example, I came across a car on a used car website that caught my interest and I would like to save it to my "favorites". And there is a special button for that. I click on it, and it has to change its shape or color, so I can see that I've selected that item. Then I check the "favorites" tab to make sure the car is there.

Creating Different Test Scenarios

While playing around with the new feature, I try all the positive and negative scenarios which a user can perform.

The positive scenario tests the application's performance under normal conditions. For example, while testing it's crucial to validate the accuracy of the phone number field.

• I verify that the phone number field design is in accordance with the specification.
• I validate the correct format of the phone number.
• I check the phone number with a country code.
• I verify the field with a maximum and minimum length of phone numbers allowed.

The negative scenario is a test under non-standard conditions where the user does something unexpected or unpredictable to the system. For example, I enter a very large or very small number of digits and click "Save." I also verify the field with letters instead of numbers. This is non-standard behavior, but even in such cases, the program should behave appropriately - for example, it should display an error message.

The purpose of negative scenarios is to detect such situations and prevent application failures. In addition to enhancing the overall quality of the application, they also serve to identify any weaknesses it may possess. Positive testing ensures that the application functions as intended, while negative testing guarantees correct operation of the application in case of non-standard user behavior.

Where do I get negative scenarios? Some of them stem from a strong foundation of theoretical knowledge, while others are rooted in my extensive working experience. Sometimes I just go into my mind palace and envision potential errors. From my personal experience, I can say that the longer I work, the easier it is for me to predict where bugs might occur.

To my mind, positive scenarios are much more important than negative ones. For example, while testing a website, it is important to first check the main scenario of operation - whether the website fulfills its main function. If the positive scenarios fail, it makes no difference if the negative scenarios exist at all.

Reporting and Analyzing Bugs

When I find bugs or other critical errors, I always analyze the results to figure out what went right and what went wrong. From there, I can make suggestions to the developers on what to improve. They, in their turn, make changes to the code that addresses the identified bug and I test the feature again. Luckily, there are certain QA tools that help me do it.

If you ask me how long the manual QA can test the functionality of an application or website, my answer will probably surprise you. Infinitely long. Yes, I'm not kidding. Every day I can come up with new negative scenarios and test them out.

To be honest, no manual QA can claim that testing covers 100% and that all errors can be easily predicted and fixed. The fact is that most problems can be predicted in the testing phase, but exhaustive testing is hardly possible. Nevertheless, my colleagues and I do our best to minimize the risks of errors occurring.

Understanding Users' Frame of Mind

In my role as a QA engineer, I have the unique ability to perceive projects from the perspective of users. It is not uncommon for developers to overlook certain aspects that might not be immediately apparent to the end users.

In one of my projects, I came across a bug that proved to be quite unexpected for the developers. In order to convert a word into a search tag, the user needed to press the "Enter" key after entering the word in the search bar. However, this was not mentioned anywhere. I am aware that users frequently enter a word without actually pressing the "Enter" key. So did I while testing. As a result, my user experience was marred by errors and I did not achieve the expected outcome.

When I showed this bug to the developers, they were really surprised, because they all knew that "Enter" is mandatory, and they could not imagine that someone could be unaware of how to set the keyword correctly. To solve this problem, the developers decided to add a placeholder, an additional text that is placed in the data entry form. Its main task is to tell the user what information should be entered in a particular field.

There is another bug that I've encountered on different projects multiple times. Developers implement validation that ensures mandatory fields, such as the username, are not left empty. But they often forget that the user can enter a space instead of an empty value. This often causes bugs on the frontend and backend.

Challenging Part of the Work

App owners often think that they will develop a project and only then hire a QA engineer a few weeks or a month before its release. But they forget that the QA is a technical specialist just like other members of the team. We need time to get into the project, understand its structure, design, all the business logic. The bigger the project is, the more time is needed.

In practice, it often happens that such a short period of time is not enough to find all the bugs and make sure the final product is meeting quality requirements before its launch. In such cases, it turns out that the QA engineer was on the project, but did not have time to do their work properly.

Investing in QA Engineer

Some business owners don't hire QA engineers mostly because of the costs. But I, personally, think it's a big mistake. It is good to have the QA from the very beginning of the project development, because the earlier we find the bugs, the faster and cheaper it is to fix them. If app owners don't want to pay for testing at the development stage, they have to pay for technical support and bug fixes after the product is released to the market. Early testing helps reduce software maintenance costs.

There is no worse scenario than letting the users test the final product and finding the bugs on production. There is no doubt they will write bad reviews that don't mean any good for the business. So, sometimes it's better to invest more money at the beginning of the project development to pick up the rewards later.