What Is QA? Quality Assurance in Software Development

Quality assurance means different things to different people on the same team – and that ambiguity costs projects time, money, and credibility. This article defines what QA actually is in software development, separates it from related terms that get used interchangeably, and explains how it functions across the full delivery lifecycle in 2026 – including where it has changed, what it still gets wrong, and how it applies in high-stakes environments like healthcare IT and financial systems.

What Is QA in Software Development

Quality assurance (QA) is a systematic, process-oriented discipline that ensures software development activities produce products meeting defined quality standards. The International Software Testing Qualifications Board (ISTQB) defines it precisely: “activities focused on providing confidence that quality requirements will be fulfilled.” That definition is important because it frames QA as process assurance – not defect finding. QA builds confidence upstream. It doesn’t just verify outcomes at the end.

In practice, QA encompasses everything from reviewing requirements for testability, establishing test standards, defining processes for defect management, and validating that release criteria are met before deployment. A QA function that only runs test cases at the end of a sprint is not doing QA. It is doing quality control – which is related but structurally different.

QA spans the entire Software Development Life Cycle. It touches requirements analysis, design reviews, code standards, test planning, test execution, defect management, and post-release monitoring. Its goal is prevention, not just detection. When QA works well, fewer defects reach testing at all – because the process upstream made them less likely to occur.

The Origin of the Term and Why It Still Matters

Quality assurance as a formal discipline predates software. It emerged in manufacturing, particularly in post-WWII Japan, under the influence of W. Edwards Deming and Joseph Juran. Their work – later codified as Total Quality Management (TQM) – established the principle that quality is built into a process, not inspected into a product after the fact. The same principle migrated into software development as the industry scaled in the 1970s and 1980s.

This history matters because it explains why QA in software is more than a testing department. The manufacturing analogy holds: you don’t quality-check a car only after it rolls off the assembly line. You engineer quality into every step of production. Software QA follows the same logic. Requirements that are ambiguous produce code that is wrong by design. Code reviewed by no one produces defects that could have been caught in 10 minutes. A build pipeline with no automated tests ships regressions that a developer introduced at 4 PM on a Friday. QA’s job is to make all of those failure modes less likely through process design, not just detect them through test execution.

QA vs. QC vs. Testing: Three Terms, Three Roles

These three terms get collapsed into each other constantly on job postings, org charts, and meeting agendas. They are not synonyms. Understanding the distinction changes how you staff, how you structure work, and what you measure.

The hierarchy, per ISTQB, runs: QA contains QC; QC contains testing. When a QA team only does testing, the organization is operating two levels below the full scope of what quality assurance provides. This is common. It’s also the reason defects keep reappearing sprint after sprint with no root cause addressed – the team is finding symptoms, not fixing the underlying process that produces them.

The practical edge case: on small teams and early-stage products, distinguishing QA from QC from testing is academic. A three-person startup doesn’t staff a dedicated QA process architect. A single QA engineer does all three. What matters is that the team understands which activity they’re doing at any given moment – because the question “how do we prevent this from happening again?” requires a different answer than “how do we find out if this works?”

What QA Does Across the Software Development Life Cycle

QA doesn’t start when development finishes. That’s a legacy model from Waterfall programs in the 1990s. In 2026, with CI/CD pipelines deploying multiple times per day and Agile sprints delivering working software every two weeks, a QA function that starts at the end of development is structurally too late. By the time they find a problem in integration testing, the developer who introduced it has moved two features forward and the sprint velocity has already been committed.

Here is what QA involvement looks like across the SDLC when it is functioning correctly.

Requirements Phase: QA’s Most Underused Contribution

The most cost-effective QA activity is requirements review. A defect found in requirements costs a fraction of the same defect found in UAT. The IBM Systems Sciences Institute famously quantified this in their cost-of-quality research, later popularized by Barry Boehm: defects found in the design phase cost roughly 6x more to fix than those found in requirements. Defects found in production can cost 100x more.

A QA analyst who reviews a user story before development starts and asks “what should happen when this field is null?” or “what’s the valid range for this numeric input?” is preventing defects, not just planning to find them. Per Karl Wiegers in Software Requirements, 3rd Edition, testability is a core requirement quality attribute. A requirement that can’t be tested unambiguously isn’t complete. QA’s review closes that gap before the developer builds to a wrong specification.

