Quality Testing

Quality is delighting customers


Hello colleagues ;


We are suffering from something makes our work out of control !!

This thing is: we (the quality team) found bugs then the developers resolved them,and we closed them during the regression testing phase.but on the upcoming releases we found that bugs again !!!


So please i need to know what are the possible reasons that make this case happened ?


Many thanks

Views: 219

Reply to This

Replies to This Discussion

- maybe they were only updating the test-system, not the live-system or the live-system was an older version

- the original bug(s) weren't fixed, but changed so your testsuite might missed it (maybe an UI-problem)

- the bug appears only at specific circumstances (could occur when generating input randomly)

- bug appears only once and after that it won't appear again (so the original bug wasn't fixed, maybe they fixed it so the bug now occurs all the time)


good luck



Hey i don't know which procedure u r following but from my prespective i will give some points

1. When u r doing build, every time use version control method. It helps to keep code update. always use latest code & maintain it on centrilize server system so every one can update final code on this centrilize server.

2.Once final build is done do the sanity test.

3.If have sufficent time then do not test defects on dev. local server, always prefer to test any defect after final build.


If you got any good way to prevent this bug occouring, pls tell me.






Possible reasons:

i.They might have not updated the changes of code in the production environment.

ii. QA team might not have tested it thoroughly once the defect is fixed

iii. Environmental issues & lot of inconsistency in the application.




Srikanth Koushal V

Mr.Nihad Kamil


Its genuine interesting question as practically I came across this serious problem. I re-engineered the process that we followed to curtail defects almost to zero. The origin of this problem is that missing integration of bug-fixes. It means selecting base code for next version is wrong especially when code is not centralized or not maintained by authorized department to issue base code on which further development should take place leads to this kind of mess.


Secondly from testing team, I strongly suggest you take the source code and build executable code so that you have a proof of the defects which are resolved in so and so version and it was tested and certified.


The other alternative is, tracking defects with different status like (Open, Fixed, Fix-Integrated, Resolved, Closed). So it is very clear that the bug-fix is integrated in so and so version with other details. Here 'Resolved' status used by testing engineer after verification of bug-fix and 'closed' is authorized by Test Manager after confirming from the Defect identifier.


I hope you might be thinking in same direction.


G.N.Mallikarjuna Rao

Program Manager (QA & QC)



Same problem with me.



The probable reason could be that the changes are not 'checked in' in the latest build. Check your version control system to see the updates or check your latest deployment log.


This is an inevitable part of the job, but there are things you can do to reduce the frequency. On the quality team side, does anyone check whether the bugs in the upcoming release are actually present in the previous release? When you find the bug again, how do you know it was tested in exactly the same way that it was tested in the previous release?

On the development side, it is possible that the bugs appear in a particularly fragile or complicated part of the software. There could be a specific developer who creates a lot of bugs. Or the software may change hands frequently; in other words, there could be many developers who all work on the buggy part of the software. If those developers don't communicate enough, or if the code is not well-enough documented, it is possible that developers re-introduce bugs because they don't understand the software. It is possible the developers do not spend much time testing the buggy parts of the software. Or the developers don't test it the way you test it. Sometimes a developer doesn't have the resources (e.g. enough computers or a big enough database) to test something as thoroughly as they would like like.

I don't know anything about your organization, but it's probably not your job to diagnose or blame developers for re-introducing bugs. The most valuable thing you can do is to be absolutely sure that the bugs really were fixed in the previous release, track the regression rate, and share that information with the developers. It is the development manager's job to figure out how to fix the problem.

Hi Bill,


On the quality team side, does anyone check whether the bugs in the upcoming release are actually present in the previous release?

I consistently do this just to avoid the glare of customers. We term it as “Escape Analysis”

When you find the bug again, how do you know it was tested in exactly the same way that it was tested in the previous release?

By referring to the previous Issue report, using test data by trial and error method.




Thanks Siddiq.  I would also like to hear the OP's answer to those questions.

Bugs appear or re-appear or pop-up due to, too many reasons.


Poor requirements,

Incorrect design,

Inappropriate coding,

Inefficient testing,

Unscheduled change request,

Insufficient time & cost,

Inefficient communication,practices, process and many more reasons.


Some solutions which won me results,


1) Extensive requirements and raising flags early

2) Improving communication with BA/Stakeholders/Dev/Customers/End users

3) Static Testing techniques

4) Health check, smoke testing the application everyday

5) Decisive regression suite execution

6) Escape & Impact analysis

7) Handy process without rubbing too much onto the team

8) Documentation of every activity




Thanx all for your valuable knowledge


TTWT Magazine





© 2021   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service