Must-know QA Concepts

A test scenario is a one-sentence statement of what needs to be validated, without specifying the exact steps. It answers "what" not "how." A single scenario can generate multiple test cases covering different data combinations or paths.

The atomic unit of testing. A test case contains: preconditions, exact input data, execution steps, expected result, and postconditions. A well-written test case is self-contained, reproducible, and unambiguous — another person should get the same result running it.

A logical grouping of related test cases, typically by feature, module, or regression scope. Suites allow selective execution (run only auth tests after an auth change), track pass/fail rates per area, and define the scope of each test cycle. In Cypress and Playwright, a spec file maps to a suite.

Test data includes all inputs, preconditions, and environment state needed to execute a test. Good test data is deterministic (same run, same result), isolated (doesn't depend on other tests), and covers valid, invalid, and boundary values. In fintech, test data must also comply with data privacy rules — synthetic data and SIN generators are essential.

A living document that defines scope, objectives, approach, resources, environments, schedule, entry/exit criteria, and risk assessment for a testing effort. It is the contract between QA and stakeholders about what will and won't be tested — and the basis for all estimations. It should be updated as the project evolves.

Requirements Traceability Matrix: a document that links each requirement to the test cases that verify it, and tracks their execution status. It ensures full coverage (every requirement has at least one test), surfaces gaps, and provides audit evidence for compliance-driven projects. Critical for regulated industries like fintech.

Tests whether the system does what the requirements specify — "does it work?" regardless of how. Covers every business rule, user flow, and edge case. Functional testing is black-box by nature: the tester provides inputs and observes outputs without needing to know the internal implementation.

Tests how well the system performs its functions, not whether it performs them. Includes performance (response times under load), security (auth, injection, data exposure), accessibility (screen readers, WCAG compliance), usability (UI clarity), and reliability (uptime, error recovery). Often skipped under pressure — and the source of production incidents.

Simultaneous learning, test design, and execution where the tester's knowledge and intuition guide what to test next — no predefined scripts. Most effective for finding issues that scripted tests miss: edge cases not in requirements, unexpected UI interactions, and integration gaps. Quality of results depends heavily on domain expertise.

A shallow, wide pass over the most critical functionality to confirm a new build is stable enough for further testing. If smoke tests fail, the build is rejected and returned to developers — there's no point running the full suite. Should be fully automated and run on every deployment, completing in minutes.

A focused, narrow check on a specific area after a bug fix or minor change, to verify the fix works and nothing immediately adjacent broke. Unlike smoke testing — which is broad and runs on every build — sanity testing is targeted and context-driven. It's often done manually by the QA who filed the bug.

Re-running previously passing tests after code changes to ensure no existing functionality was broken. This is the primary driver for test automation — manual regression is unsustainable as codebases grow. A well-maintained automated regression suite is the safety net for continuous delivery.

Executing a specific test case that previously failed, after the defect has been fixed, to confirm the fix resolves the issue. Retesting is narrowly scoped to the failing scenario — it is not regression testing. Once the retest passes, regression follows to check for side effects introduced by the fix.

The sequence of states a defect passes through: New → Assigned → Open (being fixed) → Fixed → Retesting → Verified → Closed. Side paths include Rejected (not a bug), Deferred (won't fix now), and Duplicate. Each state transition has an owner, criteria, and a required action. Skipping steps is a process failure.

Measures the technical damage a defect causes to the system. Assigned by QA. Levels: Critical (system crash, data loss, security breach), Major (core feature broken, no workaround), Minor (feature works but degraded), Trivial (cosmetic, no functional impact). Severity is objective — it's about what broke, not who cares.

Measures business urgency — how quickly the defect must be fixed. Assigned by the product owner or business stakeholders, not QA. High priority bugs are fixed in the current sprint regardless of severity; Low priority may be deferred to a future release. Priority reflects business impact, deadlines, and stakeholder visibility.

Boundary Value Analysis: a black-box technique that tests input values at and around the edges of valid/invalid partitions. Most defects concentrate at boundaries — off-by-one errors in validation logic are extremely common. For a range, test: min-1, min, min+1, max-1, max, max+1.

Equivalence Partitioning: divides all possible inputs into classes where every value in a class is expected to behave identically. You test one representative value per class instead of every possible input. This dramatically reduces test count while maintaining coverage. Always combined with BVA for complete technique coverage.

User Acceptance Testing: the final testing phase where real users or business representatives validate that the system meets business requirements and is fit for purpose. UAT success is typically the production go-live gate. It validates business value — not just technical correctness. QA enables UAT; users execute it.

Quality Assurance is a proactive, process-oriented discipline focused on preventing defects before they occur. QA is not just testing — it includes process audits, definition of standards, code review participation, shift-left practices, and continuous improvement of the development pipeline. QA improves the conditions under which software is built.

Quality Control is a reactive, product-oriented activity focused on finding defects in an already-built artifact. Testing is a QC activity. The key distinction: QA prevents defects by improving processes; QC detects them by inspecting the product. In practice, QA teams do both — but the mental model matters for where energy is invested.

A defect that escaped the testing phase and was discovered in production — by the customer, a monitoring alert, or post-release QA. High leakage rates are a signal of inadequate coverage, poor test data, missing test types, or pressure to release without completing test cycles. Tracked as the Escape Rate metric.

A known defect intentionally shipped to production with explicit business sign-off — because the fix is too risky near a release, a workaround exists, or the business impact is acceptable. Requires formal documentation: who approved it, the workaround, the timeline for resolution, and the risk acceptance criteria.

Using code and tools to execute tests automatically, reducing manual effort, increasing repeatability, and enabling fast CI feedback. Automation is not a replacement for manual testing — it's best suited for regression, smoke, and data-driven scenarios. Poorly designed automation is worse than none: it creates false confidence and high maintenance cost.

Continuous Integration (merge frequently, run automated tests on every commit) and Continuous Delivery/Deployment (automatically deploy builds that pass all gates). Tests are the quality gate: if they fail, the pipeline blocks the deploy. QA owns the test strategy inside the pipeline — not just what tests exist, but what runs at each stage and what constitutes a blocking failure.

An assertion is a verification checkpoint in an automated test that compares the actual result against the expected value and fails the test if they don't match. A test without assertions is not a test — it's just code that runs. Good assertions are specific (check the exact value, not just "truthy"), meaningful, and produce clear failure messages that point to the root cause.

Testing application programming interfaces directly — bypassing the UI — to validate request/response contracts, authentication, authorization scopes, error handling, data integrity, and performance. API tests are faster, more stable, and easier to maintain than UI tests. They belong at the integration layer of the test pyramid and are the best ROI for automation.

Validates that the system meets performance SLAs (response time, throughput, error rate) under expected and peak concurrent users. Distinct from stress testing (push beyond limits to find breaking point) and spike testing (sudden traffic surge). Runs against a production-like environment with realistic data. Tools: k6, JMeter, Gatling.

Verifies that multiple components or services work correctly together — validating the contracts and data flows at integration points. Each service may work in isolation but fail when combined due to mismatched schemas, auth handoffs, or timing issues. Critical in microservice architectures where the number of integration points grows with each service added.

End-to-End tests validate complete user workflows from the UI through all system layers (frontend → API → database), simulating real user behavior in a real environment. They provide the highest confidence but are the most expensive to maintain — slow, brittle to UI changes, and environment-dependent. Reserve E2E for the most critical happy paths and highest-risk flows.