BABOK v3’s Requirements Life Cycle Management knowledge area covers this directly. Requirements must be maintained, traceable, and validated. QA participation in requirements review is a validation activity – confirming that the stated requirement can actually be verified before it enters development.

Shift-Left Testing: Moving QA Earlier in the Pipeline

The “shift-left” concept formalizes what QA practitioners have known for decades: finding problems earlier is cheaper and faster. In a CI/CD context, shift-left testing means automated tests run on every code commit, integration tests fire on every pull request, and security scans execute in the pipeline before code reaches staging. A defect caught in a pre-merge check never enters the main branch, never corrupts the test environment, and never blocks a downstream team.

Shift-left also applies to manual testing activities. When QA analysts attend sprint planning and refinement sessions, they catch requirement gaps and missing acceptance criteria before they become sprint-blocking questions on Day 9 of a 10-day sprint. When QA reviews API contracts as they are designed rather than after the integration is built, they catch breaking changes before they cascade.

The practical constraint: shift-left requires QA to have the capacity and organizational authority to participate early. Teams that treat QA as a downstream function – hand the build over when development is “done” – can’t shift left without a structural change in how the team operates. This is a resourcing and culture problem as much as a technical one.

Types of QA Testing: What the QA Team Actually Executes

QA covers a broad range of testing types, each addressing a different quality dimension. No single type is sufficient on its own. A project that runs thorough functional testing but skips performance testing ships software that works correctly and falls over under load. A project that automates regression but skips exploratory testing ships software where automated tests pass and users immediately find issues no script thought to check.

The question of which testing types to run isn’t answered by a best-practice list. It is answered by the risk profile of the system. A low-traffic internal tool needs robust functional testing and light performance testing. A financial transaction platform needs performance, security, functional, regression, and disaster recovery testing. A HIPAA-covered EHR needs all of the above plus compliance audit logging validation. Risk drives test scope, not convention.

QA Roles: Who Does What on a Modern IT Team

QA isn’t a single role. The title “QA” covers a wide spectrum of specializations. On a mature team, these roles coexist. On a small team, one person handles several of them. Understanding the distinction prevents the common mistake of hiring a manual tester when you need an automation engineer, or vice versa.

The industry shift in 2026 is toward the SDET model – QA engineers who can code. CI/CD environments that deploy multiple times daily can’t sustain manual-only testing. The automation layer has to keep pace with the deployment frequency. An SDET who builds a Playwright suite that runs 600 regression tests in 12 minutes against every pull request provides the feedback loop that makes fast deployment viable. A manual-only QA function in the same environment becomes the bottleneck.

That said, automation doesn’t replace judgment. Automated tests verify what they’re programmed to verify. Exploratory testing surfaces what nobody thought to script. The best QA teams in 2026 use automation for coverage and repeatability, and human expertise for discovery, risk assessment, and UAT facilitation.

The QA Process: From Test Planning to Sign-Off

QA follows a structured process within the Software Testing Life Cycle (STLC). The STLC runs in parallel with the SDLC – it is not a phase that begins after development completes. The six phases of the STLC, per standard QA practice, are: Requirement Analysis, Test Planning, Test Case Design, Environment Setup, Test Execution, and Test Closure. Each phase produces documented outputs that serve as audit artifacts on regulated programs.

Test Planning

The Test Plan is the QA team’s contract with the program. It defines: the scope of testing (what is in and out), the testing approach for each module, the types of testing to be executed, entry and exit criteria for each testing phase, resource requirements and responsibilities, the defect management process, and risk areas that warrant additional attention. A Test Plan written without QA understanding the system architecture is a document, not a plan.

Exit criteria deserve particular attention. “Testing complete” is not an exit criterion. “Zero open Critical or High severity defects; defect density below 0.5 per function point; all acceptance criteria verified and signed off by BA and PO” – that’s an exit criterion. Vague exit criteria produce pressure-driven go-live decisions made on gut feel rather than evidence. In a regulated environment, this creates audit exposure.

Test Case Design

Test case design is where QA transforms requirements into executable verification steps. Each test case maps to one or more acceptance criteria. Each acceptance criterion maps to one or more requirements. This traceability – requirement to test case to test result – is what makes a test suite an audit artifact, not just a list of scenarios.

