Any test case that you decide not to run, or to run less often introduces some level of risk that you will miss a bug. However, each legacy test case comes with a cost to run which introduces expense to the project. Evaluating your legacy test cases to reduce redundancy, prioritize, and summarize can allow you to move forward to testing new functionality.rnPrioritizing tests can help save time by running the same legacy tests, just less often. If the test doesn't fall into one of the most used workflows or one of the top priority experiences that the software is delivering, it isn't in the top tier. A test being in the top tier means that the test failure will stop shipment of the product. The next tier of tests should be run until Release Candidate submits. Bugs in this category most likely will be fixed if the test fails so long as it can be fixed without jeopardizing the product schedule. The final tier is any test case which must be run during the product cycle which doesn't fit into the first two tiers.rnSet out in your test plan what legacy workflows you are protecting and what you are consciously deciding not to test, and why that decision was made. When you have the guts to not test the low priority areas and get stakeholders to sign off on it, you are recognizing and avoiding a larger risk. Adding more and more test cases without ever taking any away is an even bigger risk. If every legacy test is of equal importance, with every new version you need either an exponentially growing QE staff, a schedule that gets longer for testing each time, or you reduce risk by taking on less ambitious new functionality.
展开▼
