How Is Software Tested Before Release?

Software is tested before release by checking whether required features work, complete business workflows behave as expected, connected systems exchange the correct data, and recent changes have not damaged existing functionality. Teams also assess performance, security, supported devices and browsers, accessibility where relevant, and whether business users can complete the tasks the software was built to support.

Testing runs throughout development rather than being left until launch. Requirements and acceptance criteria establish what correct behaviour means. Functional, integration, regression, performance, security, and user acceptance testing then check those expectations from different angles.

The release decision depends on whether critical requirements have passed, significant defects have been assessed, required business acceptance is complete, and the remaining risk is understood.

Software Teams Convert Requirements Into Testable Release Criteria

Testing starts with a clear description of what the software is expected to do. Without agreed behaviour, a test can show what the system currently does. Reliable verification requires an agreed definition of correct behaviour.

Requirements Define Expected Behaviour

Requirements describe the workflows, business rules, permissions, calculations, integrations, and error conditions the software must support. A customer approval process needs more than a statement that “managers approve requests”. The requirement establishes who can approve, when approval is required, and what happens after approval or rejection.

Acceptance Criteria Define What “Correct” Means

Acceptance criteria turn requirements into observable outcomes that can pass or fail during testing.

For a role-based approval workflow, one criterion might require an authorised manager to approve a request while preventing users without that permission from completing the same action.

Risk Determines Testing Depth

Testing depth follows the consequence of failure. Payment processing, access permissions, financial calculations, customer data, and critical integrations normally require more scrutiny than a low-risk visual change.

Some release risks originate much earlier than testing. If a project still contains uncertainty around architecture, integrations, data, technical constraints, or whether the proposed solution can work as intended, a software technical feasibility assessment can help investigate those questions before significant development begins.

Functional Tests Verify Features and Business Workflows Before Release

Functional testing checks whether the software performs the actions and business rules defined in the requirements. Functional testing covers individual features and the complete workflows that connect them, because several correct components can still fail when they operate together.

Functional tests cover expected inputs, invalid inputs, permissions, calculations, validation rules, error states, and important edge cases.

Illustrative scenario: A CRM allows a salesperson to create a lead successfully. The workflow still fails if the system does not assign the correct owner, update the status, trigger the required notification, or record the change in the audit history.

Testing a button, form, or screen in isolation proves only that the individual feature behaves correctly. The complete operational journey also needs to reach its intended business outcome.

Integration Tests Verify Systems, APIs, and Data Flows Work Together

A screen can appear to work correctly while the process behind it fails. Integration testing checks whether connected systems exchange the right information and handle expected responses or failures correctly.

API and System Integration Tests Validate Exchanges

Teams test requests, responses, authentication, error handling, and important retry behaviour across APIs and connected services. This matters when the software depends on a CRM, ERP, payment service, identity provider, email platform, or another third-party system.

Illustrative scenario: A customer completes an order and receives a successful confirmation, but the order never reaches the ERP. The interface worked, yet the downstream business process failed.

Data Validation Confirms Information Moves Correctly

Connection failures are usually easy to spot. Data failures are less obvious because two systems may communicate successfully while storing the wrong status, mapping a field incorrectly, or creating duplicate records. Testing therefore checks formats, field mappings, missing records, duplicates, and transaction states when the integration creates or updates business data across systems.

Regression Tests Protect Existing Behaviour After Software Changes

A code change can solve one problem and create another elsewhere. Regression testing checks whether existing behaviour still works after new features, bug fixes, refactoring, dependency updates, or integration changes.

Retesting Confirms the Specific Fix

Retesting returns to the failed condition and checks whether the correction now produces the expected result.

Regression Testing Checks for Unintended Effects

Regression testing looks beyond the original defect and checks whether the change affected related workflows, calculations, permissions, integrations, or other established behaviour.

Automation Supports Repeatable Checks

Automation works well for stable checks such as critical calculations, API behaviour, and established workflows. It improves feedback speed. Release confidence depends on whether those checks cover meaningful risks and where human judgement is still required. Human judgement remains necessary where behaviour, usability, security, or business acceptance cannot be reduced to a reliable automated check.

Performance Tests Check Software Under Expected Demand

Software can behave correctly in a quiet test environment and still struggle when real users, transactions, or background processes arrive at the same time. Performance testing checks whether the system responds acceptably under expected demand.

Performance testing examines response times, concurrent users, transaction volume, database behaviour, background jobs, resource consumption, and peak periods. Load testing checks expected operating demand. Stress testing explores behaviour beyond normal limits when traffic spikes, batch processing, transaction bursts, or resource exhaustion could affect production.

Illustrative scenario: An employee portal works normally when a small internal team reviews it. After a company-wide announcement, hundreds of staff sign in within a short period and key pages begin responding slowly.

Performance problems often appear when several ordinary actions happen at the same time. A page may respond quickly in isolation, then slow when database queries, background jobs, integrations, and concurrent user activity compete for the same resources.

