Testing Before Go-Live

What testing is for

Testing before launch is not about proving that a system is flawless. It is about finding problems while they are still cheap to fix, and about giving decision makers evidence for a go or no-go choice. No test programme finds everything, so the aim is to cover the most important risks and to be honest about what has not been tested.

Different types of testing answer different questions. A system can pass technical checks and still fail users, or satisfy users in a demo and still break under real load.

The main types of testing

Unit and configuration testing

These are the lowest-level checks, often done by the people building or configuring the system. They confirm that individual features, settings, calculations and screens behave as designed. They are typically run by the project’s technical team or the supplier.

System testing

System testing checks the complete system as a whole against its specified requirements, in a test environment. It looks at whether the system’s functions work together, including security settings and workflows. It is usually run by a dedicated test team or technical staff, using written test cases traced back to requirements.

Integration testing

Integration tests check that the new system exchanges data correctly with the other systems it connects to: finance, identity services, reporting tools, partners and so on. They cover not only the normal path but also failures, such as a connection being down or a file arriving late or malformed. Because integrations are a common source of go-live issues, this deserves time. It relates to system interoperability questions raised in selection, and to the interfaces found in the current state assessment. Technical staff from both sides of each interface usually run these, with business input on what the data should look like.

Data migration testing

This checks that migrated data arrived completely and correctly, as covered in the data migration article. It includes trial loads, reconciliation of counts and totals, and review by people who know the data.

Performance and load testing

These tests check how the system behaves under realistic volumes: many users at once, large batches, peak periods such as month-end. They help show whether response times are acceptable and where limits lie. Results depend on how closely the test environment and data resemble production, which is why the limits of the test should be stated alongside the results.

Security testing

Security testing looks for weaknesses in access control, data protection and configuration. It should be carried out by qualified security professionals, and the findings handled under your organization’s security procedures. This article only describes the idea in general terms. Checks that access is set up as intended, such as role-based access control working as designed, also belong here.

User acceptance testing

User acceptance testing, often abbreviated UAT, asks whether the system supports real work. Business users run realistic scenarios, such as processing an order end to end or closing a period, and judge whether the result is acceptable. This is the key moment when the business confirms that the system meets its needs, so it should be run by the people who will use it, not by the project team on their behalf.

For good UAT:

• Base scenarios on real processes, including awkward cases and exceptions, not just the standard path.
• Use representative data, protected appropriately.
• Include users from different roles and locations.
• Give testers time away from daily duties, since testing squeezed into spare minutes is rarely thorough.
• Provide a simple way to log issues and track them.

Regression testing

Whenever a defect is fixed or a change is made, earlier tests may need to be repeated to ensure nothing else broke. Without regression checks, fixes can quietly introduce new problems.

Rehearsals and operational readiness

Beyond functional testing, rehearse the cutover itself: the data load, the sequence of steps, the time each takes, and the rollback procedure. Check that support teams, knowledge base articles, monitoring and escalation routes are ready. Training also matters; system training approaches should be in place so users are not meeting the system for the first time on day one.

Who should test what

The exact split depends on the size of the organization and the project. In small organizations the same few people may play several roles, which makes it more important to be explicit about what has and has not been tested.

Test environments and data

Testing is only as realistic as its environment. Ideally the test environment mirrors production in configuration, and the data resembles real data in volume and variety. Using real personal or confidential data in tests creates privacy and security risks, so many organizations mask or generate data. Check your organization’s rules and consult qualified specialists.

Defects and exit criteria

Not every defect must be fixed before launch. Agree a way to classify them, for instance by severity and by whether a workaround exists. Then set exit criteria before testing begins, such as:

• All planned tests have been executed.
• No unresolved critical defects.
• Any remaining defects are known, categorized and accepted by the business owner.
• Required sign-offs are in place.

Setting criteria early reduces the temptation to move the goalposts under deadline pressure. If criteria are not met, the options are to delay, to reduce scope, or to proceed with a documented risk acceptance and a plan for fixing issues soon after launch. That choice belongs to the people with the authority and accountability for the outcome.

Common weaknesses

• Leaving testing to the end of the schedule, where it gets squeezed.
• Treating UAT as a demonstration instead of a real attempt to do the work.
• Testing only the happy path.
• Skipping integrations because the other system “has not changed”.
• Having no clear decision on who signs off.
• Not recording what was tested, making it impossible to know the coverage later.

Good testing does not remove risk, but it turns unknown risks into known ones, which are easier to manage.