دیسیپلین تست: از Test Plan تا تست بارTesting Discipline: From Test Plans to Load Testing

You can probably write an @Test. You mock with Mockito, spin up a real Postgres with Testcontainers, write an integration test. This site's "testing" chapter covers that. But job postings ask for something else, and that is exactly where most five-year engineers slip: "familiar with test levels and types", "able to write a Test Plan and Test Cases", "experience with performance and load testing".

Those are not mechanics, they are discipline. The difference between a mid-level engineer and a senior one is not who knows verify(). It is that when both are told "test this feature", one writes a few arbitrary tests and the other produces, in ten minutes, a list of test conditions that misses nothing important, knows which of them to automate and which not to, and can state out loud: "with this suite, here is the risk that remains open."

This chapter is exactly that layer: the mental framework, the professional vocabulary, the techniques that generate test cases, the documentation a mature organisation expects, and non-functional testing — load testing above all — with real tools and runnable examples.

Part 0 — The vocabulary seniors do not get wrong

Error, defect, failure

Three words that everyday speech merges and professional conversation keeps apart:

• error (mistake) — the human act. The developer typed < where <= belonged.
• defect (fault, bug) — the result of that error, sitting in the code or the document. That wrong < is right there in the file.
• failure — when the defect manifests during execution and behaviour deviates from expectation. A user with a balance of exactly 10,000 cannot withdraw.

Why does it matter? Because a defect can sit for years without producing a failure (that path is never executed), and because not every failure comes from a code defect — environmental conditions (bad memory, a wrong system clock, a network partition) produce failures too.

Verification versus validation

• Verification: "did we build the product right?" — conformance to specification and design.
• Validation: "did we build the right product?" — does it solve the real user need.

You can have a system that is 100% green (perfect verification) and that nobody uses (zero validation). This distinction is the heart of the UAT conversation.

Senior judgment — "quality" is not a number, it is residual risk — The goal of testing is not to prove the absence of defects; for any non-trivial program that is impossible (the input space is effectively infinite). The goal is reducing risk to an acceptable level at a sane cost. Whenever someone asks "how much testing is enough?", the professional answer is: "until the residual risk falls below the business's acceptance threshold" — and then you must be able to name that risk.

Why earlier is cheaper

The later a defect is found, the more it costs — not because of some magic multiplier, but for plain reasons: more code has been built on top of it, more people get involved, and if it reached production you also owe a data fix, a customer notification and possibly compensation. That is why shift-left (pushing testing leftward on the timeline: requirement reviews, unit tests, tests in CI) is economics, not aesthetics.

And alongside it, shift-right: some testing genuinely cannot happen before production (real user behaviour, real traffic). There, canary releases, feature flags, synthetic monitoring and chaos engineering are your tools — which ties into the observability and resilience chapters.

Part 1 — Test levels: who catches what

A test level is a group of test activities managed together, usually tied to a stage of development. The common standard (ISTQB v4) counts five:

Diagram: mapping test levels to design levels in the V-model — نمودار: نگاشت سطوح تست به سطوح طراحی در مدل V.

flowchart LR
  R[Requirements] --> A[Architecture]
  A --> D[Detailed design]
  D --> C[Code]
  C --> UT[Component tests]
  UT --> IT[Component integration]
  IT --> ST[System tests]
  ST --> AT[Acceptance tests]
  R -.validated by.-> AT
  A -.verified by.-> ST
  D -.verified by.-> IT

The acceptance sub-types interviewers ask about

• UAT (User Acceptance Test) — the user or product owner runs real business scenarios.
• OAT (Operational Acceptance Test) — the ops team: does backup work? Is there a rollback path? Are alerts wired? Is the runbook written? Junior teams forget this one and discover it at 2 a.m. on release night.
• Contractual / regulatory acceptance — conformance to a contract or regulation (log retention, privacy obligations).
• Alpha / beta — alpha at the producer's site with real users; beta in the user's own environment.

Part 2 — Test types: functional, non-functional, structural, change-related

The level says where you test; the type says which property you are hunting. Four families:

1. Functional — "what does it do?" Correct calculations, business rules, flows.
2. Non-functional — "how well does it do it?" Performance, security, reliability, usability, compatibility, maintainability, portability. These are the quality characteristics of ISO/IEC 25010.
3. Structural (white-box) — "is the code structure exercised?" Statement, branch, path, MC/DC coverage.
4. Change-related — confirmation testing (did that specific bug actually get fixed?) and regression testing (did anything else break?).

ISO/IEC 25010 and the 2023 revision — The product quality model of ISO/IEC 25010 was revised in 2023 and now has 9 characteristics, with "Safety" promoted to a top-level characteristic (previously there were 8). When an interviewer asks about "types of non-functional testing", naming this model and listing a few of its characteristics — performance efficiency, reliability, security, usability, compatibility, maintainability, portability, functional suitability, safety — shows you have a framework rather than a memorised list.

Do not push non-functional testing to the end of the project — Non-functional testing is not a "final phase". If your architecture works with 50 concurrent users and your SLO is 5,000, no amount of last-week tuning will save you; the data model and access patterns have to change. A small but early load test on the critical path is worth more than a giant one two days before go-live.

Part 3 — Black-box, white-box, grey-box

The key point seniors make: 100% code coverage guarantees nothing about requirements that were never written. If the developer forgot to implement the "negative balance" case, no coverage tool will tell you something is missing. That is why black-box techniques (next part) are the foundation and white-box is the complement.

Part 4 — Test design techniques: getting from a requirement to a list of tests

This part is the heart of the chapter. If you learn only one section deeply, make it this one — because in an interview you will typically be handed a small requirement and asked to "write the test cases".

4.1 Equivalence partitioning

The idea: split the inputs into groups the system is expected to treat identically, then test one representative per group. If one representative reveals a defect, so would the others; more tests from the same partition cost money and add no information.

Worked example — a transfer fee:

