Test lead techniques

1. Writing a test strategy

A test strategy defines how testing will be done across a project or programme. It answers: what will we test, what won’t we test, how, with what tools, in what environments, with what data, who is responsible, and what does done look like?

A good strategy can be challenged. If it can’t be challenged, it’s not specific enough.

Structure: scope → approach → levels & types → tools → environments → entry/exit criteria → risks → assumptions.

2. Risk management

Risk = Likelihood × Impact. Sort descending. Highest risk gets first, deepest, most frequent testing.

Full risk-based testing reference →

3. Test planning

A test plan covers: objectives, scope, approach, schedule, resources, entry criteria, exit criteria, and risk. It’s a contract between testing and the project.

Key decisions in every plan:

• What test levels are needed? (unit, integration, system, acceptance)
• What test types? (functional, performance, security, regression)
• What’s in and out of scope — and who agreed to the scope?
• What are the exit criteria? (not "all tests pass" — "all Critical and High defects resolved, regression complete, sign-off from product owner")

4. Test estimation

Own your estimate — never accept someone else’s. Break work into tasks (WBS), estimate each task (use three-point for uncertain items), add contingency for defect volume and environment instability.

Track actuals against estimates every sprint. Use the data to improve future estimates. A team that tracks actuals becomes progressively better at planning.

Full test estimation reference →

5. Security testing basics

Not a security engineer — but every lead needs to test these:

• SQL injection — try ' OR '1'='1 and '; DROP TABLE users;-- in login and search fields.
• XSS — try <script>alert(1)</script> and <img src=x onerror=alert(1)> in text inputs stored and displayed back.
• IDOR — change IDs in URLs (user/123 → user/124). Can you see other users’ data?

• Auth bypass — sensitive data or tokens in query strings? Are admin endpoints protected?
• Information disclosure — do error messages expose stack traces, DB names, or internal paths?

6. API testing

For each endpoint: send valid data (expect 2xx), send invalid data (expect 4xx with field-level errors), send no auth (expect 401), send wrong role (expect 403), send missing required fields (expect 400). Check response schemas match contracts.

Automate API tests in CI — they’re fast, stable, and provide the first signal that something has regressed.

7. Data integrity checks

Business logic bugs often manifest as data errors, not UI errors. Check:

• Totals — sum line items vs order total. Match?
• Counts — row count in DB vs displayed count. Match?
• References — do foreign keys point to real records?
• Soft deletes — do deleted records appear in reports or search results where they shouldn’t?
• Concurrent writes — two users updating the same record: does the last write win, or is the first write silently discarded?

8. Metrics & reporting

Metrics tell you whether testing is working. Report to stakeholders weekly at minimum:

• Test execution rate — % of planned tests run
• Pass rate — % of executed tests passing
• Defect escape rate — bugs found in prod / (bugs found in test + prod)
• Defect closure rate — are bugs being fixed faster than they’re being found?
• Blocked / at-risk tests — what can’t you test and why?

Don’t just report numbers — interpret them. "85% pass rate" is meaningless without context. "85% pass rate with 3 Critical open defects and release in 2 days" is actionable.

9. Coaching & leadership

When reviewing a junior’s bug report, look for: reproducibility, specificity, completeness, and severity accuracy. Don’t just fix the report — explain why.

Build your team’s skill by pairing on testing sessions, reviewing test cases before execution, and running retrospectives on escaped defects. The best leads make their team better faster than they could make the product better themselves.

10. Coverage analysis

Map requirements/acceptance criteria to tests. Identify gaps: uncovered requirements, requirements with no negative tests, requirements tested only at happy path. Document gaps explicitly — "we are not testing X, because Y."

Goal: deliberate coverage with known, justified gaps — not accidental gaps discovered after release.

11. AI Governance & Quality Strategy

As AI agents and LLMs are integrated into products, Test Leads must define the quality strategy for non-deterministic systems:

• Model Monitoring — How do we detect when an AI's performance drifts over time?
• Safety Gates — What automated checks ensure the AI doesn't hallucinate or violate brand guidelines?
• Bias Testing — How do we systematically check for demographic bias in AI outputs?

12. Shift-Smart Continuous Quality

Shift-Left (testing early) is not enough. Leads must implement Shift-Smart: performing the right checks at the right time.

• Quality Observability — Using production data (logs/traces) to inform what we test in lower environments.
• Risk-Adjusted Pipelines — Running only the most relevant tests for a given code change to speed up the feedback loop.

13. Māori Data Sovereignty in Testing

For NZ-based projects, Leads must ensure testing practices respect Māori Data Sovereignty:

• Culturally Safe Testing — Ensuring test data used in automation and manual testing is respectful and accurate.
• Data Governance — Verifying that data involving Māori individuals or resources is handled according to the principles of Te Tiriti o Waitangi.

ISTQB CTAL-TM mapping