Software testing before launch: a practical checklist

14 October 2026 | Neuronidis Manos | Blog

Software testing before launch should prove more than the fact that an application opens and its screens look finished. Software is ready when critical workflows work, access rules are correct, data is reliable, performance is acceptable, and representative users can complete their tasks. Those results need agreed evidence, not a general feeling that the product is ready.

Before launch, define what “ready” means

Launch readiness is a shared business and technical decision. The development team may confirm that the code has passed its tests, while the business still has concerns about approvals, reports, customer records, or daily operating procedures. Both views matter.

A useful readiness definition covers five areas:

• Core workflows complete successfully from start to finish.
• Each role can access exactly what it needs, and nothing more.
• Data remains accurate through entry, editing, import, export, and integration.
• The application performs acceptably under realistic usage.
• Representative users can complete agreed tasks and approve the result.

This approach turns release preparation into a review of evidence. A passed test, a recorded user acceptance result, or a confirmed deployment procedure is more useful than “it seems fine”.

Turn business expectations into acceptance criteria

Acceptance criteria translate business expectations into conditions that someone can verify. They reduce misunderstandings because the business, product owner, designer, and development team work from the same description of a successful outcome.

Good criteria identify the user or role, the action, the expected result, relevant exceptions, and any measurable condition. They should also have an owner who can confirm the result and provide formal sign-off. A criterion such as “orders should work” leaves too much unsaid. It does not explain which order types are included, who may approve them, what happens when stock is unavailable, or what the customer receives.

A more useful version might be:

When a sales user submits an order with valid customer, product, quantity, and delivery details, the system must create one order record, calculate the agreed totals, show a confirmation number, and make the order visible to the sales manager for approval. If stock is unavailable, the system must prevent submission and display an actionable message.

That criterion can be tested with valid data, invalid data, different roles, and an exception. It also creates a natural discussion about ownership. The sales manager can confirm the approval workflow, while the technical team can provide test evidence and defect records.

Write criteria before the final development stage, not during the final hours before release. Link each one to a workflow or requirement, assign an owner, define its evidence, and record whether it is passed, failed, blocked, or accepted with a known risk. A practical guide to speaking the developer language can also help business stakeholders ask more precise questions.

Which tests should be completed before release?

Before release, testing should cover the application’s main workflows, business rules, access model, integrations, and failure cases. Testing only the screens is not enough. A clean interface can still create incorrect records or permit an unauthorised action.

Functional testing

Start with the journeys people use most often. For a business system, that may include creating a record, submitting it for review, approving it, updating it, producing a report, and closing the process. For an e-commerce application, it may include product search, cart changes, checkout, payment status, order confirmation, and fulfilment updates.

Check the details that often cause expensive surprises:

• Required fields, valid formats, field limits, and helpful validation messages.
• Search, filters, sorting, pagination, reports, and exports.
• Emails, push notifications, webhooks, and other integrations.
• Duplicate submissions, repeated clicks, and interrupted transactions.
• Recovery after a timeout, failed upload, lost connection, or expired session.
• Correct status changes as an item moves through the business process.

Roles and permissions testing

Roles and permissions testing must include positive and negative cases. For every role, record what the user can view, create, edit, approve, export, and delete. Then test what should happen when that user attempts a restricted action through the interface and, where relevant, through a direct request or deep link.

Test combinations that reflect real work. A staff member may edit a draft but not an approved record. A manager may approve an item but not change its financial details. An administrator may manage users but still need a clear audit trail for sensitive changes. These are business rules, not just buttons to hide.

Also check access after a role change, account deactivation, password reset, session expiry, and invitation to a new organisation or department. Permissions that work only in the usual path are not enough.

Check the application where people will actually use it

Testing in one desktop browser on one development machine gives an incomplete picture. Responsive web applications and mobile apps need checks on the devices, operating systems, browsers, and connection conditions that users are likely to have.

For mobile and device testing, review:

• Common screen sizes, responsive breakpoints, and text readability.
• Supported browsers and operating system versions.
• Touch targets, scrolling, keyboard behaviour, gestures, and orientation changes.
• Camera, location, notification, storage, or other device permissions.
• Movement between Wi-Fi and mobile data, weak connectivity, and reconnection.
• Backgrounding the app, receiving a call, locking the screen, and resuming an interrupted session.

The test environment should reflect the actual working context. A field worker using a smartphone has different constraints from an office employee using a multi-monitor setup. Saikō’s cross-platform mobile and desktop application development resource reflects this multi-device requirement, but the testing principle applies to any application.

Data checks deserve their own pass. Verify imports, calculations, duplicate records, date and currency formats, time zones, database updates, backups, and synchronisation with connected systems. Test empty values, unusual but valid values, maximum lengths, and records containing privacy-sensitive information. Confirm that failed integrations do not silently create partial or misleading data. Good database design for businesses makes these checks easier, but it does not remove the need to perform them.

Performance testing and user acceptance testing

Performance testing checks whether the application remains usable under realistic conditions. User acceptance testing checks whether representative business users can complete their real tasks and consider the outcomes correct. They answer different questions and should not be treated as interchangeable.

Performance checks may include:

• Page and API response times for common and complex actions.
• Concurrent users performing typical tasks at the same time.
• Background jobs such as synchronisation, notifications, and scheduled calculations.
• Large file uploads, data imports, searches, dashboards, and reports.
• Behaviour when a service is slow, unavailable, or returns an error.

Use realistic records and volumes where possible. A report that works quickly with ten rows may behave very differently with several years of business data. The result should include observed conditions, not only a pass or fail label.

User acceptance testing, or UAT, works best when it has a short, controlled process:

1. Choose representative users from the teams that will rely on the application.
2. Give them agreed scenarios, test accounts, suitable data, and acceptance criteria.
3. Ask them to complete tasks without step-by-step coaching from the development team.
4. Record each defect with the scenario, expected result, actual result, evidence, and priority.
5. Retest fixes in the same environment and confirm that related workflows still work.
6. Separate blockers from minor improvements and document any accepted risks.
7. Obtain formal approval from the designated business owner.

UAT is not a popularity poll. A user may dislike a colour choice, but that is different from being unable to approve an invoice or understand an error message. Usability still matters, especially when confusion can cause incorrect work. A useful perspective on this is covered in UX design beyond attractive colours.

A practical pre-launch checklist and go/no-go review

Use the following pre-launch software testing checklist as a starting point. Adapt it for custom web applications, mobile apps, or internal business systems.

• Confirm that core workflows, validation, error handling, search, reports, notifications, integrations, and recovery paths pass.
• Verify roles, permissions, approval rules, account states, audit records, and restricted actions.
• Test supported browsers, operating systems, screen sizes, touch interactions, orientation, permissions, and connectivity changes.
• Check imports, calculations, duplicates, formats, time zones, database updates, backups, exports, and synchronisation.
• Confirm that common actions, concurrent use, reports, uploads, background jobs, and failure behaviour meet agreed expectations.
• Review sensitive data exposure, session handling, access boundaries, logging, and retention requirements. Backend privacy controls matter, as explained in this guide to GDPR compliance beyond the cookie banner.
• Confirm that representative users can complete key tasks, understand messages, and recover from mistakes.
• Document and test release steps, configuration, migrations, monitoring, backups, and environment settings.
• Prepare support contacts, operating instructions, incident ownership, rollback steps, and post-launch monitoring.

The go/no-go decision should identify unresolved defects, failed acceptance criteria, known risks, owners, and deadlines. Do not hide a blocker inside a long list of minor issues. A release is reasonable when agreed critical criteria have passed, remaining risks have an accountable owner, and the business has documented its decision.

Make launch approval a shared decision

Testing is not a final technical ceremony. It is a shared review of whether software can support real work safely and consistently. Create the acceptance checklist before final development, assign an owner to every criterion, and require evidence for each sign-off. A structured testing and custom application delivery process can make that review clearer for everyone involved.