Hey hey hey guys, today I will post about how to manage a risk analysis and what type of questions you should ask when descoping scenarios from your regression pack.
Regression testing must cover certain conditions in order to be effective.
Regression coverage isn’t a question of the number of cases as much as covering the conditions that
- Ensure functionality works
- Bugs found have been resolved
- A functional area can handle some amount of negative or destructive behaviour
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 questions you should keep in mind are:
- Is this feature stable ?
- Is this feature dependent on other less-stable features ?
- What will happen if this feature fails in a subtle/medium/catastrophic manner ?
You can find some techniques to develop a risk analysis:
- A close reading of the requirements specification, design specifications, user documentation and other items.
- Pair-wise, you can use a tool to mix the scenarios with different combinations and reduce the scope of your regression pack.
- A sequence of one-on-one or small-group sessions with the business and technology experts in the company.
- A tool built from Six Sigma DMAIC model. You can simply write down each function and it’s permutations in any manner that works for your business. The whole development team provides input, while the QA professional manages the document and detail of the information and input gathered.
If you are in a small company, like a startup, my opinion is: You can write the scenarios for you regression pack and ask for some developer to review it. So, you will have a regression pack built with their product code knowledge and you with your global view. QA ends up with factual data on what areas and functions of the application are most critical.
Finally, you put together a regression pack that focuses the higher priority functions while exercising the lesser functions less in depth. The key is to test the higher risk areas first and frequently, while still testing the lesser risk functions more superficially or via rotating test suites based on priority or risk.
It seems too simple, but it works to improve communication between team members while also documenting application functionality.
Stay updated with the last features, your regression pack needs to be fresh with the scenarios. Each new version will contain some new feature as it also can remove an old one. It’s important to try to execute that final test cycle with the freshest view you can.
Resources:
http://istqbexamcertification.com/what-is-risk-analysis/
http://www.growingagile.co.za/2012/12/breaking-down-user-stories/
http://searchsoftwarequality.techtarget.com/answer/Regression-testing-How-to-select-test-cases
Rafaela Azevedo 