7 Approaches To Testing

Originally published on August 17, 2020

This article will be interesting for IT directors, product managers, project managers, and anyone who wants to understand the processes of project quality assurance better.

At Qualitica, we test large web and mobile projects, both commercial and national ones. Before a separate testing agency has been established, I spent 10 years as a specialist and head of several digital studios. Usually, in any IT project (websites, applications, games, corporate software), you start by treating testing as a formal procedure. However, normally the testing also evolves with the project: the more people are involved, the more complex is the process.

There are 7 testing evolution stages that may differ in different companies:

1. There are no testers. Their functions are performed by developers or managers.
2. Testers appear, but test projects only at the completion stage.
3. Testers check all developer tasks to see if the result matches the original task statement.
4. Testers are engaged in test design.
5. A test management tool is being implemented.
6. Testing automation appears.
7. The complexity of the hierarchy, the creation of new roles in the test team.

Let’s learn about each stage in more detail.

Stage 1: Testing Is Performed by the Developer and/or Manager

It’s the simplest, "instinctive" approach to testing. It is common in small companies. When it is impossible or presumably unwanted to hire a professional tester, this part of the work is performed in-house.  However, this is an inappropriate and problematic approach for the following reasons:

• A developer only tests his own scenarios with the data he used in the development process. In this testing, alternative scenarios are omitted. As a result, something is out of control, and end-users usually get errors.
• A manager takes testing as a side job, having little expertise, time, and desire to do it. This way, you can detect gross errors, but many nuances are overlooked.
• The subjective approach and the desire to complete the project quickly result in the wish to ignore “minor” problems.

An extreme case is when no testing is done in the company and the error report goes from the client. Then more and more errors/bugs appear. Thus, clients become testers at their expense.

Stage 2: The Tester Tests the Project at the End

Checking the entire project at the pre-release is a classic method when working with the Waterfall model. The project is divided into global stages (sometimes the entire project is single-stage). At each stage, the software is made and then tested in place, which is good. But there are also specific problems:

• First, serious architecture errors may be found too late necessitating to redo the project or its part.
• Second, if there is no documentation, we can only perform surface testing using the free search method. This immediately discards some alternative scenarios.
• Third, the project time is mostly allocated for development as a priority task. A little time is left for verification, but there is no time to fix errors. As a result, improvements may slow down the project.
• Fourth, between the stages, the tester may forget the details and needs more time to recollect these.

Thus, this approach is logical but takes into account no global errors. Therefore, testing evolves further.

Stage 3: All Issues Are Checked To See if the Result Matches the Original Issue

Then the company understands that it is better to detect errors as they accumulate. Therefore, we switch from the Waterfall model to the Agile method. At this point, testers are deeply integrated into the development.  All tasks are tested repeatedly and sequentially: separately, as part of the release, in the field.

At this stage, issues are checked for compliance with the stated requirements. Agile helps you work better, but not all testers, and especially their managers, are ready for a new approach to testing. The manager expects speed and quality from testers, but there is still no understanding of the need for test documentation and regression testing; hence, the typical problems of this stage of evolution.

Testing is rather intuitive than structured. The principle of "what I see is what I test" prevails. For each iteration, different tests are made in different sequences. As a result, you can at least skip or ignore the error at one of the testing stages as well as alternative scenarios and change of the related functionality.

Moreover, there is a problem with regression testing, which, if it is conducted, is haphazard. The QA engineer tests what he considers necessary or what the developer/manager advised.

Stage 4: Testers Are Engaged in Test Design

At this stage, the test design starts. Testers begin to consciously pay attention to requirements analysis. The functionality is divided into logical blocks, covered by checklists or test cases.

• Checklist is a list of the functionality tests.
• Test case is a sequence of steps to test the functionality.
• Full-fledged test documentation can be used to track a particular functional verification.

This is called a test design. The important professional testing begins at this stage. Now there are few tasks to be checked, but a structured process for analyzing requirements, creating test documentation, and direct testing. In particular, the approach to test data is changing. Data is no longer generated spontaneously on the fly but is taken from pre-prepared sets.

There are no obvious disadvantages at the test design stage. In general, this is already a decent level of testing. For streaming production of websites or similar projects, test design is enough. The main thing is to approach the testing process correctly: analyze the product, prepare the documentation, and test it.

Stage 5: The Test Management Tool Is Being Implemented

Next, the company needs specialized systems to:

• Store requirements and test cases.
• Link requirements to test cases.
• Analyze test coverage.
• Store different versions of the test cases.
• Perform the test runs.
• Perform a comparative analysis of test runs.
• Maintain reports of testing.
• Track the team's workload to adjust tasks and resources.

The system is always a new stage of evolution. In our case, first of all, control over the testing process is improved. We manage tests better and get a new level of product quality. In the late project development, this system reminds everyone how something should operate and how to check it. The system speeds up the introduction of new participants to the project.

Stage 6: Regular Tests Are Automated

During the long-term project development, automated individual tests are needed. Developers and testers write self-tests. Developers usually do unit tests, and testers do UI tests. They start with positive scenarios of using key functionality with self-tests. Developed self-tests are included at the CI/CD, which allows the team to learn about errors directly at the time of commitment.

There are many technologies for test automation. Over time, at Qualitica, we have identified the following for ourselves:

• Testing framework: TestNG/JUnit
• Programming language: Java, Python
• Project builder: Maven/Gradle
• Library for UI tests uses: Selenide, PyTest
• For backtests: The Rest Assured library
• Formation of reports: Allure

Self-tests reduce the cost of regression testing and improve the quality of the product, but they take a certain tester level. You should also know that it doesn't make sense to do self-tests at the early stages of the project. The system changes quickly, so avoiding phantom errors requires time-consuming changes in the self-tests.

Stage 7: The Hierarchy Becomes More Complex and New Roles Appear

We have reached the highest stage of evolution when the hierarchy in the testing department becomes much more complex and specialists like test managers, test leads, test analysts, test designers, etc. are required. For example, the test manager is involved in the testing arrangement at a higher level. He rather communicates with clients and developers than with the testing team.

Each person is responsible for his or her own front of work:

• The test manager owns all the information on the product, sees the "whole picture", organizes work, and manages the testing team. His function is to communicate with the customer and the development team.
• The test lead coordinates testing and assign tasks within the team.
• The test analyst analyzes the requirements, prepares the documentation.
• The test designer transforms the requirements into checklists and test cases.
• There are testers, who make tests manually and integrate into the development team.
• Automation engineers write self-tests for functions that do not change anymore.

New roles involving the entire team of testers are necessary for large and complex IT projects.

Conclusion

We’ve reviewed the key stages in the evolution of testing in the company. Conscious professional testing begins with the test design stage. Test design steadily improves product quality.

You can skip, combine, or mix certain stages, or go straight to a higher level.

A test management tool, self-tests, and especially test designers are not always required, but staying at the stage of instinctive testing or limiting yourself to final tests, you are unlikely to do complex long-term projects. Therefore, I wish you to find the right point of view in testing development, improve the quality of testing, and give clients a high-quality product.