Effective test case design uses established techniques. Equivalence partitioning divides inputs into groups with the same expected behavior, then tests one representative value per group. Boundary value analysis tests at the edges of valid ranges – the values where systems most often fail. Decision table testing maps combinations of conditions to expected outputs, which is essential for complex business rules. Negative testing validates that the system handles invalid inputs correctly, not just that valid inputs work.

A test case that only tests the happy path is incomplete. Users don’t just submit valid data. They submit empty forms, paste foreign characters into fields, leave required fields blank, and click Submit twice. If the system doesn’t handle these gracefully, it will fail in UAT or production.

Test Execution and Defect Management

Test execution follows the test plan against the test cases in the agreed environment. Results are logged: pass, fail, or blocked. Failed tests produce defect reports. A well-written defect report contains: unique ID, summary, steps to reproduce, actual result, expected result, severity, priority, environment details, screenshots or logs, and the linked test case. A developer assigned a defect without steps to reproduce will either guess or ask for clarification – both options cost time.

Defect severity and priority are independent dimensions. Severity is the technical impact on the system: Critical, High, Medium, Low. Priority is the business urgency to fix: how soon does this need to be resolved relative to everything else in the backlog? A cosmetic label error on the login screen of a publicly visible compliance portal is low severity but potentially high priority because stakeholders and auditors see it immediately. Collapsing these into one field loses critical information for triage decisions.

After fixes are deployed to the test environment, QA re-executes the failed test case (retesting) and runs a targeted regression sweep to confirm no related functionality broke. This cycle – test, defect, fix, retest, regression – repeats until exit criteria are met.

Test Closure and the Go/No-Go Decision

Test closure produces the Test Completion Report (sometimes called Test Summary Report). This document records: total test cases executed vs. planned, pass/fail counts by module, open defects by severity and priority, known risks going into production, and the QA team’s release recommendation. In a regulated environment, this document is a compliance artifact. HIPAA’s Security Rule requires documented evidence of due diligence in testing systems that process protected health information. The Test Completion Report is that evidence.

The go/no-go decision belongs to the Program Manager, Product Owner, and Business Sponsor – not to QA. QA provides the evidence and the recommendation. The decision is a business call that weighs quality risk against schedule pressure. QA’s job is to make that evidence clear and honest, including documenting what was not tested and why. A QA team that withholds or softens risk information to avoid conflict is not functioning as a quality function.

QA in Agile: How the Process Changes in Scrum and SAFe

Agile changed the timing of QA activities but not their purpose. In a Scrum sprint, QA doesn’t wait until development is complete to start testing. Stories are tested within the sprint they are built. The “Definition of Done” for a user story typically includes: unit tests written, code reviewed, functional testing passed, and acceptance criteria verified by QA. A story is not done until QA signs off.

This creates a different capacity challenge. In Waterfall, QA waits for a complete build and then tests it sequentially. In Agile, QA is testing incrementally alongside development – which means they need to be ready to test when development hands off, not three days after. Teams that don’t staff QA proportionally to developers end up with a testing bottleneck. Stories pile up “In Review” waiting for QA capacity. The sprint board looks green on development and red on testing, and velocity is misrepresented as a development problem when it’s a staffing problem.

In SAFe at the Program Increment level, QA contributes to PI Planning by identifying testing dependencies between teams, flagging shared environment constraints, and estimating test capacity against the PI objectives. The Inspect and Adapt workshop at the end of each PI is a direct application of the Six Sigma DMAIC “Improve” and “Control” steps: measure quality outcomes, analyze root causes of defects, and implement process changes for the next PI.

The Agile Manifesto’s principle of “working software over comprehensive documentation” doesn’t license skipping test documentation. It means that documentation should be proportional and useful, not ceremonial. A test case that exists only in a spreadsheet that nobody reads fails both criteria. A test case in Jira that links to the story, the acceptance criterion, the test result, and the defect that failed it serves the project – even a sentence of it is worth more than a 40-page Test Plan that was written once and never updated.

QA in Healthcare IT: A Real-World Scenario With Regulatory Stakes

A regional health system is implementing a new EHR platform and integrating it with an existing laboratory information system and a payer for claims adjudication. The clinical lab integration uses HL7 FHIR R4 – specifically the DiagnosticReport and Observation resource types – to transmit lab results from the LIS to the EHR. The claims integration uses X12 837P and 835 EDI transactions.

