5

In an application that is currently in production, one module of code is being modified. Is it necessary to re-test the whole application or is it enough to just test functionality associated with that module?

1
  • 1
    You question title and description are not matching at all. Also, it is too broad to answer this question this way, as it all depends interaction of changed module with other modules and features. You should first search for its answer over web. – Dhiman Oct 7 '15 at 15:23
5

I would say there is no concrete answer to this. Sure there are idealistic 'regression test everytime', but we are rarely afforded the luxury.

So it then comes down to risk management.

  1. Is this module critical - ie worst case scenario what can it break. Ex:
    Is it a change in how a profile is being saved? Is the profile being used as part of the whole system or is it just a side page that doesn't have any critical parts?
  2. How much time do you have?
  3. Is this module known to be very complicated? or is it super straightforward?

These are sort of basic questions that come down to estimation of any type of testing but becomes more important in the 'just one change'. You want to make sure you cover the worst case scenario and know what can be the fallout from not having regression tested it. And make sure the team knows about the risks. It might be worth it to just test the code change itself, or you might be shooting yourself in the foot. It really depends on system and feature complexity (and in developer skill as well).

2

This is the simplest of question which is handled by a simple google search.

I am assuming you are not a part of QA team.

Nevertheless, it is always better to test whole application- not every thing but only the critical parts, to ensure after the change, nothing is broken. This is called Regression testing.

Please read about it here

2

Not necessarily, if you can clearly understand the impact of the changes and how the underlying code effects other parts of the system. I would do a risk analyses with the developers and decide which parts need re-testing.

If you build the application on top of something like micro services and each part has a clear interface it should be very doable to locate all the elements the change has impact on and only test those.

Even better automate all of the testing and let the build server do the work for you.

1

As Niels wrote you do not need to test the entire application but you can limit your test to the part of the software affected by the code changes. I would even add that if the output of the modified software is the input of another module (e.g. your software produce a csv file that you load with another module for plotting the csv data) you have also to test that module.

1

I regression test all associated modules and functionality with a bug fix, not just the 1 module where the fix was made. As previously mentioned, this is the purpose of regression testing (to verify nothing was broken when a modification was made; to verify that functionality did not regress.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.