Transfer amounts from 10,000 to 50,000,000 are allowed. Up to 1,000,000 the fee is a flat 5,000; above 1,000,000 and up to 10,000,000 the fee is 0.1%; above 10,000,000 the fee is a flat 25,000. The amount must be an integer.

Partitions — both valid and invalid, and it is the invalid ones most candidates forget:

4.2 Boundary value analysis

The idea: bugs nest on boundaries, because < and <= are one character apart. For every boundary, test the values around it.

Two schools:

• 2-value BVA: the boundary itself and the first value outside it. For the 1,000,000 boundary: 1,000,000 and 1,000,001.
• 3-value BVA: one before, the boundary, one after — 999,999, 1,000,000, 1,000,001. Stricter, and recommended for financial or safety logic.

For the example above with 3-value BVA the test values are 9,999 / 10,000 / 10,001, 999,999 / 1,000,000 / 1,000,001, 9,999,999 / 10,000,000 / 10,000,001 and 49,999,999 / 50,000,000 / 50,000,001.

And that maps straight onto a JUnit 5 parameterised test:

@ParameterizedTest(name = "amount={0} -> fee={1}")
@CsvSource({
    "10_000,      5_000",
    "1_000_000,   5_000",
    "1_000_001,   1_000",     // 0.1% of 1,000,001 rounded down
    "10_000_000, 10_000",
    "10_000_001, 25_000",
    "50_000_000, 25_000"
})
void feeIsCorrectAtBoundaries(long amount, long expectedFee) {
    assertThat(feeCalculator.feeFor(amount)).isEqualTo(expectedFee);
}

@ParameterizedTest
@ValueSource(longs = {9_999L, 50_000_001L, -1L, 0L})
void amountsOutsideAllowedRangeAreRejected(long amount) {
    assertThatThrownBy(() -> feeCalculator.feeFor(amount))
        .isInstanceOf(AmountOutOfRangeException.class);
}

4.3 Decision tables

When the outcome depends on a combination of conditions, equivalence partitioning is not enough; you must lay out the combinations systematically.

Worked example — withdrawal authorisation: Conditions: (C1) is the account active? (C2) are funds sufficient? (C3) has the user completed two-factor authentication? (C4) is the amount above the daily limit?

Important detail: – means don't care; the full table has 2⁴ = 16 combinations and rule collapsing brought us to 5. That collapsing is the point, and it is what an interviewer is looking for: show that you understand which combinations are unreachable or irrelevant.

Senior judgment — put the decision table into the code — If you drew a decision table, feed that same table into the test as the source of truth. With @CsvSource, each row becomes one rule, and if someone adds a rule tomorrow the PR diff shows exactly which rule changed. This fuses document and test and prevents the classic "documentation that drifted from the code".

@ParameterizedTest(name = "R{index}: active={0} funds={1} mfa={2} overLimit={3} -> {4}")
@CsvSource({
    "false, true,  true,  false, ACCOUNT_BLOCKED",
    "true,  false, true,  false, INSUFFICIENT_FUNDS",
    "true,  true,  false, false, MFA_REQUIRED",
    "true,  true,  true,  true,  MANUAL_REVIEW",
    "true,  true,  true,  false, APPROVED"
})
void withdrawalDecisionTable(boolean active, boolean funds, boolean mfa,
                             boolean overLimit, Decision expected) {
    var request = new WithdrawalRequest(active, funds, mfa, overLimit);
    assertThat(policy.decide(request)).isEqualTo(expected);
}

4.4 State transition testing

When the system has memory — the response to an event depends on history — draw the state machine.

Diagram: an order state machine with the legal events — نمودار: ماشین حالت یک سفارش و رویدادهای مجاز.

stateDiagram-v2
  [*] --> CREATED
  CREATED --> PAID: pay
  CREATED --> CANCELLED: cancel
  PAID --> SHIPPED: ship
  PAID --> REFUNDED: refund
  SHIPPED --> DELIVERED: deliver
  SHIPPED --> RETURNED: return
  DELIVERED --> RETURNED: return
  RETURNED --> REFUNDED: refund
  CANCELLED --> [*]
  REFUNDED --> [*]

Three coverage levels come out of that diagram:

• State coverage: every state visited at least once. The weakest level.
• Transition coverage / 0-switch: every edge traversed at least once. This is the acceptable minimum.
• 1-switch: every consecutive pair of transitions (e.g. pay then ship) traversed. Catches history-dependent bugs.

And most importantly: the invalid transitions. Draw the full states × events grid and test the empty cells — "what does ship do in state CREATED?" The right answer is a specific error with no state change, not a NullPointerException.

@ParameterizedTest
@EnumSource(OrderState.class)
void shipIsOnlyLegalFromPaid(OrderState from) {
    Order order = Order.inState(from);
    if (from == OrderState.PAID) {
        order.ship();
        assertThat(order.state()).isEqualTo(OrderState.SHIPPED);
    } else {
        assertThatThrownBy(order::ship)
            .isInstanceOf(IllegalStateTransitionException.class);
        assertThat(order.state()).isEqualTo(from);   // no side effect
    }
}

An invalid transition must be inert, not merely throw — The most common state-machine bug is a method that performs a side effect first (publishes an event, mutates a field) and then checks the guard and throws. Without a surrounding transaction you now hold a half-mutated state. In every invalid-transition test, assert not only the exception but also that the state did not change and no event was published.

4.5 Pairwise (all-pairs) testing

With several independent parameters the Cartesian product explodes. Suppose browser (4) × OS (3) × locale (5) × payment type (4) × user tier (3) = 720 combinations. Testing them all is impossible.

The empirical observation: the overwhelming majority of defects are triggered by the interaction of one or two parameters, not five. So if you build a set where every pair of values from every two parameters appears together at least once, roughly 20 combinations give you nearly the same detection power.

Practical tooling: PICT (Microsoft, open source) or ACTS (NIST). A PICT model file is plain text:

