Testing & QA English Lab

Unit tests verify a single function or class in isolation, replacing dependencies with mocks or stubs. Integration tests check that two or more components work together correctly — for example, a service and its database layer. End-to-end (E2E) tests exercise the full application stack from the UI through to the backend, simulating real user journeys. The test pyramid model recommends many unit tests, fewer integration tests, and even fewer E2E tests because higher-level tests are slower and more brittle.

A professional defect report should contain: a concise, specific title summarising the problem; the severity (how badly it affects the product) and priority (how urgently it should be fixed); a numbered list of steps to reproduce the issue; the actual result observed; the expected result; and environment details (OS, browser, build version). Optional but valuable fields include screenshots or screen recordings, log excerpts, and a test data specification.

Regression testing verifies that previously working functionality has not been broken by recent code changes. It is typically run after every code change, bug fix, or new feature merge — often as part of a CI/CD pipeline. A regression suite is a curated set of test cases covering critical paths. A smoke test is a minimal regression run that checks only core functionality to quickly determine whether a build is stable enough for fuller testing.

Test coverage (most commonly line or branch coverage) measures what percentage of the codebase is executed by the test suite. High coverage indicates that most code paths are exercised, but it does not guarantee correctness — a test can execute a line without asserting the right outcome. Coverage is best used as a floor (e.g. "no PR below 80% coverage") rather than a quality ceiling. Mutation testing is a more rigorous technique that checks whether tests can detect deliberate code changes.

Behaviour-Driven Development (BDD) is a practice where tests are written in plain language that both technical and non-technical stakeholders can read. Gherkin is the structured language used to write BDD scenarios using Given/When/Then syntax: Given describes the initial context, When describes the action taken, and Then describes the expected outcome. Scenarios live in .feature files and are executed by frameworks such as Cucumber or SpecFlow.

A go/no-go decision is communicated after evaluating whether the product meets release criteria. A typical QA sign-off includes: the number of open defects by severity, test execution results (pass/fail/blocked counts), coverage of acceptance criteria, any known gaps or deferred issues, and a clear recommendation. Common phrasing includes: "All P1 defects are resolved. Two P2 defects are accepted as known issues. QA recommends go." A no-go typically cites unresolved blockers or insufficient test coverage.

Severity describes the technical impact of a defect on the system — a crash is higher severity than a cosmetic issue. Priority describes the business urgency of fixing it — a minor bug on the checkout page may have low severity but high priority due to its business impact. A defect can be high severity but low priority (e.g. a crash in a rarely used admin feature) or low severity but high priority (e.g. a misspelling in a product launch banner). Distinguishing these terms is a common QA interview topic.

These are all test doubles — objects that replace real dependencies in unit tests. A stub returns pre-configured responses to calls without recording anything. A mock is pre-programmed with expectations about which calls it should receive and will fail the test if those expectations are not met. A spy wraps a real object, allowing real behaviour while recording calls for later assertion. The distinction matters when writing precise test documentation and reviewing automation frameworks.

Performance testing evaluates how a system behaves under load. Load testing applies expected production traffic to check normal performance. Stress testing pushes beyond expected limits to find the breaking point. Spike testing applies a sudden large increase in load. Soak (endurance) testing runs sustained moderate load over many hours to detect memory leaks. Key metrics include throughput (requests per second), latency percentiles (P95, P99), and error rate.

Core security testing vocabulary includes: OWASP Top 10 (the most critical web application vulnerabilities), CVSS score (a standardised severity rating from 0–10), SAST (Static Application Security Testing — analysing source code without running it), DAST (Dynamic Application Security Testing — probing a running application), and IAST (Interactive AST — instrumentation during test execution). Penetration testing reports typically document findings using a risk matrix and include reproduction steps and remediation recommendations.