Let's say you're between builds. You have one build coming that has fixes in it. You have corrected bugs that are waiting for that build. Fine. Say you've also got bugs that were passed in a previous series of builds.
So now how do you spend your time with the current build of the product? Do you re-test the passed bugs (from all previous builds) specifically? Or do you just do regression of test cases without reference to specific bugs? Or do you do more exploratory type stuff to see what you have done?
I guess real question is this: how often do you go back to bugs that were passed and re-test them? Do you do that every build? (I mean say you've got bugs that were passed from three builds ago. Do you still go back and re-test them on each and every build you get?)
It depends on several factors. If the bugs were in a section of code that has a history of problems, or the developer who fixed them is known for breaking other stuff, then you should test the bug fixes again after a couple builds. If, on the other hand, they were simple changes in well-developed code, then you shouldn't have to worry about them.
I wouldn't suggest spending all of your time between builds just checking old bugs. If possible, you might have one person look at previously fixed bugs, and let the other testers work on something else (regression, exploratory, or whatever.) The problem with focusing on old bugs is that existing bugs will stay in the software longer. It can be frustrating to find a bug in the current build that has been there for the last several builds, but no one caught it.
I agree with PedroG but partially. Still making one person responsible for looking at old bugs can be very impractical esp. whenever resorce crunch is there, as is the case w.r.t. most of testing projects.
Better way to do it is round robin allocation of people per build to check old bugs. Bug selection criteria can be sequential, hased or any other standard sampling method but randomness should be avoidable for productivity and optimum utilisation.
1. Get Release Notes from the Developers.This can help the QA Team in knowing which are the Classes/Modules/Areas in which changes have been made or bugs have been fixed.Test these areas with utmost care with HIGH PRIORITY.
2. Analyze and findout the Problem prone areas.
3. Findout the Areas where "Side Effects" can creep in. Check for New Bugs related to side effects in these areas.
4. Allready posted bugs on these problem prone areascan be regressed.
5. As suggested above, its not a bad idea to allocate one dedicated resource, just to check the old bugs.Offcourse that particular person must have versatile knowledge about the SUT. After all, he may have to check the bugs posted
by someother person also.
[i]Work Like u don't need Money...Love like u have never been Hurt...Dance Like Nobody is Watching...Sing Like Nobody is Listening...Live like its Heaven on Earth!