In IT environment people believe that regression testing is an unnecessary activity. All in all, when something has been checked once, it doesn’t have to double-checked. For many, it’s not only a waste of time but mostly a waste of money. What exactly regression testing is and why is it worth using?

 

One of definitions says that it is:

 

(…)tests performed in order to find potential defects which can occur because of changes introduced to software.”

 

It means that a client will not receive software which can contain mistakes in the areas that have been checked and delivered before. As it turns out, it is most often the critical point in incrementally realized projects.

 

Let’s imagine the following situation. Our task is to deliver a well-working application to one of banks. After some time, we deliver a product which works perfectly. Both the client and his clients are satisfied with the application, its functions and its clarity. Some time later, the same bank orders another functionality for the same product. Obviously, the company is excited and managers are happy to have another commission. Don’t forget that this is the right moment for regression testing.

At the beginning, we should focus on running an analysis which will show if what the client has ordered will not collide in any way with what he has already received. During an upgrade of already existing system, we have to make him sure that the current functionality will not become damaged by the new implementation.

 

Clearly, we are talking about update which penetrates or connects to already existing functionality. That is why we as well as our client have to be sure that the functionality written before has not been breached, and we need to define regression tests.

 

A tester along with a technical person should specify new tests – created on the basis of already existing ones. This way, it’s much easier to choose and check areas which penetrate each other in the new implementation. However, when we know in advance that we are going to deliver new functionalities incrementally, it’s worth choosing the tests which should or could be a part of regression testing. This approach will make its specification time shorter at a later date.

 

Unfortunately, it most frequently happens that tests are committed with too little time, or they are performed at the last moment. In the end, this approach causes the testers to have the whole attention, including the client’s focus. The reason is time which makes the project longer. Additionally, sometimes it happens that there are too many specified regression tests to do the job immediately after the tests covering a new functionality.

 

In this situation, a risk analysis technique should be applied as well as we need to specify a test group which is critical from the point of view of already working functionality. Nevertheless, even then there is some risk that we will not have enough time to perform all the tests. Another technique which can be used is setting priorities for each regression test. This technique is about determining the importance of every test. A tester conducts the tests according to their priority, in time which was given to do that. Then we can be sure that the most critical tests have been performed; while those with less priority which could not be done in the available time should be placed in a special report which include the information concerning the tests which have not been carried out.

Obviously, if we have some part of the project budget left, it would be recommended to perform the rest of the regression tests after delivering the new version of a software to the client. That would later make us sure that there have not been any regression in the existing function in the delivery.

 

Some people might be tempted to claim that I present the situation only from one point of view. I do not want to be misunderstood so that is why I would like to highlight that time pressure is put on every individual involved in a project. Sometimes, at the very beginning the time frames imposed are so narrow that we do not have any time for mistakes or possible corrections. It also happens that even if the project is already pumped up, another functions are added as they seem equally important from the client’s point of view. Work in this kind of project is really hard as time pressure is accompanied by frustration when the team does not cooperate with each other or is not managed properly. Then it is really difficult to talk about closing everything within the time frames given. Mistakes are created and the responsibility is switched from person to person.

 

That is why it is so important to take time into account for all tasks realized in a project and to give them workable time frames or priorities. I put emphasis on that as regression testing is the type of activity which inherently just takes a lot of time.

_All posts in this category

blogpost
Articles

eSignature – how can it solve your business’s problems?

The growing popularity of electronic signatures has increased the pace. According to forecasts, this market will grow by an average of over 20% annually, reaching the value of nearly $7 billion in 2025. The market growth is one thing, but the question is: is this really worth our attention?

Read more
blogpost
Articles

How to efficiently perform a digital transformation in your company?

Digital transformation is becoming more and more present in nearly every business and indicating its presence by changes in work management and organisation style. Although we still hear the echoes of the discussion about the importance of all the fuss about digitalisation, more and more frequently we deliberate how to implement solutions to automate processes in our company.

Read more
blogpost
Articles

Internet of Things in energetics

The turn of XVIII and XIX century was undoubtedly a gold age of electrotechnology in human history. Many contributed to the success.

Read more
blogpost
Articles

Tester’s work fosters saving!

For unknown reason, there is a common conviction that testing in the software creation process is not a significant element of the project. Sadly, such approach can cause a company to incur much higher costs than initially planned. Why? Because it is a sort of a ticking time bomb. It turns out that in the […]

Read more
blogpost
Articles

Theory vs. reality – what’s the deal with quality and software testing?

At a certain level, we all know the theory as it defines our experience, teaches processes and helps in technical discussions. But is it really true that the picture-perfect theory applied in everyday life always gives the expected results? Do companies that have established processes based on theory face no problems with running projects and […]

Read more
blogpost
Articles

Front-end microservices

How to solve the problem with the organization of a web application when monolithic approach is not feasible? Why does server-side rendering deserve a comeback? Do micro frontends make any sense? This article shall discuss how the topic of the segmentation of web applications into smaller fragments can be handled. Introduction The architecture of microservices […]

Read more

Let’s get in touch

Contact us