Testing Techniques
The techniques themselves: how to design cases that find defects with the fewest tests, how to test security, performance and mobile behaviour, and how to measure what the testing achieved. Seven guides, each with a worked example.
7 guidesUpdated Editorial method
About testing techniques
Technique is what separates testing from clicking around. A tester who knows equivalence partitioning designs eleven cases where a colleague guesses forty and misses the boundary; one who knows the difference between a load test and a stress test asks for the right environment; one who can read a coverage report knows that 80 percent tells you almost nothing on its own. The guides here teach the classical design techniques and the specialist types (security, performance, mobile) at a level that a working tester can apply the same week, with tables and figures built to be copied into a test plan or a slide.
Black box vs white box testing compares the two approaches on what each finds and misses, with an illustrative cost-effectiveness table. Equivalence partitioning and boundary value analysis is a step-by-step how-to with a worked age-field example and the arithmetic that shows why the technique produces fewer, better cases. Test coverage distinguishes requirements, risk, code and model coverage and explains what a percentage means for each.
Security testing covers the five main types, the OSSTMM and the OWASP Top Ten as vocabularies, and where each activity sits in a pipeline; it continues the security theme of the magazine's issue 6. Performance testing explains the test types, workload modelling from production data, and why the 95th percentile matters more than the mean. Mobile app testing designs a device matrix, covers interruptions, networks, permissions and store checks, and continues the theme of the final issue. Software testing metrics gives twelve metrics with formulas, what each hides, and how to pick five for a dashboard.
Three situations decide where to start. If a plan is due this week, design the cases with the partition-then-boundary procedure, state what the plan covers in the terms of requirements, risk and code coverage so that the number means something, and set the depth per feature with the risk scoring in the management hub. If the build is red and nobody trusts it, the black box and white box comparison tells you which view will locate the failure faster, the defect trend metrics tell you whether the failures are new or old, and if the failures are timing-related the load and stress definitions in the performance guide separate a slow environment from a slow product. If an audit is coming, the OWASP and OSSTMM vocabularies are what the assessor will expect the security testing to be organised by, and the twelve metrics with formulas in the metrics guide are the ones a dashboard will be checked against.
Every guide in this hub cites its sources by name (Copeland, Myers, Meszaros, the ISTQB syllabi, ISO/IEC 25010, the OWASP and ISECOM methodologies) and links the glossary for terms. Where a technique depends on a management decision (how deep to test a feature) the guide points to risk-based testing rather than repeating it.
The same techniques carry over to AI components. A detector or classifier is judged with a confusion matrix and confidence intervals, and its evaluation slices are chosen by partitioning; the Testing AI Systems hub covers benchmarking an AI text detector, false positives and base rates and reviewing machine-written tests and code.
The newer authenticity guides in that hub lean on the techniques here even more directly. Disclosure label test cases are built by equivalence partitioning: origin (declared, signed, inferred) by medium by edit state gives the partitions, one expected result per partition gives the cases, and the crop and re-encode boundaries are where labels go missing. Evaluation set slices are coverage items in the sense of the coverage guide: a detector benchmark that reports one overall rate has the same problem as a suite that reports 80 percent statement coverage. Confidence intervals for classifier metrics is the metrics guide's rule that no number is reported without what it hides, applied to rates measured on a few hundred cases. And verifying content credentials is security testing in miniature: a signature, a certificate chain and a trust list, checked the way a penetration tester checks a TLS configuration; metadata survival testing is the black-box view of the same pipeline. The technique reader will find the same partitioning discipline in recording the lineage of every item in an evaluation set and in a deepfake detection protocol that reports recall per manipulation family.
All guides
Nothing matches. Clear the filter to see every entry.
Questions
Which technique should I learn first?
Equivalence partitioning with boundary value analysis. Split an input into classes where every value should behave the same, test one representative per class, then add the values at each edge, where off-by-one errors live. For an age field accepting 18 to 65 that gives about 11 tests.
What is the difference between black-box and white-box testing?
Black-box testing derives tests from requirements and observed behaviour without reading the code, and finds missing and wrong features. White-box testing derives them from code structure and finds untested logic and dead paths. Most teams use black box at system and acceptance levels, white box at unit and integration levels.
Is 80 percent code coverage good enough?
The number says little on its own: 80 percent of lines executed says nothing about what was checked. Coverage comes in four kinds, requirements, risk, code and model, and the coverage guide treats it as a gap-finder rather than a target, with advice on reporting it to non-testers.
Why judge performance by the 95th percentile rather than the average?
Because averages mislead. The performance guide judges results by p95 and p99 rather than the mean, builds the workload from production data and tests on production-sized capacity. Load tests check expected traffic, stress tests find the breaking point and soak tests run for hours to expose leaks.