A useful performance target describes a real operating condition. An internal CRM used by a controlled group and a booking platform expecting a scheduled traffic surge need very different test assumptions.

Security Tests Identify Vulnerabilities and Access-Control Failures Before Release

Security testing checks the failure paths that could expose accounts, data, privileged actions, or system components. The depth of testing increases when the software handles payments, personal information, sensitive business data, administrative roles, or other functions where misuse carries a higher consequence.

Authentication and authorisation deserve separate attention even though users experience them as part of the same access journey. Login, session handling, and password recovery establish who the user is. Role and permission checks determine what that authenticated user can view, change, approve, or administer. A valid account with excessive permissions is still a security failure.

Vulnerability and Dependency Checks Expose Technical Weaknesses

Higher-risk applications usually require several forms of technical security testing. Source-code analysis, dependency checks, configuration review, dynamic testing, and deeper manual assessment examine different failure paths. NCSC guidance supports testing defined functional and security requirements throughout the software lifecycle.

Sensitive information also needs attention outside the visible application flow. Credentials, personal information, secrets, logs, and test data can create exposure if storage, access, or handling controls fail. ICO guidance connects UK GDPR security obligations with regular testing and evaluation of appropriate technical and organisational measures.

Security findings then feed into the release decision according to severity, exploitability, affected data, and business impact. A weakness that exposes a privileged action or sensitive information may justify holding the release until the issue has been corrected and retested.

Compatibility and Accessibility Tests Verify Software Works for Intended Users

Compatibility testing checks whether software works in the environments its intended users rely on. Accessibility testing examines whether people can complete important tasks using relevant interaction methods and assistive technologies.

Device and Browser Compatibility Tests Cover Supported Environments

Testing follows the supported user base rather than attempting to cover every possible device or browser. Customer-facing applications usually require broader desktop and mobile coverage than controlled internal systems.

Teams focus particularly on workflows where layout, browser behaviour, permissions, or device capabilities affect task completion.

Accessibility Tests Check Whether Intended Users Can Operate the Software

Accessibility testing may include keyboard navigation, visible focus, form labels, colour contrast, error handling, and screen-reader behaviour.

For UK public-sector websites and mobile apps within scope of the accessibility regulations, current GOV.UK guidance uses WCAG 2.2 level AA as the technical standard. For private-sector products, the required accessibility scope is shaped by the service type, intended users, contractual commitments, and applicable legal duties.

User Acceptance Testing Confirms Software Supports Business Requirements

User acceptance testing checks whether the finished software supports the business processes it was commissioned to handle. Technical QA confirms specified behaviour. Business stakeholders determine whether that behaviour works in realistic operational use.

UAT uses representative users, realistic workflows, agreed acceptance criteria, and a suitable staging or pre-production environment.

An invoice workflow may pass technical testing because calculations, status changes, and notifications work correctly. UAT is where technically correct workflows often meet operational exceptions that were not obvious from the specification. Approval handoffs, missing information, unusual user roles, and real working practices can expose gaps that functional testing did not reveal.

The people performing UAT should understand the actual process. The right UAT participants are the people who own, operate, approve, or administer the workflow being accepted. That may include department leads, operational staff, product owners, or administrators.

The development team can prepare the environment, resolve defects, and clarify expected behaviour. The client remains responsible for deciding whether the software meets its business requirements well enough to approve release.

Defect Triage and Retesting Turn Test Findings Into Release Decisions

Testing findings need more than a status of “open” or “fixed”. The team should record the defect, confirm how it can be reproduced, assess its severity and business impact, assign ownership, correct it where required, and verify the result.

Business priority can outweigh visible severity. A visible alignment issue may have little release impact. A rare permissions defect may be serious enough to block production because it allows the wrong user to access or approve something.

Some low-impact defects may remain open if responsible stakeholders understand and accept the residual risk. Higher-risk findings require correction before launch when the remaining exposure exceeds the agreed release threshold.

Quality depends on the significance of known findings, their effect on users and operations, and the residual risk accepted for release.

Release Gates Combine Test Evidence Into a Go-or-No-Go Decision

A release gate brings together the results that matter for production approval. The decision considers whether critical tests were completed, important acceptance criteria passed, serious defects remain open, and any security or performance findings create unacceptable exposure.

The useful question at this point is no longer how much testing occurred. The team needs to know what failed, what remains unresolved, which requirements are affected, and whether the remaining risk is understood well enough to proceed.

Deployment readiness sits alongside the test results. Configuration changes, database updates, deployment steps, rollback preparation, and monitoring need to be ready before the production transition.

Where client approval forms part of the release gate, the recorded UAT outcome and accepted residual risks contribute directly to the go-or-no-go decision.

AI-Enabled Software Requires Additional Evaluation Before Release

AI-enabled software needs extra evaluation because the same input does not always produce one fixed result. The team needs to test whether the AI feature performs its intended task consistently enough for real use.