This is not a hypothetical. This is the standard architecture for a mid-size health system integration program in 2026. The QA responsibilities in this environment are substantially different from QA on a commercial SaaS product.

First, HIPAA compliance is not optional background context. The HIPAA Security Rule requires documented risk analysis and documented evidence that security controls are working. QA must produce test results that verify: role-based access controls prevent unauthorized access to PHI, audit logging captures every PHI access event, data transmission between systems is encrypted at rest and in transit, and break-glass access procedures work correctly. These aren’t functional test cases. They are compliance evidence that an auditor may review.

Second, HL7 FHIR message validation requires domain knowledge that general QA doesn’t provide. A QA analyst testing HL7 FHIR integration needs to understand FHIR resource structures, validate that observation components in the OBX segment map correctly to the Observation.value field in FHIR R4, and confirm that ICD-10 diagnosis codes transmit without truncation through any XML transformation layers. A test case that only checks “does the result display in the patient chart?” misses the structural validation that the data integrity requires.

Third, the testing environments are constrained. Patient data can’t be used in testing without HIPAA-compliant de-identification. This means QA needs synthetic test data – realistic but non-identifiable patient records – to test clinical workflows. Building and maintaining synthetic test data sets is a QA infrastructure investment that many programs underestimate until data availability blocks testing progress.

In this scenario, the QA Test Plan includes: functional test cases for all clinical workflows documented in the requirements, HL7 FHIR message structure validation for each interface, security test cases for all HIPAA-covered access control requirements, performance test scenarios for peak clinical load (morning rounds, shift changes), regression test suite covering all interfaces after any configuration change, and UAT coordination with clinical department leads. The Test Completion Report for this program is reviewed by the Compliance Officer before go-live approval.

The edge case that surfaces on almost every healthcare IT program: the interface engine vendor’s test environment doesn’t support the same message volume as production. Performance testing for the FHIR interface has to be done against a best-effort simulation. The QA team documents this limitation in the Test Plan, tests within the available constraints, and clearly notes in the Test Completion Report that production message volume was not validated. This honesty protects the program when performance issues emerge post-go-live and prevents QA from being blamed for not testing something they explicitly documented as out of scope.

QA in Financial IT: Where Testing Meets Regulatory Risk

A mid-size financial services firm is migrating a loan origination system from an on-premise platform to a cloud-native architecture on AWS. The system processes sensitive consumer financial data covered by the Gramm-Leach-Bliley Act. The migration team is running a hybrid Agile-Waterfall delivery model: Agile sprints for development, with Waterfall-style formal testing phases (SIT, UAT, Parallel Run) before cutover.

QA on this program has three distinct responsibilities that don’t exist on a standard product development project. First, data migration validation: every loan record that migrates from the old system to the new one must be verified for completeness and accuracy. QA runs SQL-based reconciliation queries to compare source and target record counts, validates field-level data mapping for key financial fields (loan amount, interest rate, maturity date), and flags any records that failed transformation rules. A loan record with a corrupted interest rate field isn’t just a data quality problem – it’s a consumer harm and regulatory risk.

Second, parallel run testing: for a defined period before cutover, both the old and new systems process the same transactions simultaneously. QA compares outputs daily. Any discrepancy – a different fee calculation, a different payment schedule – is a defect that must be resolved before cutover or formally accepted by the business with documented risk approval. This is a labor-intensive but essential quality gate for systems where data correctness is legally required.

Third, regression testing for the AWS infrastructure layer: the new cloud environment introduces latency variability, auto-scaling behavior, and disaster recovery procedures that the old on-premise system didn’t have. QA must validate that the application behaves correctly when AWS auto-scaling triggers under load, that failover to the secondary region works within the RTO defined in the business continuity plan, and that encryption keys managed through AWS KMS apply correctly to stored loan data. These are not application defects. They are infrastructure-application integration risks that QA must verify before go-live.

QA Automation in 2026: AI, CI/CD, and the Changing Toolset

Test automation has shifted significantly in 2026. The previous generation of automation – brittle Selenium scripts that broke every time a developer renamed a CSS class – has largely given way to more resilient tooling. Playwright and Cypress dominate UI automation for web applications. REST-assured and Postman/Newman handle API automation. Appium remains the standard for mobile. Jenkins, GitHub Actions, and GitLab CI are the pipeline orchestrators where these suites execute.

