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.
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.
Logic: if (age >= 18 && hasID) { allow(); } else { block(); }
How many tests are needed for 100% Statement coverage?
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).
Scenario: An icon-only "Search" button with no aria-label or title.
What will a screen reader announce?
- 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
| Technique | ISTQB reference |
|---|---|
| Statement & branch coverage | CTFL 4.3 / CTAL-TA 3.3 |
| Advanced black box (EP, BVA, decision tables) | CTAL-TA 3.2 |
| Advanced exploratory & checklists | CTAL-TA 3.4 |
| Risk-based testing | CTAL-TA 2.3 |
| Accessibility / quality characteristics | CTAL-TA Ch. 4 |
| Defect classification & root cause analysis | CTAL-TA Ch. 6 |