Browser:  Chrome, Firefox, Safari, Edge
OS:       Windows, macOS, Linux
Locale:   fa-IR, en-US, ar-SA, tr-TR, de-DE
Payment:  Card, Wallet, Gateway, COD
UserTier: Guest, Basic, Premium

IF [Payment] = "COD" THEN [UserTier] <> "Guest";

# generate the pairwise set (PICT defaults to order=2)
pict model.txt > pairs.tsv

# three-way coverage for the high-risk paths
pict model.txt /o:3 > triples.tsv

4.6 Error guessing and exploratory testing

Error guessing means using experience to guess where things usually break: empty string, leading/trailing whitespace, an apostrophe in the input, the last day of a leap year, a zero-byte file, double-clicking "pay", closing the browser mid-transaction, hitting back after a successful submit.

Make it professional with a fault attack list: a written, maintained list of failures that have actually happened in your project. Every incident adds a row. This is the single most valuable test document a mature team owns.

Exploratory testing is its structured sibling: under session-based test management, a 60–90 minute timebox with an explicit charter ("investigate cart behaviour when stock drops to zero during checkout") and simultaneous note-taking. Output: defects, questions, and ideas for automated tests.

4.7 Positive and negative testing

• Positive (happy path): valid input, correct result.
• Negative (unhappy path): invalid input or bad conditions produce the correct, controlled error.

In a mature service the healthy ratio usually favours the negative cases — there is one happy path and dozens of ways to fail. If a PR contains only happy-path tests, that is exactly where you should stop in code review.

Senior judgment — which technique when:

Part 5 — The documentation a mature organisation expects

This is where "just a coder" engineers come up short. You do not have to love documentation; you do have to know which question each document answers and what its smallest useful version is.

5.1 The Test Plan

A Test Plan states, for this project or release, what is tested, how, by whom, in which environment, by when, and with what stopping criteria. The old IEEE 829 and the current ISO/IEC/IEEE 29119-3 give you templates, but nobody expects 40 pages. The useful skeleton:

5.2 A good test case

A good test case must be executable by someone who does not know the project, and its outcome must be judgeable. The anatomy:

5.3 Traceability from requirement to test

A requirements traceability matrix (RTM) links each requirement to the tests that cover it. It answers three questions nothing else does:

1. Coverage: which requirement has no test at all? (a real hole)
2. Change impact: if REQ-PAY-7 changes, which tests must be revisited?
3. Status reporting: "92% of P1 requirements are covered and green" means something to a manager; "84% line coverage" does not.

Diagram: the traceability chain from business need to defect — نمودار: زنجیره‌ی ردیابی از نیاز کسب‌وکار تا نقص.

flowchart LR
  BR[Business need] --> REQ[Requirement / user story]
  REQ --> AC[Acceptance criteria]
  AC --> TC[Test cases]
  TC --> RUN[Test runs]
  RUN --> DEF[Defects]
  DEF -.reopens.-> REQ

In practice you do not need a spreadsheet. Put the requirement id in the test name or an annotation and derive the matrix from code:

@Test
@Tag("REQ-PAY-7")
@DisplayName("REQ-PAY-7 | withdrawal above daily limit goes to manual review")
void withdrawalAboveDailyLimitGoesToManualReview() { /* ... */ }

And if execution data lives in a database (which most test-management tools do), finding uncovered requirements is one query:

SELECT r.req_id,
       r.title,
       COUNT(tc.tc_id) AS test_cases,
       COUNT(*) FILTER (WHERE tr.status = 'PASSED') AS passed
FROM requirement r
LEFT JOIN test_case tc ON tc.req_id = r.req_id
LEFT JOIN LATERAL (
    SELECT status
    FROM test_run
    WHERE test_run.tc_id = tc.tc_id
    ORDER BY executed_at DESC
    FETCH FIRST 1 ROW ONLY
) tr ON TRUE
WHERE r.priority = 'P1'
GROUP BY r.req_id, r.title
HAVING COUNT(tc.tc_id) = 0
    OR COUNT(*) FILTER (WHERE tr.status = 'PASSED') < COUNT(tc.tc_id)
ORDER BY r.req_id;

SELECT r.req_id,
       r.title,
       COUNT(tc.tc_id) AS test_cases,
       COUNT(CASE WHEN tr.status = 'PASSED' THEN 1 END) AS passed
FROM requirement r
LEFT JOIN test_case tc ON tc.req_id = r.req_id
OUTER APPLY (
    SELECT status
    FROM test_run
    WHERE test_run.tc_id = tc.tc_id
    ORDER BY executed_at DESC
    FETCH FIRST 1 ROW ONLY
) tr
WHERE r.priority = 'P1'
GROUP BY r.req_id, r.title
HAVING COUNT(tc.tc_id) = 0
    OR COUNT(CASE WHEN tr.status = 'PASSED' THEN 1 END) < COUNT(tc.tc_id)
ORDER BY r.req_id;

5.4 A defect report a developer can act on

A bad defect report costs three days of ping-pong. A good one contains:

• Title: what, where, under which conditions — in one line. Not "the site is broken".
• Environment: build version, browser/client, environment (staging/prod), tenant id, exact time with timezone.
• Reproduction steps: the minimal steps that produce the bug. Minimise them if you can.
• Actual versus expected result.
• Evidence: logs with the traceId, screenshots, the raw HTTP response — not a phone photo of a monitor.
• Reproduction rate: 10 out of 10, or 2 out of 10? That number is critical for concurrency bugs.
• Severity and priority — see below.
• Workaround, if one exists.

5.5 Exit criteria and Definition of Done

What does "testing is finished" mean? If your answer is "we ran out of time", that is not an exit criterion, that is surrender. A defensible exit criterion combines:

• Coverage: 100% of P1 and P2 requirements have at least one executed test.
• Execution: ≥95% of planned test cases executed; 100% of P1 executed and passing.
• Defects: zero open Critical/High defects; Medium defects deferred with written product-owner approval.
• Non-functional: p95 under the SLO at target load; error rate below threshold; security scan free of Critical findings.
• Operational readiness: runbook, alerts, dashboard and a tested rollback path.