The material change in 2026 is AI-assisted test generation and self-healing automation. Tools with self-healing capabilities use element locator strategies that adapt when UI elements change – a button that shifts from id=”submit-btn-456″ to id=”submit-btn-789″ no longer breaks the test. AI-powered platforms can analyze code changes, identify which test cases are most likely to catch resulting failures, and prioritize test execution to surface risk faster. This doesn’t replace the human judgment required to design meaningful test cases. It reduces the maintenance overhead that made large automation suites expensive to sustain.

A Reuters Technology report from 2025 found that 78% of surveyed enterprises use AI-driven tools for software testing, with 62% reporting measurable improvement in defect detection rates. The 38% that didn’t see improvement share a common pattern: they implemented AI tooling without fixing the underlying data quality issues (inconsistent test data, no acceptance criteria, untraced requirements) that make AI-generated test cases meaningless. AI amplifies the quality of your inputs. It doesn’t compensate for vague requirements or missing test coverage information.

The CI/CD integration model in 2026 looks like this for mature teams: unit tests run on every commit, typically in under 2 minutes. Integration and API tests run on every pull request, typically in under 15 minutes. A full regression suite runs nightly or on every merge to the main branch, typically in 20-60 minutes. Security scans (OWASP ZAP, Snyk, or similar) run in the pipeline before staging deployment. Performance baselines run weekly against a production-like environment. Any failure in any gate blocks progression unless explicitly overridden with documented justification.

Edge case: organizations running legacy systems often can’t build this pipeline architecture because the system wasn’t designed for testability. A 15-year-old monolithic application with no API layer, a UI that renders in Internet Explorer, and a database schema with no foreign key constraints doesn’t accommodate modern test automation elegantly. QA on legacy system maintenance projects has to work within real constraints: automation where feasible, manual testing where necessary, and a documented risk acceptance for the parts that can’t be fully tested. Pretending the ideal CI/CD model applies to every environment is wishful thinking, not quality management.

QA Metrics That Actually Drive Decisions

A QA function that doesn’t measure itself can’t improve. But the wrong metrics produce the wrong incentives. “Number of test cases executed” is a vanity metric. A team that executes 2,000 trivially easy test cases looks more productive than a team that executes 400 carefully designed high-risk test cases. What gets measured is what gets optimized. Here are the metrics that drive genuine quality decisions.

Defect escape rate measures what percentage of defects were found in production vs. total defects found. A high escape rate means the test coverage is missing risk areas. Per ISTQB guidelines, this metric should be tracked by module and by testing phase to identify where the coverage gaps are, not just that they exist.

Defect density by module (defects per function point or per story) identifies which parts of the system generate the most quality debt. High defect density in the same module across multiple sprints points to a development quality problem, a requirements clarity problem, or a complexity problem – all of which require different interventions.

Test coverage measures what percentage of requirements, user stories, or code paths have test cases. 100% coverage isn’t realistic or always valuable. But knowing that a module has 30% coverage before a major release is information the release decision-makers need. Without this metric, release decisions are made without knowing what hasn’t been tested.

Mean Time to Detect (MTTD) measures how quickly the team finds defects after they are introduced. In a CI/CD environment with automated testing, MTTD should be minutes for unit and API test failures. In a manual testing environment, it may be days. A high MTTD means defects compound – one unfound bug creates several more as dependent code is built on top of broken logic.

Mean Time to Resolve (MTTR) measures the average time from defect discovery to verified fix. High MTTR for Critical defects indicates a development bottleneck, a process problem in defect routing, or unclear ownership. Six Sigma process improvement tools – Pareto charts for defect distribution, control charts for MTTR trends – apply directly to these metrics and provide the data-driven foundation for retrospective improvement actions.

Common QA Failures and What Causes Them

Understanding what goes wrong in QA is as useful as understanding best practices. These are the failure patterns that appear consistently across IT programs, regardless of industry or methodology.

QA starts too late. Development runs long, the release date doesn’t move, and QA absorbs the schedule compression. The test window shrinks from four weeks to ten days. Test coverage gets cut by priority negotiation rather than risk analysis. Things get shipped that aren’t adequately tested, and the QA team takes the blame for the production issues that follow. The root cause is not QA performance – it’s project management failure to protect the testing schedule.

