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 ?
- 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)
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.
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
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.
Program Manager (QA & QC)
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.
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.
Bugs appear or re-appear or pop-up due to, too many reasons.
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