AI evaluation covers task success, output accuracy, unsupported responses, retrieval quality, prompt behaviour, model changes, latency, cost, privacy, fallback behaviour, and human review when the feature influences decisions, handles sensitive information, or produces outputs users may act on.

Traditional software often allows:

Input → expected result → pass or fail.

AI-enabled behaviour may require:

Evaluation input → quality criteria → tolerance → automated or human assessment.

A support assistant may return a technically valid response that is incomplete, unsupported by source material, or unsuitable for the user’s request. That behaviour needs evaluation against defined acceptance criteria.

Teams should also rerun evaluation sets when prompts, retrieval logic, model versions, or supporting data change. Production readiness requires evaluation of the AI behaviour itself, including output quality, fallback behaviour, and defined acceptance criteria.

UK Requirements Shape Testing and Assurance Obligations for Some Software Projects

UK testing obligations change when the software processes regulated data, serves users covered by accessibility duties, operates in a regulated sector, or carries contractual assurance requirements.

Data Protection Requirements Influence Testing Where Personal Data Is Processed

If software processes personal data, UK GDPR security requirements become relevant. ICO guidance expects organisations to regularly test, assess, and evaluate the effectiveness of appropriate technical and organisational measures, with scope shaped by the processing risk.

Software Security Guidance Informs Risk-Based Testing

The UK Government’s Software Security Code of Practice is voluntary and expects software vendors to have a clear process for testing software and updates before distribution. NCSC guidance adds expectations around defined requirements, documented results, and identified vulnerabilities.

Accessibility Requirements Apply According to Service Context

For public-sector websites and mobile applications within scope, current GOV.UK guidance uses WCAG 2.2 level AA. Applicability depends on the service context.

Sector Requirements Add Project-Specific Assurance Checks

Financial services, healthcare, public-sector systems, and critical infrastructure can require extra assurance around areas such as access control, auditability, resilience, data handling, or operational continuity. The regulator, contract, and system role determine which checks and records are required.

UK projects therefore need testing records, assessments, and assurance outputs that reflect their actual legal, technical, contractual, and operational obligations.

Clients Should Ask Software Vendors for Evidence Before Approving Release

A statement such as “QA is included” gives a client little information about release readiness. Clients need to ask what was tested, what remains unresolved, and which evidence supports the recommendation to move into production.

A vendor discussion becomes much more useful once it moves beyond a general “QA passed” status and into failed tests, unresolved risks, release blockers, and the material available for review. Clients also need to know who can explain those findings directly. These details reveal more about testing discipline than a raw test count.

These questions also help when deciding which software development company to choose because they show how a provider handles quality and accountability in practice.

Square Root Solutions UK Tests Software Against Business and Release Requirements

Square Root Solutions UK provides custom software development services for UK organisations building CRM systems, web applications, mobile applications, and other business software. Testing for these products needs to reflect the workflows, integrations, user roles, data, and release conditions agreed for the individual project.

Clients need to see whether critical requirements were checked, defects were assessed, important integrations behaved correctly, business users completed acceptance testing where required, and remaining release risks were understood.

Testing scope changes with the product. A CRM with role-based approvals presents different risks from a public web application, an integrated business platform, or software containing AI functionality.

If you are planning a new application or reviewing an existing system, discuss expected release criteria early enough for them to influence development and testing.

Discuss Your Software Project

Frequently Asked Questions

Q.

When should software testing start?

Testing starts as soon as requirements and acceptance criteria are clear enough to verify. Teams can review rules and test conditions before implementation, then continue relevant testing throughout development.

Q.

What is the difference between QA and UAT?

QA checks whether software behaves according to defined requirements. UAT checks whether representative business users can complete the workflows required for real operations and whether the client is prepared to accept the software.

Q.

Who should perform user acceptance testing?

People who understand the real business process perform or lead UAT. This may include product owners, department managers, operational staff, or administrators. The client retains responsibility for business acceptance.

Q.

What is regression testing before release?

Regression testing checks whether a new change has unintentionally affected existing behaviour. It is commonly used after feature changes, fixes, dependency updates, or configuration changes.

Q.

Does every software release need security testing?

Security-testing depth follows the risks introduced by the software and the change being released. Applications handling authentication, payments, personal information, sensitive data, or privileged roles normally require deeper security scrutiny than low-risk changes.

Q.

How are integrations tested before launch?

Teams verify whether connected systems send, receive, map, and process information correctly. Relevant checks may include API authentication, responses, error handling, mappings, missing records, duplicates, and transaction states.

Q.

What happens if bugs remain before release?

Not every known defect has to be closed. Teams assess unresolved issues by business impact, affected users, security implications, and release criteria. Low-impact defects may be accepted as documented residual risk.

Q.

What evidence should a software company provide before launch?

Useful material includes critical test results, an open defect register, UAT approval, relevant security and performance findings, release notes, and deployment or rollback readiness.