What I’ve found is that coverage is a good start, and may be sufficient for most teams (among teams that can’t run all their tests quickly on every build). However, adding a few other selection factors (or heuristics) and applying a few weights can take you a step further.
Some heuristics I’ve used in the past for test prioritization/selection include :
- Has the test already found a bug? Some tests are effective in detecting product bugs. I give more weight to these tests.
- When was the last time the test was run? If a test has been run every day for a year without failure, I don’t give it much weight. We testers are always paranoid that the moment we choose not to run a test, a regression will appear. This weighted heuristic helps solve the dilemma of running the test that never fails versus the fear of missing the regression.
- Test stability: If you’ve never had an unstable test, skip this step. For all others, it makes sense to run my tests that return false positives less frequently (or at the end of the test series).
- How long does the test take? I give more weight to tests that run faster {…}
Continue reading the full article here on Tooth of the Weasel, notes and reviews on software and software quality.
ABOUT OUR Q-LEAP EXPERT WHO RECOMMENDS THIS ARTICLE
Stefan Papusoi is a test specialist at q-leap. As a context-driven and exploratory tester, he is constantly expanding his experience in testing, script automation, and test process management and improvement.
