Be on the same page with us
Subscribe to our latest news
By clicking the button Subscribe you give a permission for the automatic sending of e-mails

Tips for detecting new bugs (when old test cases don't work)

Often with time your tests don't uncover bugs anymore. You might feel a gerbil on the treadmill sprint after sprint. Why?

One of the answers is test repeatability. Have you heard about Boris Beizer's pesticide paradox?

Farmers use pesticides to get rid of bugs. The poison works perfectly. But the more of the same poison they use the less effective it becomes. Bugs develop immunity to the poison.Each type of visual aid has pros and cons that must be evaluated to ensure it will be beneficial for the overall presentation. Before incorporating visual aids into speeches, the speaker should understand that if used incorrectly, the visual will not be an aid, but a distraction.
November 14, 2017
Speaking the QA language, we have the following:

  1. We carry out a project, test a piece of software. To do our best we apply a mix of white-box and black-box tests for this software. The tests detect bugs – we report – everyone is happy.

  2. Since the software is getting more mature, new features are added to it. In the short run part of the tests is broken, however after being fixed they still run the same piece of functionality. They start to lack additional integration flows introduced by the added features.

  3. Another obvious (but often missed) case is when we sign off the releases based on the same standardized set of acceptance test cases. No new bugs are detected. But does it really mean they don't exist? It may happen that some new bugs have appeared when the fix and new changes were applied to the system. So the old set of test cases can't detect the new bugs.
What is the way out of this situation?

  1. Once per release spend several hours to change testing steps in your cases. Try to reach the expected result in more sophisticated way.

  2. Re-arrange the test suite. Sometimes this simple measure enables you to catch specific pre-condition state and uncover the issue.

  3. Try to use a different approach: test in black-box what was previously covered by the white-box scenario.
  4. Use 80 / 20 proportion for test cases running and ad hoc exploration. If you have experienced testers on board, ad hoc is often effective when used as an addition. On contrary for junior testers, try to avoid ad hoc wherever is possible.