Stop testing after 5% of test cases fail

As a software tester, many times I have encountered that bug reporting software gets flooded by bug reports for a single feature. From my experience, usually, only a few of them are bugs. The rest of them are bugs caused by already reported ones.

The problem is that a great amount of time is lost in managing tickets and retesting the same cases over and over again. Time is always valuable in software development and usually, there is none to waste.

I have found the working solution following a simple pattern. Stop testing after about 5% of test cases fail. Of course, pattern rellies on testing basic test case scenarios first. Without working basics, there is no point in testing edge cases.

Try to follow the next 2 rules and you can spare a good amount of QA / BA / PM / DEV time.

The first rule is to develop your test strategy before you start testing. I am mentioning this because, in many companies, QA has no time to prepare test cases before testing starts. In this case, at least, before testing start write down test case titles and order them by priority, basics first.

The second and most important rule is to stop after 5% of basic test cases fail. From my experience, bugs found in the early stage will definitely impact the rest of the testing. The most common impact is that some case fails for the same reason as the last one. That means that bugfix will also impact both cases. This will prevent reporting 2 bugs instead of one. This will also prevent the developer from wasting time debugging the same thing 2 times.