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.