Explain about regression of bugs

Showing Answers 1 - 6 of 6 Answers

In general, regression testing can be done if at all a new change request is done to the current code to re check existing code gets disturbed due to the new changes.

But we can do regression testing in one more scenario, if a change request is came, tested and found more than 10 issues, developer fixed and tester retested, closed, finally to ensure the existing functionality we are conducted one more complete round of testing on existing functionality called Regression testing.

And Regression of bugs: let us assume in build 1, you have found 5 issues, developer fixed the issues and given build 2, again re-opened 1 issue and sent to developer, again developer fixed the issue and given build 3, tester need to check the reopened issue along with already closed issues to recheck whether they gets disturbed or not.

  Was this answer useful?  Yes

Regression Testing is a repetitive testing which is done from second build
onwards where you verify that the bugs are fixed or not, changes in the
application, added new features and most importantly all the above changes were
not affecting other functionality.


One more reason why we do regression testing is, in single attempt we can’t
find all bugs and there might be some hidden issues, so we regress the
application again and again in order to trace as much as bugs as possible we can
for the sake suppose if you have 1000 test cases, in regression testing you will
execute all the 1000 test cases


Re-test is also a repetitive testing and is done in order to reproduce. for
example if you find a defect you wanted to make sure that the defect is
reproducible or not for the sake you re-test that functionality again and
whenever a bug is fixed by the developer and new build has came then you want to
make sure that the bug is really fixed so you will re-test that functionality
more than once


Regression of bugs : when the first release date is finalized, by that time
Developers will develop whole module or else part of module, so you get first
build on finalized date for testing and you will be informed what areas were
developed so far, so we execute acceptance test cases and after acceptance we do
execute remaining test cases that are part of that developed application and
raise the issues, during the time developers might concentrating on developing
whole build for releasing build 2, so the issues that were raised before release
of build 2 will be fixed based on severity, priority and time availability for
developer to fix the issues and included in build 2, so once you get build 2,
you will again do build acceptance testing and next regression testing begins
where you re-test the issues that you were raised and as well execute all the
test cases. Likewise you will involve till last build

  Was this answer useful?  Yes

Give your answer:

If you think the above answer is not correct, Please select a reason and add your answer below.

 

Related Answered Questions

 

Related Open Questions