How to quickly find bugs that prevent release

I got into the management of the project, which, due to the unorganized processes of its control and monitoring, was in very poor condition. I will not list the full list of problems and all the steps taken to solve them, because I want to share the experience of finding bugs quickly, the correction of which will most likely be enough to release and deliver the product to the client.

So, given: the project to develop an interactive online simulator, the product stage is open beta.
Task: quickly and as cheaply as possible to find bugs that prevent the release, fix them and pass the product to the client.

To solve the problem, a scheme was developed in which the freelance testers involved were motivated to find as many bugs as possible, while the total budget would not exceed the amount set in advance.

This was achieved thanks to the introduction of the dependence of payment on the number and categories of bugs found . Also, the maximum payout amount was set so that it was possible to determine the maximum budget in advance, but so that the tester did not stop after typing the maximum amount, a bonus was added, which is added 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. For testing, 2 scenarios were used, it took place on the weekend, 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 completed the task for freelancers, I could not find a suitable description of the error categories on the Internet, so I made it myself. Perhaps it will be useful to someone:

• Category A (I). The presence of errors in this category blocks access to the main functionality of the product for the user. These may be errors associated with registration, authorization and / or errors, the occurrence of which prevents the user from moving further along the course regardless of his current state.
  
  
• Category B (II). They restrict access to some functionality that does not affect the completion of the product or do not allow the user to advance in the course, depending on the previous steps taken by him, forcing him to start some part of the course to go through again.
  
  
• Category C (III). Errors of this category do not directly affect the process of using the product, but worsen the integrity of its perception or impression of the process. This includes layout errors, incorrect display and layout of graphic elements, delayed response of controllers, etc.
  
  
• Category D (IV). Errors in this category are not essentially errors. The category was introduced so that the error could be assigned if it is related to the functionality, visualization and other properties of the product, the implementation of which the tester differs from what was supposed to be implemented.

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

Thanks for attention!