Types of Testing in Software Delivery

Most teams don’t fail because they skip testing. They fail because they use the wrong type of testing at the wrong stage – or treat all testing as a single end-of-cycle event. If you’ve ever shipped a release that passed QA and still broke production, this is the structural gap that caused it.

This guide maps the types of testing in software delivery to the phases where they belong, explains the logic behind each, and flags where teams consistently get it wrong. It covers both quality assurance fundamentals and how testing fits inside the software development life cycle.

The Two Master Categories: Functional vs. Non-Functional Testing

Everything in software testing falls under one of two umbrellas. Understanding the split tells you what you’re testing – and why.

Functional testing answers: does the software do what the requirements say it should do? It validates behavior. Does the login screen accept valid credentials? Does the claim adjudication engine calculate the correct co-pay? Does the HL7 FHIR API return the right patient demographic bundle?

Non-functional testing answers: how well does the software perform under real conditions? It validates quality attributes. Can the system handle 10,000 concurrent users? Does it meet HIPAA encryption standards? Does it recover within the defined RTO after a database failure?

Both categories are mandatory. Skipping non-functional testing because the features “work” is one of the most common causes of post-deployment incidents – especially in healthcare IT and financial systems where load patterns and compliance requirements are non-negotiable.

Types of Functional Testing in Software Delivery

Unit Testing

Unit testing validates a single function, method, or component in isolation. Developers write and run these tests – they’re not a QA artifact. The goal is immediate feedback on logic correctness before code reaches any shared environment.

In practice: a developer working on a claims calculation module writes unit tests for each calculation rule before committing the code. If the co-insurance formula breaks on edge inputs, the unit test catches it in seconds – not in UAT three weeks later.

Teams running SAFe Agile should treat unit test coverage as part of the Definition of Done. If it isn’t in the DoD, it will get cut under sprint pressure.

Integration Testing

Integration testing validates that separate modules or services work correctly when combined. This is where most mid-project defects surface – not in the individual components, but in how they talk to each other.

A payer-provider data exchange is a textbook integration testing scenario. The eligibility verification service may pass unit tests. The claims adjudication engine may pass unit tests. But when the eligibility response feeds into the claims workflow, field mapping mismatches, missing required elements, or timing issues in asynchronous calls cause failures that neither test suite caught alone.

HL7 FHIR API integrations require particular attention here. A FHIR R4 endpoint returning a Patient resource needs integration tests that validate the full round-trip: request construction, response parsing, error handling on 4xx/5xx codes, and correct population of downstream fields.

System Testing

System testing evaluates the complete, integrated application against the full set of specified requirements. It runs in an environment that mirrors production as closely as possible.

This is end-to-end functional coverage. In an EHR implementation, system testing covers the complete patient encounter workflow: registration, clinical documentation, order entry, results retrieval, and charge capture – all in sequence, all in one environment.

System testing is distinct from integration testing. Integration testing asks whether components connect correctly. System testing asks whether the assembled product meets the business requirements as a whole. According to BABOK v3, this maps directly to solution evaluation – verifying that the delivered solution meets stakeholder needs before formal acceptance.

User Acceptance Testing (UAT)

UAT is the formal gate before production release. Business stakeholders – not QA engineers – execute test scenarios to confirm the system meets their acceptance criteria. It’s not a QA handoff; it’s a business decision checkpoint.

The failure mode teams encounter most is treating UAT as a final QA pass. When UAT uncovers logic defects that should have been caught in system testing, you’re looking at delayed releases, renegotiated timelines, and damaged stakeholder trust.

For a deeper look at how UAT connects to requirements traceability and business analysis, the business analyst’s role in UAT clarifies who owns what. In SAFe, the Product Owner drives acceptance criteria and participates directly in UAT sign-off, which the Product Owner guide covers in detail.

Regression Testing

Regression testing confirms that new code changes haven’t broken existing functionality. It answers a deceptively simple question: did this sprint’s work break something that was working last sprint?

Without a maintained regression suite, every release is a manual re-verification of the entire application. That’s unsustainable beyond a certain system size. Automation is the only practical solution – but the automation suite must be actively maintained, not left to decay as the codebase evolves.

In regulated environments like HIPAA-covered healthcare applications, regression testing isn’t optional. Any change to a system that processes PHI triggers a validation obligation. Skipping or shortcutting regression creates audit exposure, not just technical risk.

Smoke Testing and Sanity Testing

These two terms get conflated constantly. They’re not the same.

Smoke testing runs a minimal set of high-priority tests on a new build to determine whether it’s stable enough for further testing. It’s the first gate – if smoke tests fail, the build goes back to developers without further testing effort wasted on it.

Sanity testing is narrower and targeted. After a specific fix or change, sanity testing verifies that the affected area works correctly – without running the full test suite. It’s a spot-check, not a coverage exercise.

In CI/CD pipelines, smoke tests should run automatically on every build that hits a test environment. If they’re manual, deployment frequency will outpace your testing capacity.

Types of Non-Functional Testing in Software Delivery

Performance Testing

Performance testing measures system behavior under expected and peak load conditions. It breaks into four subtypes that serve different purposes:

• Load testing – validates behavior under anticipated normal load
• Stress testing – pushes the system beyond normal capacity to find the breaking point
• Spike testing – simulates sudden, sharp increases in traffic
• Soak testing (endurance testing) – runs extended load to detect memory leaks and degradation over time

A real-world example: during open enrollment season, a health insurance portal may see 40× its daily average traffic in a two-hour window. A system that performs well in load testing but fails spike testing will go down during the exact moment it’s needed most. This isn’t hypothetical – it’s a documented pattern in payer systems that didn’t test spike scenarios before ACA enrollment periods.

