How to quickly find bugs that interfere with the release

I managed to manage a project, which, due to unsuccessful processes of its control and monitoring, was in a very poor condition. I will not list the complete list of problems and all the steps taken to solve them, because I want to share the experience of quickly finding bugs, the correction of which is likely to be enough to release and hand over the product to the client.

So, given: a project to develop an interactive online simulator, the product stage is open beta.
Task: quickly and as cheaply as possible, find release-preventing bugs, fix them and hand over the product to the client.

To solve the problem, a scheme was developed in which the attracted testers freelancers are motivated to find as many bugs as possible, and the total budget will not exceed the amount set in advance.
')
This was achieved by introducing the dependence of payment on the number and categories of bugs found . Also, the maximum payout amount was set so that you could decide on the maximum budget in advance, but in order for the tester not to stop after he raised the maximum amount, a bonus was added that adds to the payment if this tester found bugs worth more than all the others.

The experience was very positive, both for the project and for testers. Two scenarios were used for testing, it took place on weekends, and on Monday I already had 84 bugs (3 categories A, 15 - B, 62 - C and 4 - D), designed according to the requirements. After fixing all these bugs, the product was released.

By the way, when I designed the assignment for freelancers, I could not find on the Internet a suitable description of the categories of errors, therefore I compiled it myself. Perhaps it will be useful to someone:

• Category A (I). The presence of errors in this category blocks for the user access to the main functionality of the product. These can be errors related to registration, authorization, and / or errors, the occurrence of which prevents the user from progressing further along the course regardless of its current state.
  
  
• Category B (II). Restrict access to some functionality that does not affect the completion of the passage of the product or does not allow the user to advance along the course, depending on the previous steps taken by him, forcing him to start some part of the course again.
  
  
• Category C (III). Errors in this category do not directly affect the process of using the product, but degrade the integrity of its perception or impression from the process. This includes layout errors, incorrect display and location of graphic elements, delayed response of the controls, etc.
  
  
• Category D (IV). Errors in this category are not in fact errors. The category is introduced so that the error can be assigned to it, in case it is related to the functionality, visualization and other properties of the product, the tester's implementation of which is different from what was intended to be implemented.

If someone has questions about the content of the post, I will answer with pleasure.

Thanks for attention!