Regression test

Discussions
, ,
1

“Let’s say a change was made in a part of the code, and you were asked to perform regression testing. How can you understand which parts of the system might be affected by this code change? In other words, how do you determine which modules or functionalities are connected to the section of code that was modified?”

1 Like
2

Firstly, I’d expect a handover, which should clearly explain what was changed so you know what areas might be affected. - Trying to test without information isn’t a great situation to be in.

If the handover doesn’t give enough detail, I’d check the repository, where the commit history and change notes should show exactly what was updated and help you understand what parts of the system to focus on.

1 Like
3

Hi,

Pretty much whats in the first comment. What I do is I always ask from dev who made the change: what he thinks the impact would be? because he is the making change and can tell better, ask them to add those impacted areas in the ticket. Thats shall be unsaid rule for Regression. To the least share impacted areas in the ticket.

Thats where you can start your testing. Not only that, you might need to test feature to make sure nothing else has been impacted truly by your product knowledge and instinct. (however make sure to time box it).

Good Luck! :slight_smile:

4

thanks for your answer

5

I said the same thing in the interview, but the person asking the question asked, "What will happen if the dev doesn’t answer or you can’t ask him?

6

I would have answer or you can answer next time:

a) First of all there is always a way to communicate, thats what the make teams best. if not for some reason:

b) I can check the PR - what changes have been made. (as Saviski said in first comment) :slight_smile:

7

Even if they mention the modules impacted… go one step ahead and ask these as well

  1. This change in module what is it business logic changed? or any validation added? Error handling? API Integration or updated? only UI Change /Rendering ? Or any state management ? Any DB changes

  2. Dependency Mapping : Upstream : Who calls this changed code? Downstream : who is called by this changed code

  3. Ask the PO or Dev what was the intent of this change? Intent tells you what should change , everything beyond that is risk

  4. Get Access to architecture diagrams or PR diffs , API doc or API contracts and do the analysis urself