Security Testing

Security testing identifies vulnerabilities that could be exploited by attackers. In regulated industries, it’s also a compliance requirement – not just a best practice.

For HIPAA-covered entities and business associates, security testing must address the Security Rule’s technical safeguard requirements: access controls, audit controls, integrity controls, and transmission security. Penetration testing and vulnerability scanning aren’t optional additions; they’re expected controls under any reasonable risk analysis.

Common test types under the security testing umbrella include vulnerability scanning, penetration testing, static application security testing (SAST), and dynamic application security testing (DAST). Each serves a different purpose. Vulnerability scanning finds known weaknesses. Penetration testing simulates an active attack to test real exploitability. SAST analyzes source code. DAST tests the running application from the outside.

Security testing should not be a one-time pre-release event. Integrate SAST into the CI/CD pipeline and schedule penetration tests at defined intervals – or after significant architectural changes.

Usability Testing

Usability testing measures how effectively real users can complete tasks using the system. It’s qualitative where most other testing types are quantitative.

It’s underused in enterprise IT – particularly in healthcare, where clinicians are often handed systems with poor workflow alignment and expected to adapt. EHR usability failures aren’t just user experience problems; they contribute to documentation errors, alert fatigue, and in some documented cases, patient safety incidents. The ONC has addressed EHR usability in its certification criteria precisely because the gap between technically compliant software and clinically usable software is measurably real.

Compatibility Testing

Compatibility testing verifies that the application works correctly across browsers, operating systems, devices, and network conditions. As organizations move to cloud-native and mobile-first delivery, the compatibility matrix expands.

Healthcare portals accessed by patients on mobile devices across varying network conditions are a straightforward example. If a patient portal renders correctly on Chrome/Windows but breaks on Safari/iOS, you’ve excluded a significant portion of your user base – and potentially created an accessibility compliance issue.

Where Testing Types Fit in the Delivery Lifecycle

Knowing the types is one thing. Knowing when to apply them is what separates teams that catch defects early from teams that find them in production.

The full Software Testing Life Cycle (STLC) provides the process framework that governs how these phases connect. If your team is running Scrum, the Scrum framework maps testing activities to sprint ceremonies – sprint planning, mid-sprint testing, and sprint review all carry specific testing responsibilities.

Edge Cases the Textbook Doesn’t Cover

Ideal test coverage assumes stable requirements, adequate environments, and enough time. Real projects offer none of those consistently.

In legacy system integrations – common in healthcare payer organizations still running COBOL-based claims systems alongside modern APIs – unit testing is often impossible for legacy components. The practical response is to build integration tests that treat the legacy system as a black box and validate outputs against known inputs. It’s not ideal. It’s what works.

In compressed release windows, regression testing gets cut first. This is the wrong call, but it happens. The mitigation is a tiered regression suite: a core smoke-plus-regression set that covers the highest-risk functional areas and runs in under 30 minutes. If that’s all you can run before release, run that.

When teams work under SAFe, PI Planning should include explicit capacity allocation for testing activities – not just story point estimates for development. Testing that isn’t planned in PI is testing that gets squeezed out during the iteration.

Karl Wiegers makes a consistent point in Software Requirements: requirements that can’t be tested are not requirements – they’re wishes. If acceptance criteria aren’t testable at the time they’re written, the QA team will be improvising test cases later. That improvisation creates inconsistent coverage and arguments about what “done” actually means.

Exploratory Testing: The Type That Doesn’t Fit a Script

Exploratory testing is simultaneous test design and execution. The tester investigates the system without a predefined script, guided by domain knowledge, risk intuition, and real-time findings.

It’s not the same as ad-hoc testing. Ad-hoc is unstructured. Exploratory testing is structured in intent – the tester has a charter (a defined area and objective) – but unscripted in execution.

Exploratory testing is most valuable after scripted testing is complete. It finds the defects that scripted tests miss: edge cases, unexpected user paths, and system behaviors that no one thought to specify. In a healthcare portal UAT, an experienced tester doing exploratory work on the prescription refill workflow found that a concurrent request from two sessions on the same account created a duplicate medication order. No scripted test covered it because no one had written a requirement for that scenario.

Don’t mistake exploratory testing for a cost-cutting workaround when you don’t have time to write test cases. It’s a distinct, skilled activity that complements – not replaces – structured testing.

What a Mature Testing Strategy Actually Looks Like

A mature testing strategy isn’t a comprehensive list of testing types applied uniformly. It’s a risk-based selection of the right types, at the right phase, with the right owners, calibrated to the system’s complexity and the consequences of failure.

In a healthcare IT context: a payer implementing a new prior authorization portal needs functional testing for the clinical rules engine, integration testing for EHR and clearinghouse connections, security testing for PHI handling under HIPAA, performance testing for open enrollment load, and UAT with both clinical staff and member services representatives. That’s not over-engineering. That’s appropriate risk coverage for a system that directly affects patient care access and regulatory compliance.

Contrast that with an internal reporting dashboard for claims operations. Unit and integration tests for the data pipeline, smoke testing before each deployment, and periodic regression on the report outputs – that’s proportionate. You don’t apply the same testing weight to every system.

If your current strategy doesn’t map testing types to delivery phases with clear ownership – start there. A one-page test strategy document that answers “what are we testing, when, who owns it, and what does pass mean” will do more for your release quality than any tool adoption.

Authoritative references:

• HHS HIPAA Security Rule – Technical Safeguards – authoritative source for security testing obligations in healthcare IT
• HL7 FHIR Specification – foundation for API integration testing in modern healthcare interoperability