How to Test Software Before Launch: The QA Process Explained

Launching new software is always a risky moment for a company – the more complex the system, the more places where something can go wrong. The QA process before a software launch is precisely the tool that systematically reduces this risk before the software ever reaches real users. For a manager who doesn't develop software but decides on its rollout, it's important to understand at least the basic logic of testing – not so they can write tests themselves, but so they know which questions to ask the vendor or internal team.

This article explains what phases make up the QA process, who is involved in it, and what to watch out for, even if you don't understand programming.

Testing software before launch is often seen as an internal technical matter that will somehow "sort itself out" in the final days before going live. In practice, it's exactly the opposite – the later testing begins, the more expensive and stressful it becomes to fix problems. A bug found at the design stage is fixed with a single change to the specification. The same bug found after going live can mean system downtime, lost data, or unhappy customers.

That's why the QA process should be part of planning from the very start of the project, not just the last item before handover. When software is built to order, testing is one of the phases the vendor should include in the schedule just as naturally as the individual phases of custom software development described in the article on how custom software development unfolds step by step – not as an add-on done "if there's time left".

Software quality control happens in layers – each one verifies something different and builds on the previous one. The overview below simplifies the usual process so that it makes sense even without a technical background.

Unit tests: basic code-level checks

The lowest layer of testing verifies individual, small pieces of code (functions, methods) in isolation from the rest of the system. Developers write and run these directly while writing the code, and their purpose is to catch logic errors before they propagate further. This layer is usually automated and runs repeatedly, practically with every code change.

Integration testing: verifying that modules work together

Software is usually made up of several modules – a payment gateway, a database, a user interface, connections to external APIs. Integration tests verify that these parts actually work together as intended. This is often where problems surface that unit tests can't catch, because the individual parts worked correctly on their own but didn't cooperate well together.

System and end-to-end testing

At this stage, the whole system is tested as a unit, from the perspective of a real usage scenario – for example, the complete process from placing an order through to processing and invoicing it. The goal is to verify that the individual parts of the application flow smoothly into one another and that the system behaves predictably across the entire chain of steps, not just within isolated components.

UAT – testing with the client involved

User Acceptance Testing (UAT) is the phase where the software is tested by people on the client's side – future users or authorised company representatives. They verify that the system actually solves what it was meant to solve and that it matches the brief from the point of view of an everyday user, not just the technical specification. This phase is the most visible one for management and a good opportunity to ask the vendor questions before going live. The vendor's ability to run this phase transparently is also one of the criteria worth checking already when choosing a software vendor.

Performance and security testing

Besides functionality, testing before launch also checks how the system behaves under load (performance testing) and whether it contains vulnerabilities that attackers could exploit (security testing). This layer is especially important for systems that handle personal or financial data – a useful reference point for what to check is, for example, the list of common vulnerabilities in the OWASP Top 10, publicly available at owasp.org.

The principle of the testing pyramid was described by software architect Martin Fowler and is a useful tool even for a non-programmer when assessing whether a vendor's test plan looks balanced (source: martinfowler.com).

The QA process isn't the work of one person. Typically, several roles are involved:

• Developers – write and run unit and integration tests directly during development.
• QA engineer / tester – prepares test scenarios, carries out system and regression testing, and logs the bugs found.
• Project manager – coordinates the testing schedule and communicates readiness status to the client.
• Client representative – carries out UAT and confirms that the result matches expectations.

For management, it's useful to require a clear log of the bugs found – who reported them, how severe they are, and what stage their resolution is at. Such a log can be kept simply, but on larger projects it's worth having it in clear dashboards instead of manual spreadsheets, similar to moving to automated reporting for company leadership.

A well-set-up QA process has a clear sequence of steps:

1. Test plan – defines what will be tested, using which methods, and against which success criteria.
2. Preparation of test scenarios – specific use cases to be verified, including edge cases and error states.
3. Test execution – progressing step by step through the layers described above.
4. Bug logging and triage – every issue found is recorded, rated by severity, and assigned an owner.
5. Retesting and regression testing – after a fix, checks confirm that the bug is resolved and that the fix hasn't broken anything else.
6. Release-readiness decision – based on the results, a decision is made on whether the system is ready to go live or needs another iteration.

It's important to realise that the QA process doesn't end once the software goes into production. After launch comes monitoring, gathering feedback, and ongoing fixes – this phase is covered in more detail in the article on software maintenance and development after launch.

Even though management doesn't write the tests themselves, several decisions made at that level have a direct impact on the quality of the resulting software:

• Testing is planned only for the end of the project. If testing is squeezed into the last few days before launch, there's no time for a proper retest after fixes.
• UAT is treated as a formality. Real testing of key scenarios by real users is irreplaceable – automated tests can't verify whether a solution "makes sense" in everyday practice.
• There's no clear "ready for launch" criterion. Without defined criteria (for example: no critical bugs, all major scenarios verified), the launch decision is made intuitively, which increases risk.
• Testing of new technologies is underestimated. When deploying AI functionality or automation, specific risks appear that classic testing procedures don't fully cover – an overview of typical failures is offered in the article on the most common mistakes when deploying AI agents in companies.

Software quality can't be "tested in" at the last minute – it's the result of how testing is planned from day one of the project.

The QA process before a software launch consists of several interconnected layers of testing – from checking individual functions in the code through to verification with real users. Management's job isn't to carry out the tests, but to make sure they have enough room in the schedule, that there's a clear log of bugs, and that the launch decision is based on predefined criteria rather than time pressure. When choosing a vendor for custom software development, it's worth asking specifically how the testing process works and who on the team is responsible for quality. If you're considering a new project and want to discuss how the QA process should be set up in your case, book a no-obligation consultation.