In best practices
Oh no, not you again. Regression testing.

It is believed that regression testing is not an easy task. It's hard to disagree with that when you test what has already been tested and then test it again.
Today we decided to talk about regression testing as much as possible so that everyone can make their own opinion.
It is believed that regression testing is not an easy task. It's hard to disagree with that when you test what has already been tested and then test it again.

Today we decided to talk about regression testing as much as possible so that everyone can make their own opinion.
The regression testing has some nuances (well, who doesn't). They often remain invisible (from a bird's eye view especially, where project managers are located). However, regression testing also needs to be given attention when developing a project strategy. The properly constructed process will reduce costs and get the highest quality product.
Well, essentially, it's quite like that. The regression test is a must-have test. Now let's check why.
In the process of developing an application, inevitably changes are made to the code. In your seemingly flawless application, some percentage of users will definitely want to add a calendar, or a custom stick pack, or (God save us all) make it synchronize with a "random app name" to bake Sunday pancakes.

But the most important thing is not only to satisfy the appetites of users. It is also important that new functionality does not affect the existing one. To do this, you need regression testing, which will help you understand whether your application remains as perfect after adding a couple of new features.
Let's give an example.
Imagine that your team has developed a simple flashlight application. The application has only two functions: turn on and off the flashlight. You test the functionality to ensure that these functions and the application as a whole work properly. The test result is positive – you have nothing to worry about.

After some time you decide to improve the application, adding the function of turning on the flashlight by simply shaking the device. New functionality added, and another round of testing is being conducted. However, this time you need to check not only the new function but also the old ones. What if the changes touched them in some way?

This example demonstrates the place of regression testing in software development.

Let's take a look at how a project management methodology influences regression testing.
Take for example the three most popular: agile, waterfall and hybrid.
Agile.
Agile development is conducted in short iterations (sprints), each lasting 4-6 weeks. At the end of each iteration, the customer receives a finished product that can perform certain functions. Usually, regression testing should be done at the end of each sprint, but in fact, this is not always the case.

What's the problem?
Hard deadlines and time delays during development leave less time for testing.

How to solve it?
At the end of each sprint, regression testing with partial coverage should be carried out. It is necessary to check the areas that are more likely to be affected by the new functions implementation.

Waterfall.
According to the waterfall methodology, the transition to the next stage is possible only after the completion of the previous one. Thus, testing begins after the end of development.

What's the problem?
Making changes to the finished product is a time consuming and expensive process. It is not surprising that the waterfall model is used on small projects where the requirements are clear and do not change during the development process.

How to solve it?
It is recommended that requirements be tested prior to the development process begins. You need to make sure that the requirements are clear, relevant and realizable.
We recommend trusting the requirements testing to outside specialists. They can objectively evaluate the requirements and give recommendations on how to optimize them. After all, fixing bugs in the requirements is just adding some corrections to the text. But fixing bugs found in the finished product costs hours of developers and testers work.

Hybrid.
All the advantages of the agile and waterfall methodologies are combined in a hybrid project management methodology. The stages of planning and defining requirements are carried out according to the waterfall methodology, and the stages of design, development, implementation, and evaluation follow the agile approach.

This means that full or partial regression testing will be performed at different stages of the project.
7 stages of regression test

Regardless of which methodology you follow, software changes require regression testing, which consists of the following stages:
1
It is necessary to analyze the changes made, as well as to find areas that may have been affecter.
2
Then you need to create a set of relevant test cases.
3
The next stage is the first round of regression testing.
4
Bug reports writing.
5
Bug fixing.
6
Verification.

At this stage, QA engineers verify that the bug is indeed fixed. If the problem remains, a new bug report is created. In some cases, there is no need to fix the defect found. All critical and significant defects must be fixed necessarily, but minor and (most importantly) money-gobbling can be left unfixed.
7
The next stage is the second round of regression testing.

As the evidence from practice shows, at least three rounds of regression testing are required to fix all bugs and stabilize the application.
Manual or automated?
Regression tests are always the first in the queue for automation since they run regularly. Automation not only reduces testing time but also frees up resources for higher-level tasks and researches.
However, manual regression testing is also quite popular.
Manual.
Implementing automation on small projects that last only a few months is not always advisable. Its cost may not pay off, and the autotests development will only delay the whole project implementation. In this case, testing is performed manually without any special tools, except for the bug-tracking system (for example, JIRA).

However, if the project grows, the software functionality increases with each new release, and this entails a volume of tests increasing. In this case, it is worth attracting specialists in automation.
Automated.
To do the tests automation, it is necessary to involve only specialists with certain skills, for example, knowledge of programming languages.

The benefits of tests automation should not be underestimated:

  1. It is possible to significantly improve the quality of the product.
  2. Accelerate product launch
  3. Optimize the cost of testing
By the way, there are such projects where it is reasonable to combine manual checks with automated ones.

It all depends on the specifics of the software product.

According to the World Quality Report 2018-2019, about 26% of the total companies' IT budget goes to testing. The experience of various IT projects confirms that 40-70% of these costs are spent on regression testing.
Simplicity is not the absence of clutter; that's a consequence of simplicity. Simplicity is somehow essentially describing the purpose and place of an object and product.
Stay tuned!

We love what we do and do it with pleasure.
QAcamp team

You may also like: