Does your project need a QA engineer? On the importance of testing

What IT profession is associated with a large number of myths and stereotypes? Probably the profession of a QA engineer! A lot of people are still wondering what they do and is it possible to do without them? Running far ahead, we will immediately answer: “No, it’s impossible!” And in this article we will tell you why and dispel the most popular myths about this profession. Well, let's get started!

Stereotype #1: The biggest stereotype is that a tester's job is to hunt for bugs in a website or application. And then with the exclamation “I’ve broken!” joyfully run to the developer and show their “loot” in the form of a technical bug.

Stereotype #2: At the same time, people have the illusion that software developers have to write code without errors, thinking through everything to the smallest detail. And along the way, organize the work within the team.

From these two stereotypes, the question naturally arises: “Why are testers still needed?”

Our answer is: they are not just needed, they are real must have! Who will check all conceivable and inconceivable scenarios of user behavior when working with an application or website, identify potential bugs, catch defects based on their experience and skills even at the stage of familiarization with the requirements, so that the developer receives the most detailed task, and the product is released faster? Who if not a tester? Not a single mistake escapes his keen eye. The tester acts as a kind of safety net for the developer, a guarantor of the quality of his work. No matter how professional the developer is, the product he creates can potentially have unreported bugs that are difficult to detect at first glance.

And here another question arises: “Can't programmers independently find bugs in software without involving a tester?”

We believe that a programmer is able to obtain basic knowledge for testing and even conduct superficial checks. But it is always more difficult to look for your own mistakes. And the programmer's hourly rate is many times more expensive than that of a tester. In the end, testing a product by a developer will not give the same result as testing by a specialist who is an ace in software quality assurance.

Stages of the tester's work on the project

Let's dig deeper and consider the full cycle of interaction between a tester and a project in order to better understand the essence and principles of work. Let's divide the software product quality assurance process into five conditional phases:

• Clarification and analysis of requirements for the software product.

• Drawing up a test plan.

• Writing test documentation.

• Product testing using technical means.

• Checking the results.

1. Clarification and analysis of requirements for the software product

Testing a finished function in an application is just one of the tasks in the work of a tester. As soon as you receive the first requirements for the software, you need to foresee all the problematic moments as much as possible in order to redo less later.

Let's give an example from our practice: as conceived by the customer, the registration page should contain the “email” and “password” fields. The task of the tester in this case is to clarify:

• what emails are allowed;

• how long should the password be;

• what symbols/numbers, lowercase/capital letters will definitely be present;

• what is the next page after successful registration;

• what errors and how should be shown during email/password validation, and so on.

The more information is obtained, the more emergency cases can be foreseen. The developer will receive more complete requirements and perform his work with high quality, since a significant part of the details will already be described in the task.

2. Drawing up a test plan

Along with this, the tester thinks out a test plan. It is impossible to keep everything in mind, so the engineer creates a document where he describes:

• testings that are planned;

• test data to be used (for example, fake user accounts);

• how and with what tools it is necessary to carry out load testing, security testing;

• what we need from the development team to run the tests.

Together with the developers, a trace matrix is additionally written - a document in the form of a table, which clearly shows the dependencies of one function in the application logic on another.

3. Writing test documentation

Based on the developed test plan, documentation is prepared. It can be different, there are several types of documents that are created in the process of product testing. The most famous is the “bug report”. It is necessary to fix the defect and describe its reproduction step by step. The better and more accurately the bug is described, the faster the developer will fix it. Test cases are useful not only to all members of the development team, but also directly to the customer. They describe step by step how this or that functionality works, down to scenarios, how validation should work out - the process of checking whether the final product meets the original requirements.

4. Testing the product using technical means

At the end of the theoretical part, the tester starts the practice. With the help of our own hands and machine mechanisms, the product is tested at all stages of its creation. To understand in more detail when and what type to use (manual testing or autotests), we have saved an article for you. In it, we revealed the difference between these two types of testing, and also talked in more detail about the process of finding bugs in an application or on a website.

In addition to the type, the engineer is also determined with the methodology of work, so as not to carry out excessive testing of everything in a row.

5. Checking the results

At the final stage, the tester checks the compliance of the plan and the results of the testing. It also supplements the test documentation with new information that was obtained in the process of work and will be useful to the developer in the future.

What threatens to refuse software testing?

The question is broad and complex. Let's simplify the task and show it with a specific example: our company received a request for outsourcing - an online store that was previously tested only by the customer support service. At first glance, everything worked fine: the business logic is in order, the designs are pixel by pixel. But the server had to be restarted often, the application slowed down. The team was tasked with identifying and localizing the problem. We had to test the whole application. And what did we see?

1) In addition to the memory leak, the testers realized that if you insert the order number into the url (website address), you can view the receipts of any user, not just your account.

2) In the response from the server, in addition to the necessary data (name, e-mail, rating, and so on), the user's balance was also loaded.

3) When entering the application, the user's password was received from the server (although encrypted, but this is very, very bad).

What does all this threaten? The personal data of users is practically open to the attacker and served on a silver platter for further fraudulent operations. It's good that we discovered these bugs before someone became the fraud’s victim and the customer received a lawsuit from users. In this case, the refusal to test threatened both the loss of the budget and the loss of reputation.

In order to prevent such situations, you need to clearly understand that an application or website is not only a beautiful visual. These are complex mechanisms with their own “laws” and internal systems. Both the application and the site have a hidden part, like in a car, that works “under the hood”. And just as a car needs not only a driver, but also a mechanic, so an IT product needs a tester who will detect a breakdown in time and prevent negative consequences