Requirements are too vague to test. Acceptance criteria that say “the system should perform well” or “the UI should be user-friendly” can’t be tested. What is “performing well” – 2-second response time under 100 concurrent users? What is “user-friendly” – passes WCAG 2.1 AA accessibility standards? When QA can’t test against a criterion because the criterion isn’t specific, either the BA must revise the requirement or QA must guess – and guessing creates test cases that may have nothing to do with what the business actually needs.

Test environments don’t match production. Tests pass in QA and fail in production because the environments differ: different data volumes, different third-party integration endpoints, different memory configurations. Environment parity is an infrastructure responsibility, but QA must flag when the test environment is materially different from production and document the risk. Testing in a materially different environment is better than not testing – but the gap must be explicit.

Automation is confused with quality. Teams build large automation suites and assume they are covered. Automated tests verify the behavior they’re programmed to verify. They find regressions. They don’t find new defects in untested workflows, they don’t catch usability problems, and they don’t identify issues in complex multi-step user journeys that weren’t anticipated during test design. Automation is a tool for efficiency and repeatability, not a substitute for comprehensive quality assurance.

Defect triage doesn’t happen. Defects accumulate in the backlog without classification, assignment, or prioritization. The sprint team has no signal about which defects block progress and which can wait. Release decisions are made without knowing how many high-severity defects are open. This is a process failure, not a QA failure – it requires a structured triage cadence with the right stakeholders present.

QA Certifications and Professional Development

The ISTQB (International Software Testing Qualifications Board) is the primary certification body for QA professionals globally. The Foundation Level certification establishes the baseline: testing principles, test lifecycle, test design techniques, defect management, and test tools. It is recognized by employers across IT industries and is a common hiring requirement in regulated sectors.

Beyond Foundation, ISTQB offers Advanced Level specializations: Test Manager, Test Analyst, and Technical Test Analyst. These address the depth of knowledge required for senior QA roles leading programs, designing automation frameworks, or managing compliance-driven testing programs. Expert Level certifications exist for practitioners building organizational test competencies.

For QA engineers moving into automation, AWS Certified DevOps Engineer provides relevant infrastructure context. For those working in regulated industries, domain-specific knowledge of HIPAA, HL7 FHIR, PCI DSS, or SOX requirements isn’t credentialed separately – it’s gained on the job and through disciplined self-study of the regulatory frameworks that govern the systems being tested.

The career trajectory in 2026 moves in two directions from a QA Analyst starting point. One path deepens technical skills: automation engineering, performance testing, security testing, DevOps integration. The other path broadens scope: QA Lead, QA Manager, Test Director, Director of Quality Engineering. Both paths are viable. The choice depends on whether the individual’s strength is in technical depth or organizational leadership. What neither path should do is stall at manual testing for more than two to three years without building either automation competency or process leadership skills – both are essential for senior QA careers in 2026.

What QA Is Not: Clearing Up the Persistent Misconceptions

QA is not the last line of defense. If QA is the only mechanism preventing defects from reaching production, the development process is broken. Code review, unit testing, automated pipeline gates, and requirement quality all prevent defects before QA sees the build. QA is a structured verification layer within a broader quality system – not the sole guardian at the gate.

QA is not responsible for product quality. The development team is responsible for building it correctly. The BA is responsible for specifying it correctly. The Product Owner is responsible for prioritizing it correctly. QA is responsible for verifying that all of those activities produced the intended result and for providing evidence that the product meets its quality criteria. When production defects appear, the root cause is almost always upstream of QA – in requirements, design, or development practices.

QA is not a phase that happens after development. In Agile environments, testing is continuous. In any environment, QA activities – requirements review, test planning, test case design – begin before development starts. The “hand the build to QA when we’re done” model produces the schedule problems and quality gaps described earlier in this article.

QA is not just “clicking around in the app.” That characterization reflects a fundamental misunderstanding of what structured testing involves. A skilled QA analyst designs test cases using established techniques, maintains traceability from requirement to test result, applies risk-based prioritization to testing scope, writes defect reports that give developers everything they need to reproduce and fix an issue, and contributes to process improvement based on defect pattern analysis. That is analytical, methodical, high-stakes work.

Suggested External References:
1. ISTQB Certified Tester Foundation Level Syllabus (istqb.org)
2. HIPAA Security Rule – HHS.gov (hhs.gov)