A typical approach is for a lead tester or QA or Test manager to be the release decision maker. This again involves significant assumptions - such as an assumption that the test manager understands the spectrum of considerations that are important in determining whether software quality is 'sufficient' for release, or the assumption that quality does not have to be balanced with timeliness and cost. In many organizations, 'sufficient quality' is not well defined, is extremely subjective, may have never been usefully discussed, or may vary from project to project or even from day to day.

Release criteria considerations can include deadlines, sales goals, business/market/competitive considerations, business segment quality norms, legal requirements, technical and programming considerations, end-user expectations, internal budgets, impacts on other organization projects or goals, and a variety of other factors. Knowledge of all these factors is often shared among a number of personnel in a large organization, such as the project manager, director, customer service manager, technical lead or manager, marketing manager, QA manager, etc. In smaller organizations or projects it may be appropriate for one person to be knowledgeable in all these areas, but that person is typically a project manager, not a test lead or QA manager.

For these reasons, it's generally not a good idea for a test lead, test manager, or QA manager to decide when software is ready to be released. Their responsibility should be to provide input to the appropriate person or group that makes a release decision. For small organizations and projects that person could be a product manager, a project manager, or similar manager. For larger organizations and projects, release decisions might be made by a committee of personnel with sufficient collective knowledge of the relevant considerations.