If you are an active tester on the test IO platform, you have probably received invitations to test the same customer product every week or even every day.

Why do we have such recurring tests? It is simple – test IO's customers have the possibility to schedule tests as often as they would like to have their product tested. This means that some of their tests run on a daily or weekly basis if they like. This also means that you will most likely never run out of projects to participate in!

Although recurring or scheduled tests tend to have similar instructions, device requirements, etc., it is strongly advised to always read through the test instructions carefully for possible updates. Since the products in recurring tests have been tested regularly by the testing Community, there's a higher chance for such tests to have a longer Known bugs list than usual that you will have to consider before submitting a bug. However, it doesn't mean that there are no bugs to be found in such tests – Such websites/apps are usually updated regularly, which creates room for new bugs to occur. Furthermore, bringing your fresh perspective will also help you find bugs that have been overlooked by other testers in previous tests.

Repeated bugs in recurring tests

In recurring tests, you are asked to test the same product over and over again and it is possible for the same bug to be found in subsequent tests.

In which cases are you allowed to repeat a bug from a previous test?

  • The original bug was accepted by the customer in the previous test but was not added to the Known Bugs list.
  • The report was rejected as a known bug but was not added to the Known Bugs list.

❌ In the following cases, your repeated bug will be rejected by the Team Leader:

  • The original bug report was rejected by the customer for “not relevant”
  • The original bug report was rejected by the CSM for “not relevant”
  • The original bug report was rejected by the customer for “device not relevant”
  • The original bug report was rejected by the customer for “only occurs in the testing environment”
  • The original bug report was rejected for “behaviour/design is intentional” (not a bug)

In the following cases, the Team Leader will decide on a case-by-case basis, since it is dependent on the customer and the test setup:

  • The original bug report was rejected by the customer for “cannot reproduce”
  • The original bug report was rejected for “test instructions were not followed”

How are repeated bug reports handled?

Since repeated bugs in recurring tests are not a result of creative exploratory testing, we consider them a form of reproduction. Such bugs are less valuable for our customers who have already been informed about these issues multiple times in the past. Therefore, the payout for repeated bugs is reduced to 30% of the original bug payout.

Please note that the bug report doesn't need to be an absolute copy to be classified as repeated as long as the essence of the bug is the same.

If your bug report gets marked as repeated, you will be notified about it with the following message (only when you are online):

Did this answer your question?