EXPERT RESPONSE
There are a couple of reasons that answering your question by a metric such as selecting one, two or three cases is difficult as well as potentially dangerous.
Regression coverage isn't a question of the number of cases as much as covering the conditions that 1) ensure functionality works, 2) bugs found have been resolved and 3) a functional area can handle some amount of negative or destructive behavior. Regression testing that addresses all three aspects should guide your testing efforts more than focusing on the number of cases.
Assessing coverage by the number of test cases is difficult -- one case can cover many conditions or one case could provide coverage of only a single condition. If I provided a response by a metric of one case will cover what is needed, you might be underestimating regression testing that such a response would be potentially dangerous or misleading.
So addressing the question how I would plan regression testing might be more practical. The answer varies so I'll use a couple of examples.
I recently retested a defect that was related to column sorting on a Web page. For retests, I built a quick grid in Excel outlining the column sorting available going across in columns and a list of pages where sorting was available in rows. I choose to retest all the combinations because sorting had two prior defects reported and the amount of testing needed was not an extensive effort -- so I choose to execute a full retest. If the amount of retest time was extensive and I wasn't able to cover all the conditions, I would have used the same grid to determine the most likely combinations and covered those conditions. If the selection is large, there is a tool that can help you make that assessment See James Bach's tool, Allpairs.
|
|
 |
In another recent experience, I retested a defect and after closing the bug, I allocated time for a test session mixing what would be deemed positive and negative tests. I knew the functional area was an important feature for the product release. After testing several conditions, I referred to the product notes recorded on the team wiki to see if there was anything else I thought I should cover. Sometimes I reflect back to early testing notes to choose retest ideas. Another tip is to talk with developers. Sometimes when I'm retesting an area, I talk with the developers to learn how bugs were resolved, which can affect how I plan retest efforts.
A final comment on regression testing, I tell myself this all the time: Stay fresh, your testing is likely the final view of the product before it ships. As much as you have likely seen multiple internal builds, it's important to try to execute that final test cycle with the freshest view you can.
|