Part 6 — The pyramid, the ice-cream cone, and where contract tests fit

Diagram: a healthy pyramid versus the ice-cream cone anti-pattern — نمودار: هرم سالم در برابر مخروط بستنی.

flowchart TB
  subgraph Pyramid["Healthy pyramid"]
    P1["E2E: few, slow, high value"] --> P2["Integration / contract: some"]
    P2 --> P3["Unit: many, fast, cheap"]
  end
  subgraph Cone["Ice-cream cone"]
    C1["Manual testing: huge"] --> C2["E2E UI: many"]
    C2 --> C3["Integration: few"]
    C3 --> C4["Unit: almost none"]
  end

The pyramid's logic is economic, not ideological: the higher you go, the slower, more brittle, more expensive to maintain and vaguer at pinpointing causes each test becomes. So build fewer of them — but do not delete them, because only the top of the pyramid tells you the whole system actually works.

Clinical symptoms of the ice-cream cone — If you see these, your pyramid is upside down: the build takes over 20 minutes and nobody waits for it; diagnosing a failure requires watching a UI test video; the team has a "stabilisation week" before every release; most bugs are found by manual QA rather than CI; and "just re-run it, maybe it goes green" has become a normal sentence.

Contract testing — the missing layer

The microservices problem: each service's unit tests are green, yet putting them together breaks, because the consumer assumed amount was a string and the provider made it a number. The naive answer is "E2E with all services running" — slow, brittle, and requiring the whole world to boot in CI.

Contract testing says: record the contract between two services in an executable file, then test each side separately against that contract.

• Consumer-driven (Pact): the consumer writes its expectations, producing a pact file; the provider verifies it in its own CI. The practical prerequisite is a shared broker to exchange contracts.
• Provider-driven (Spring Cloud Contract): the provider writes the contract in a DSL, which generates both the provider test and the stub the consumer uses in its own tests.

// src/test/resources/contracts/shouldReturnAccountBalance.groovy
Contract.make {
    description "should return balance for an existing account"
    request {
        method GET()
        url "/api/accounts/ACC-1001/balance"
        headers { accept(applicationJson()) }
    }
    response {
        status OK()
        headers { contentType(applicationJson()) }
        body(
            accountId: "ACC-1001",
            balance: 250000,
            currency: "IRR"
        )
        bodyMatchers {
            jsonPath('$.balance', byType())
            jsonPath('$.currency', byRegex('[A-Z]{3}'))
        }
    }
}

<plugin>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-contract-maven-plugin</artifactId>
  <version>4.3.0</version>
  <extensions>true</extensions>
  <configuration>
    <baseClassForTests>com.example.contract.ContractBase</baseClassForTests>
    <testFramework>JUNIT5</testFramework>
  </configuration>
</plugin>

Senior judgment — contract tests do not replace E2E, they replace 90% of it — Contract tests tell you the message shapes are compatible. They still do not tell you the business flow is right (does an order actually ship after payment?). So keep a few E2E tests on the revenue paths and delegate the rest of the compatibility surface to contracts. The question that scores points in an interview: "can the provider deploy without breaking any consumer? If you do not know the answer, you do not have contract tests."

Part 7 — Automation strategy

7.1 What to automate and what not to

Automation is an investment: build cost plus maintenance cost versus the saving on future runs. If a test runs twice a year and takes three manual minutes, automating it is a loss.

7.2 Managing flaky tests

A flaky test passes sometimes and fails other times with no code change. The real danger is not the failure itself; it is that the team learns to ignore red, and the day a genuine bug turns the build red, nobody reacts.

The process that works:

1. Measure: derive the flakiness rate from CI history (same test, same commit, different result).
2. Time-boxed quarantine: pull the flaky test out of the main gate but keep running it in a separate job, with an owner and a deadline. Quarantine without a deadline is deletion.
3. Fix the root cause, not with a retry.
4. Budget: for example "at most 5 tests in quarantine"; when it fills, new work stops until it is cleaned.

retryFailedTests is a painkiller, not a cure — Adding automatic retries is tempting and turns the build green in the short term. It has two costs: it hides rare real bugs (races in production code, not in the test) and it multiplies the worst-case run time. If you must retry, at least report it: a test that passed only on retry should be flagged in the report and recorded on a flakiness dashboard, otherwise you have thrown information away.

7.3 Test data management

Three strategies, in order of preference:

1. Built inside the test (test data builder) — the best case. Each test creates its own data, so it is independent and readable.
2. A small shared fixture — for immutable reference data (currency list, bank codes).
3. A copy of production (anonymised) — only for load testing and data migration. It carries compliance risk (GDPR and local equivalents) and a high maintenance cost.

The builder pattern with sensible defaults transforms test readability: each test states only what matters to it.

public final class AccountBuilder {
    private String id = "ACC-" + UUID.randomUUID();
    private long balance = 1_000_000L;
    private boolean active = true;
    private boolean mfaEnabled = true;

    public static AccountBuilder anAccount() { return new AccountBuilder(); }

    public AccountBuilder withBalance(long balance) { this.balance = balance; return this; }
    public AccountBuilder inactive() { this.active = false; return this; }
    public AccountBuilder withoutMfa() { this.mfaEnabled = false; return this; }

    public Account build() { return new Account(id, balance, active, mfaEnabled); }
}

// the resulting readability: only the meaningful difference is visible
var poorAccount = anAccount().withBalance(0).build();

To reset the database between integration tests, TRUNCATE is usually faster than row-by-row deletion — but the identity-reset syntax differs between the dialects:

-- empty the tables and reset identity in one statement
TRUNCATE TABLE payment, account RESTART IDENTITY CASCADE;

-- Oracle truncates each table separately and identities reset separately
TRUNCATE TABLE payment CASCADE;
TRUNCATE TABLE account CASCADE;
ALTER TABLE account MODIFY (id GENERATED BY DEFAULT AS IDENTITY (START WITH 1));

Do not "anonymise" production data — synthesise it — Stripping names and phone numbers is not enough: date of birth plus postcode plus recent transactions is usually sufficient for re-identification. If you must use real data, use genuine pseudonymisation (a stable mapping with a separately held key), keep the environment at the same confidentiality level as production, and log every access. The best option is to write a synthetic data generator that mimics production's statistical distribution without containing a single real record.

7.4 Environment strategy and test doubles

The precise test double vocabulary (the common taxonomy) — useful in interviews:

And for environments:

• Hermetic / ephemeral: each build creates and destroys its own environment (Testcontainers, a temporary Kubernetes namespace). More expensive to set up, but free of interference and drift.
• Shared staging: cheap, but three teams work on it simultaneously and failures contaminate each other.
• External partner services: if a stable sandbox exists, use it — but not in the main gate. Run the main path against a contract-based double (WireMock or a mock server) and run a nightly job against the real sandbox to detect drift.

7.5 Running tests in CI

Pipeline detail belongs to the CI/CD chapter; here we only cover the test layering:

<!-- surefire: fast unit tests in the test phase -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <excludedGroups>integration,slow</excludedGroups>
    <parallel>classes</parallel>
    <threadCount>4</threadCount>
  </configuration>
</plugin>

<!-- failsafe: integration tests in the integration-test phase -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-failsafe-plugin</artifactId>
  <configuration>
    <groups>integration</groups>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>integration-test</goal>
        <goal>verify</goal>
      </goals>
    </execution>
  </executions>
</plugin>

# the fast developer loop: unit only
mvn -q test

# the merge gate: unit + integration, failing at verify
mvn -q verify

# JUnit 5 parallel execution (src/test/resources/junit-platform.properties)
# junit.jupiter.execution.parallel.enabled = true
# junit.jupiter.execution.parallel.mode.default = concurrent

7.6 Code coverage: a signal, not a target

Coverage only tells you which lines or branches were executed — not that they were checked. A test with no assertion still produces coverage.

The useful flavours:

• Line/statement coverage — the weakest.
• Branch coverage — both sides of every if were taken. The meaningful minimum.
• MC/DC — for each atomic condition inside a compound condition, show it independently affects the outcome. Mandatory in safety-critical domains.

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.13</version>
  <executions>
    <execution><goals><goal>prepare-agent</goal></goals></execution>
    <execution>
      <id>check</id>
      <phase>verify</phase>
      <goals><goal>check</goal></goals>
      <configuration>
        <rules>
          <rule>
            <element>BUNDLE</element>
            <limits>
              <limit>
                <counter>BRANCH</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.70</minimum>
              </limit>
            </limits>
          </rule>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

7.7 Mutation testing — testing your tests

If coverage says "this line executed", mutation testing asks "if I deliberately break this line, does any test go red?"

How it works: the tool creates mutants in the bytecode — turning < into <=, return true into return false, removing a method call — and runs the tests. If a test fails, the mutant was killed. If everything stays green, the mutant survived, which means that behaviour is effectively unguarded.

Mutation score = killed mutants ÷ total mutants. It is a far more honest number than coverage.

<plugin>
  <groupId>org.pitest</groupId>
  <artifactId>pitest-maven</artifactId>
  <version>1.19.1</version>
  <configuration>
    <targetClasses><param>com.example.payment.domain.*</param></targetClasses>
    <targetTests><param>com.example.payment.domain.*Test</param></targetTests>
    <mutationThreshold>75</mutationThreshold>
    <timestampedReports>false</timestampedReports>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>org.pitest</groupId>
      <artifactId>pitest-junit5-plugin</artifactId>
      <version>1.2.2</version>
    </dependency>
  </dependencies>
</plugin>

# full run over the module
mvn -q test-compile org.pitest:pitest-maven:mutationCoverage

# incremental mode: only code changed against the base branch (ideal for PRs)
mvn -q test-compile org.pitest:pitest-maven:scmMutationCoverage \
    -Dinclude=ADDED,MODIFIED
# HTML report: target/pit-reports/index.html

Senior judgment — do not run mutation testing over the whole project — PIT is slow because it re-runs tests per mutant. The practical strategy is to run it only on the domain core (money, pricing, authorisation, calculations) and only on the code changed in the PR. Even if you enforce no threshold at all, reading one PIT report over your domain core is a sobering experience: it usually surfaces a handful of surviving mutants in exactly the places that are scary in production.

Part 8 — Non-functional testing: performance, load, stress, endurance

8.1 Precise vocabulary — teams routinely misuse these

A spike test measures recovery, not just survival — Most teams look only at "did the system survive?". The more important question is: after the spike passes, how long until it returns to normal? Systems with unbounded queues may show no errors during the surge yet still be chewing through expired requests half an hour later. The correct pattern is fast rejection (load shedding) plus bounded queues — covered in the resilience chapter.

8.2 SLO first, then the test

A load test without a pass criterion is just colourful chart generation. So before anything else:

• SLI (indicator): what you measure. Example: "the percentage of POST /payments requests that receive a 2xx/4xx response in under 800ms".
• SLO (objective): the target value for that indicator over a window. Example: "99.5% over any 30 days".
• SLA (agreement): the contractual commitment with penalties. Usually looser than the internal SLO.
• Error budget: 1 minus the SLO. At 99.5%, the monthly budget is roughly 3 hours 36 minutes.

8.3 The workload model: open versus closed

This concept is the line between a toy load test and a credible one.

• Closed model: a fixed number of virtual users, each looping "send request, get response, think, send again". If the system slows down, the arrival rate automatically drops. This models systems with a bounded user population well (an internal app with 200 employees).
• Open model: users arrive at an arrival rate independent of how slow the system has become. This models real internet traffic — the world does not wait for you.

Little's Law is your mental tool for converting between these:

L = λ × W

That is, "requests concurrently in the system = arrival rate × average time in system". At 200 requests per second with a 250ms average response, about 50 requests are in flight on average — which maps directly onto your connection-pool and thread-pool sizing. If the pool holds 20, a queue forms and p99 explodes even while the CPU sits idle.

8.4 Modelling real load

Synthetic load ("everyone just hits GET /") produces worthless results. Build the workload model from real data: derive the endpoint distribution and the peak hour from access logs or an events table.

SELECT endpoint,
       COUNT(*) AS hits,
       ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct,
       ROUND(COUNT(*) / 3600.0, 2) AS rps_in_peak_hour
FROM access_log
WHERE ts >= TIMESTAMP '2026-08-05 12:00:00'
  AND ts <  TIMESTAMP '2026-08-05 13:00:00'
GROUP BY endpoint
ORDER BY hits DESC
FETCH FIRST 15 ROWS ONLY;

SELECT endpoint,
       COUNT(*) AS hits,
       ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS pct,
       ROUND(COUNT(*) / 3600, 2) AS rps_in_peak_hour
FROM access_log
WHERE ts >= TIMESTAMP '2026-08-05 12:00:00'
  AND ts <  TIMESTAMP '2026-08-05 13:00:00'
GROUP BY endpoint
ORDER BY hits DESC
FETCH FIRST 15 ROWS ONLY;

From the output, build a load profile: for example 60% search, 25% detail view, 10% add-to-cart, 5% checkout — then implement those same ratios in the scenario. Add realistic think time between steps, without which your concurrency pattern is entirely unrealistic.

Diagram: load-test topology and the signals to watch at each hop — نمودار: توپولوژی تست بار و سیگنال‌هایی که در هر گره باید دید.

flowchart LR
  LG[Load generators] --> LB[Load balancer]
  LB --> APP[App instances]
  APP --> DB[(Database)]
  APP --> CACHE[(Cache)]
  APP --> EXT[External / stubbed services]
  MON[Metrics: RED + USE] -.scrapes.- APP
  MON -.scrapes.- DB
  MON -.scrapes.- LG

8.5 Three tools: JMeter, Gatling, k6

k6 — least friction for CI

k6 is a Go binary; you write the test in JavaScript and thresholds directly determine the process exit code — so the CI gate is free.

// payments-load.js
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Trend, Rate } from 'k6/metrics';

const paymentLatency = new Trend('payment_latency', true);
const businessErrors = new Rate('business_errors');

export const options = {
  scenarios: {
    // open model: arrival rate independent of how slow the system gets
    steady_traffic: {
      executor: 'ramping-arrival-rate',
      startRate: 20,
      timeUnit: '1s',
      preAllocatedVUs: 100,
      maxVUs: 500,
      stages: [
        { target: 20,  duration: '1m' },   // warm-up
        { target: 200, duration: '3m' },   // ramp to target
        { target: 200, duration: '10m' },  // steady state
        { target: 0,   duration: '1m' },   // ramp down
      ],
    },
  },
  thresholds: {
    'http_req_failed': ['rate<0.01'],
    'http_req_duration{name:createPayment}': ['p(95)<800', 'p(99)<2000'],
    'business_errors': ['rate<0.005'],
    'checks': ['rate>0.99'],
  },
};

export default function () {
  const payload = JSON.stringify({ accountId: 'ACC-1001', amount: 250000, currency: 'IRR' });
  const res = http.post('https://staging.example.internal/api/payments', payload, {
    headers: { 'Content-Type': 'application/json' },
    tags: { name: 'createPayment' },   // stable tag for metric grouping
  });

  const ok = check(res, {
    'status is 201': (r) => r.status === 201,
    'has payment id': (r) => r.json('paymentId') !== undefined,
  });

  paymentLatency.add(res.timings.duration);
  businessErrors.add(!ok);
  sleep(Math.random() * 2 + 1);   // realistic think time
}

# run locally
k6 run payments-load.js

# override options from the command line (for a quick smoke run)
k6 run --vus 5 --duration 30s payments-load.js

# emit JSON for later analysis
k6 run --out json=results.json payments-load.js

# scaffold a new script
k6 new payments-load.js

Why tags matters — If the URL contains a variable id (/api/payments/9f3a...), k6 counts each one as a separate name and your metrics shatter. With tags: { name: 'createPayment' } you group them under one stable name and can attach a threshold to it — exactly like http_req_duration{name:createPayment} above.

Gatling — when the team is a Java team

Since 3.7 Gatling has a full Java DSL; you do not need Scala. The test lives beside the project code in src/test/java and runs through the Maven plugin.

package simulations;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

import java.time.Duration;

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

public class PaymentSimulation extends Simulation {

    HttpProtocolBuilder httpProtocol = http
        .baseUrl("https://staging.example.internal")
        .acceptHeader("application/json")
        .contentTypeHeader("application/json")
        .shareConnections();

    FeederBuilder<String> accounts = csv("accounts.csv").random();

    ScenarioBuilder createPayment = scenario("Create payment")
        .feed(accounts)
        .exec(
            http("createPayment")
                .post("/api/payments")
                .body(StringBody("""
                    {"accountId":"#{accountId}","amount":250000,"currency":"IRR"}
                    """))
                .check(status().is(201))
                .check(jsonPath("$.paymentId").saveAs("paymentId"))
        )
        .pause(Duration.ofSeconds(1), Duration.ofSeconds(3))   // think time
        .exec(
            http("getPayment")
                .get("/api/payments/#{paymentId}")
                .check(status().is(200))
        );

    {
        setUp(
            createPayment.injectOpen(          // open model: arrival rate
                nothingFor(Duration.ofSeconds(5)),
                rampUsersPerSec(10).to(200).during(Duration.ofMinutes(3)),
                constantUsersPerSec(200).during(Duration.ofMinutes(10))
            )
        )
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile3().lt(800),   // p95 by default
            global().failedRequests().percent().lt(1.0),
            details("createPayment").responseTime().percentile(99.0).lt(2000)
        );
    }
}

# run with the Maven plugin (io.gatling:gatling-maven-plugin)
mvn gatling:test -Dgatling.simulationClass=simulations.PaymentSimulation

# HTML report at target/gatling/<simulation>-<timestamp>/index.html

Open versus closed model in Gatling — injectOpen(...) is the open model: rampUsersPerSec/constantUsersPerSec control the arrival rate. injectClosed(...) is the closed model: constantConcurrentUsers/rampConcurrentUsers hold the number of concurrent users fixed. For public APIs open is almost always right; keep closed for systems with a bounded user population or when simulating a fixed worker pool.

JMeter — protocol breadth and non-GUI execution

JMeter's stable release is 5.6.3 and it requires Java 8+ (Java 17+ recommended). The golden rule: the GUI is for building and debugging the test only; real runs are always non-GUI.

# non-GUI run plus HTML dashboard generation
jmeter -n -t payments.jmx -l results.jtl -e -o report/

# override parameters from the command line (read in the .jmx via ${__P(threads,50)})
jmeter -n -t payments.jmx -Jthreads=200 -Jrampup=120 -Jduration=600 \
       -l results.jtl -e -o report/

# distributed run: the controller drives several server machines
jmeter -n -t payments.jmx -R 10.0.0.11,10.0.0.12 -l results.jtl

# generate the dashboard from an existing results file
jmeter -g results.jtl -o report/

Three JMeter settings everybody gets wrong — (1) Running the GUI for a real test — the GUI consumes resources itself and distorts the results. (2) Leaving graphical listeners ("View Results Tree") in the executed plan — they hold every response in memory and will OOM a long run; remove or disable them for non-GUI execution. (3) Ignoring the default heap — for high load you must raise HEAP in the launcher script, otherwise the real bottleneck becomes JMeter's own garbage collector rather than the system under test.

8.6 Reading the results

Four families of numbers, and the order in which to look at them:

1. Throughput — the actual completion rate (req/s). If actual is below target, either the load generator ran out of steam or the system is saturated.
2. Latency — p50 for "the usual feel", p95/p99 for "the common worst experience", max for "what went wrong". Always look at a histogram or a time series, not a single number.
3. Error rate — and the breakdown by error type: a 503 (capacity rejection), a client timeout and a 500 (a bug) are worlds apart.
4. Saturation — resources: CPU, memory, thread-pool queue, connection-pool occupancy, disk IO, bandwidth. Here USE (utilisation, saturation, errors) for resources and RED (rate, errors, duration) for services are the standard frameworks.

The pattern to recognise: up to a point, more load means more throughput and roughly flat latency. Past the knee of the curve, throughput flattens while latency rises exponentially — that means queueing has begun. If throughput actually falls past the knee, the system is collapsing (thrashing, continuous GC, timeout-and-retry storms).

Part 9 — Security testing: the minimum expected from a backend engineer

Vulnerability detail belongs to the application-security and OWASP chapter; here we only place each tool in the lifecycle, because that is what interviews probe.

Diagram: where each security test type sits in the pipeline — نمودار: جای هر نوع تست امنیت در خط لوله.

flowchart LR
  DEV[Commit] --> SEC1[Secret scan + SAST]
  SEC1 --> BUILD[Build]
  BUILD --> SCA[Dependency / SCA scan]
  SCA --> IMG[Container image scan]
  IMG --> DEPLOY[Deploy to staging]
  DEPLOY --> DAST[DAST baseline scan]
  DAST --> PROD[Production]
  PROD -.periodic.-> PEN[Penetration test]

# SCA of Maven dependencies with OWASP Dependency-Check
mvn org.owasp:dependency-check-maven:12.1.3:check \
    -DfailBuildOnCVSS=7 -Dformats=HTML,SARIF

# image and filesystem scanning with Trivy
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:3.4.0
trivy fs --scanners vuln,secret,misconfig .

# a DAST baseline scan with OWASP ZAP (containerised)
docker run --rm -v "$(pwd)":/zap/wrk/:rw \
  ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t https://staging.example.internal -r zap-report.html

Failing the build on every CVE teaches the team to bypass the gate — If every CVE above CVSS 7 turns the build red, within two weeks somebody adds a flag that skips the scan and your security posture becomes zero. A workable policy: CVEs exploitable through a real code path fail the build; everything else is filed as an issue with a time-based SLA. That is why VEX (a statement that a given CVE is not exploitable in your product) and reachability analysis have become important. And the real secret: every entry in suppressions.xml must carry an expiry date and a reason, or the file turns into a landfill.

Part 10 — Accessibility and usability

Two test types backend engineers ignore and that are legally mandated in large organisations, especially in the public sector.

• Accessibility (a11y): can someone using a screen reader, no mouse, or with low vision complete the task? The reference is WCAG 2.2 with three conformance levels A/AA/AAA — the practical industry target is usually AA.
• Usability: can a user finish the task without training? Measured by testing with a handful of real users, not by team opinion.

# automated a11y scan of a page with axe (open source)
npx @axe-core/cli https://staging.example.internal --tags wcag2a,wcag2aa

Automated tools only do part of the job — Industry analyses consistently show that automated tools catch only a portion — roughly a third to a half — of WCAG issues: missing alt, low contrast, missing labels. But "is this alternative text meaningful?" and "is the focus order logical?" require human judgment. The minimum every team should do: navigate the critical forms end to end with the keyboard only. That single exercise finds more defects than a month of automated scanning.

Part 11 — TDD and BDD, honestly

11.1 The red-green-refactor loop

Diagram: the TDD cycle and the rule of each step — نمودار: چرخه‌ی TDD و قانون هر مرحله.

stateDiagram-v2
  [*] --> RED
  RED --> GREEN: write the simplest code that passes
  GREEN --> REFACTOR: tests stay green
  REFACTOR --> RED: next small behaviour
  note right of RED
    Test must fail for the RIGHT reason
  end note
  note right of REFACTOR
    Change structure, never behaviour
  end note

The rules that separate real TDD from "writing tests after the code":

1. Write the test first and confirm it fails for the right reason (not because of a compile error or a typo).
2. Write the simplest code that makes it pass, even if it is naive.
3. Refactor only while green — and add no new behaviour during the refactor step.
4. Keep the steps small; if you have been red for more than a few minutes, the step was too big.

Tests that lock in the implementation — If your tests mock every internal collaborator and verify call ordering, you have locked in structure rather than behaviour. The symptom: any refactoring — even with unchanged behaviour — breaks ten tests. That is the exact opposite of the purpose of testing. The working rule: keep mocks for external boundaries (payments, email, queues); use real objects or fakes for internal collaborators. A test should state what happened, not how.

11.2 BDD and Gherkin

BDD (behaviour-driven development) is a conversation before it is a tool: business, development and testing build concrete examples together (the "three amigos"). The Gherkin language writes those examples in a format both humans and machines can read.

# src/test/resources/features/withdrawal.feature
# language: en
Feature: Cash withdrawal limits
  As a bank customer
  I want withdrawals above my daily limit to be reviewed
  So that fraudulent transfers can be stopped

  Background:
    Given an active account "ACC-1001" with balance 50000000 IRR
    And two-factor authentication is enabled for "ACC-1001"

  Scenario: Withdrawal within the daily limit is approved immediately
    When a withdrawal of 5000000 IRR is requested from "ACC-1001"
    Then the withdrawal is approved
    And the balance of "ACC-1001" becomes 45000000 IRR

  Scenario Outline: Withdrawals above the daily limit need manual review
    When a withdrawal of <amount> IRR is requested from "ACC-1001"
    Then the withdrawal status is "<status>"

    Examples:
      | amount   | status         |
      | 20000000 | PENDING_REVIEW |
      | 20000001 | PENDING_REVIEW |
      | 19999999 | APPROVED       |

The step definitions in Java with Cucumber-JVM:

package com.example.acceptance;

import io.cucumber.java.en.Given;
import io.cucumber.java.en.When;
import io.cucumber.java.en.Then;
import static org.assertj.core.api.Assertions.assertThat;

public class WithdrawalSteps {

    private final WithdrawalService service;   // injected via cucumber-spring
    private WithdrawalResult result;

    public WithdrawalSteps(WithdrawalService service) { this.service = service; }

    @Given("an active account {string} with balance {long} IRR")
    public void anActiveAccount(String accountId, long balance) {
        service.createAccount(accountId, balance);
    }

    @Given("two-factor authentication is enabled for {string}")
    public void mfaEnabled(String accountId) {
        service.enableMfa(accountId);
    }

    @When("a withdrawal of {long} IRR is requested from {string}")
    public void requestWithdrawal(long amount, String accountId) {
        result = service.withdraw(accountId, amount);
    }

    @Then("the withdrawal status is {string}")
    public void statusIs(String expected) {
        assertThat(result.status().name()).isEqualTo(expected);
    }
}

package com.example.acceptance;

import org.junit.platform.suite.api.ConfigurationParameter;
import org.junit.platform.suite.api.IncludeEngines;
import org.junit.platform.suite.api.SelectClasspathResource;
import org.junit.platform.suite.api.Suite;

import static io.cucumber.junit.platform.engine.Constants.GLUE_PROPERTY_NAME;
import static io.cucumber.junit.platform.engine.Constants.PLUGIN_PROPERTY_NAME;

@Suite
@IncludeEngines("cucumber")
@SelectClasspathResource("features")
@ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = "com.example.acceptance")
@ConfigurationParameter(key = PLUGIN_PROPERTY_NAME,
                        value = "pretty, html:target/cucumber-report.html")
class RunAcceptanceTest { }

<dependency>
  <groupId>io.cucumber</groupId>
  <artifactId>cucumber-java</artifactId>
  <version>7.22.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>io.cucumber</groupId>
  <artifactId>cucumber-junit-platform-engine</artifactId>
  <version>7.22.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.junit.platform</groupId>
  <artifactId>junit-platform-suite</artifactId>
  <scope>test</scope>
</dependency>

Pay Cucumber's cost only when there is a buyer for it — Cucumber adds a layer of indirection: between the feature file and the code there is a regex mapping to maintain. That cost is worth paying only when somebody other than developers actually reads or writes those feature files. If the engineering team is the only reader, the same test in plain JUnit and AssertJ is more readable, faster and easier to debug. The senior-level interview answer is exactly this: "I use BDD as a conversation technique always; I use Cucumber only when there is a real non-technical audience."

Living documentation means publishing the output of those same scenario runs (the HTML report) as the official description of system behaviour. Its advantage is that it can never go stale: if behaviour changes and the document is not updated, the test goes red. It is the only kind of documentation that keeps itself honest.

Part 12 — How to talk about testing in an interview

Three common mistakes: (1) listing tool names instead of explaining decisions; (2) claiming "always TDD", which collapses under one follow-up question; (3) having no numbers at all.

The framework that works when you are asked "how would you test X?":

1. Risk — what causes the most damage if it breaks? Start there.
2. Level — which layer gives the cheapest answer.
3. Technique — name them: equivalence partitioning, boundary values, decision table, state transition.
4. Data and environment — where the data comes from, how external services are doubled.
5. Pass criterion — when you declare it done.
6. What you deliberately do not test — and why that risk is acceptable.

The numbers a senior brings to a quality conversation (siblings of the DORA metrics): escaped defect rate (bugs that reached production), change failure rate, time to restore (MTTR), pipeline duration, flakiness rate, and P1 requirement coverage. If you can say "the pipeline went from 40 minutes to 9, and escaped defects halved in three months", nobody needs further convincing that you understand testing.

Part 13 — A checklist for judging a test suite

On your first day in a new codebase, check these. The answers reveal the team's engineering health better than any document:

Command cheat sheet