Organizing manual testing at the release stage is a set of measures for the quick and effective detection of defects in the version of the product prepared for deployment, focusing on the most critical and frequently used functions.
Background: In the past, releases were often accompanied by "night emergencies": testers rushed to check everything, which harmed the quality of testing, bugs "flew" into production, and resources were spent inefficiently. Eventually, it was noticed that with clear prioritization, better results could be achieved in less time.
Problem: Limited time for testing before the release does not allow for everything to be checked, and human factors such as fatigue, haste, and stress increase. Often, critical bugs only surface after deployment, undermining the product's reputation and creating chaos within the team.
Solution:
Key features:
Can you "play it safe" and manually check the entire application before the release?
No, usually there is not enough time for complete manual testing — a balanced approach focusing on key scenarios provides better outcomes.
Should you disclose "minor" bugs before the release so the team knows about them in advance?
No, in release mode, it's essential to escalate only critical and blocking defects, while less significant ones should be documented as known issues and addressed post-deployment.
Is it mandatory to write detailed test cases manually for the release stage?
No, it's often easier and faster to work with checklists or mini-scripts derived from test cases, allowing for a quick review of relevant scenarios.
Release testing is conducted at night while briefly checking documents, forgetting about the critical payment flow. The next day, users are unable to process payments en masse.
Pros:
Cons:
Before the release, the focus is solely on critical scenarios (login, payment, order preservation, integration with partners). Results are run through a checklist, and bugs are escalated immediately.
Pros:
Cons: