Level 3 · Senior Techniques

Senior techniques

Context is everything. The same feature behaves differently on mobile, in Safari, with a screen reader, after a timeout. At senior level you think in systems — and you start contributing to test strategy.

Senior ISTQB CTAL-TA v4.0

1. Coverage-based testing

At senior level you work directly with developers and understand the code. Use coverage metrics to identify untested paths — not as a target to game, but as a tool to find gaps.

A team that reports 80% branch coverage with known untested areas is more mature than one that reports 100% statement coverage without knowing what they’ve missed.

Mini-Hunt: Logic Branching

Logic: if (age >= 18 && hasID) { allow(); } else { block(); }

How many tests are needed for 100% Statement coverage?

Answer: Two. One to hit allow() and one to hit block(). Statement coverage only cares that every line is executed at least once!

Statement coverage reference →  |  Branch coverage reference →

2. Advanced exploratory testing

At senior level, exploratory testing is deliberate and charter-driven. You write charters, time-box sessions, and report findings formally.

Senior-level charters go beyond the happy path: "Explore the payment flow under network degradation using throttled 3G to discover how the system handles slow or failed responses."

Use Session-Based Test Management (SBTM): charter + time box + session sheet. This makes exploratory work visible and auditable.

Full exploratory testing reference →

3. Accessibility testing

Accessibility is a quality attribute, not a nice-to-have. Test against WCAG 2.1 AA as the baseline:

  • Keyboard navigation — put the mouse away. Tab through the entire page. Every interactive element must be reachable, focusable, and activatable. Focus must always be visible.
  • Screen reader — test with NVDA (Windows, free) or VoiceOver (Mac). Can you complete core tasks without sight?
  • Colour contrast — use DevTools Accessibility panel or the WAVE extension. Target: 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold).
Mini-Hunt: Accessibility Gap

Scenario: An icon-only "Search" button with no aria-label or title.

What will a screen reader announce?

Answer: "Button" (or nothing). Without a label, the user has no idea what the button does. This is a critical blocker for visually impaired users.
  • Zoom to 200% — does the layout break? Is any content inaccessible?

4. Responsive & cross-browser testing

  • Test at key breakpoints: 375px (iPhone SE), 390px (iPhone 14), 768px (iPad), 1280px, 1440px.
  • Check for: horizontal scroll, overlapping elements, text overflow, truncated buttons, touch targets < 44px.
  • Cross-browser smoke: Chrome, Firefox, Safari, Edge. Focus on: CSS rendering (flexbox/grid), form element styling, font loading, JavaScript compatibility.
  • Test with both light and dark OS themes if the app supports them.

5. Session & auth testing

Security-relevant scenarios that junior testers often miss:

  • Session expires mid-task — does the user lose their work? Are they redirected to login and returned to the original page afterward?
  • Same account open in two tabs — does a logout in one tab affect the other?
  • Bookmarked logged-in URL accessed after logout — what happens?
  • Low-privilege user manually navigates to high-privilege URL — are they blocked?
  • JWT tokens — do they expire? Are they refreshed correctly?

6. Error recovery testing

Cause errors deliberately, then test the recovery path:

  • Throttle the network (DevTools → Network) and submit a form. What happens at slow connection?
  • Go offline mid-form — is the user’s data lost?
  • Force a 500 error (if you can) — does the app recover gracefully or stay broken?
  • Refresh mid-process — is there orphaned state? Partial records?

7. Risk-based prioritisation

As a senior tester you start contributing to test planning. Build a simple risk matrix: for each feature area, rate likelihood of defect (1–5) and impact if defective (1–5). Multiply for risk exposure. Focus depth of testing proportionally to risk.

Full risk-based testing reference →

8. Defect analysis

At senior level you don’t just log bugs — you analyse them. For recurring or high-severity defects:

  • What triggered it? (5 Whys, root cause analysis)
  • Why wasn’t it caught earlier? (test gap analysis)
  • What test should we add to prevent recurrence?
  • Is this a class of bug that affects other areas?

Full defect management reference →

9. API Testing Foundations

Senior testers must look under the hood. Most modern apps are just UIs talking to APIs. Testing at the API layer is faster and more reliable than UI testing.

  • Status Codes — Verify 200 (OK), 201 (Created), 400 (Bad Request), 401 (Unauthorized), and 500 (Server Error) are used correctly.
  • Payload Validation — Does the JSON response match the documented schema? Are types (string vs number) consistent?
  • CRUD Operations — Test the Create, Read, Update, and Delete flow for a resource.

10. Manual Security Auditing (OWASP Top 10)

While Lead levels define security strategy, Senior testers perform the manual "smell tests" for common vulnerabilities:

  • Broken Access Control — Can User A view User B's private data by changing a ID in the URL? (IDOR)
  • Cryptographic Failures — Is sensitive data (passwords, credit cards) masked in the UI and encrypted in transit (HTTPS)?
  • Injection — Does entering ' OR 1=1 -- into a login field cause a bypass?

11. NZ Privacy Act Compliance

In New Zealand, the Privacy Act 2020 sets the rules for handling personal information. Quality Engineering includes verifying compliance:

  • Purpose Limitation — Is the app asking for more data than it actually needs?
  • Storage & Security — Is personal data stored securely? Is it deleted when no longer needed?
  • Access to Info — Can a user request all data the system holds about them?

ISTQB CTAL-TA mapping

ISTQB CTAL Test Analyst v4.0 — key chapters
TechniqueISTQB reference
Statement & branch coverageCTFL 4.3 / CTAL-TA 3.3
Advanced black box (EP, BVA, decision tables)CTAL-TA 3.2
Advanced exploratory & checklistsCTAL-TA 3.4
Risk-based testingCTAL-TA 2.3
Accessibility / quality characteristicsCTAL-TA Ch. 4
Defect classification & root cause analysisCTAL-TA Ch. 6