Software Testing Techniques Guides
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.
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; a research repository cited the magazine for a study on exactly that comparison. 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.
All 7 guides in this hub
| # | Guide | What it settles | Level | Reading |
|---|---|---|---|---|
| 1 | Black box vs white box testing: what each finds and misses | Black-box testing judges the software from outside, against what it is supposed to do. | Foundation | 8 min |
| 2 | Equivalence partitioning and boundary values: worked example | An age field that accepts 18 to 65 has, in principle, billions of possible inputs. | Foundation | 8 min |
| 3 | Security testing: types, OSSTMM and where it fits in delivery | Security testing is not one activity but five, run at different points of the lifecycle by different people, and a penetration test is only the last and most expensive of them. | Practitioner | 7 min |
| 4 | Performance testing: types, workload models and p95 results | Most performance tests fail before they run, because the workload does not resemble production and the pass criterion is an average. | Practitioner | 7 min |
| 5 | Software testing metrics: 12 formulas and what each hides | Every testing metric answers one question and hides another. | Lead | 7 min |
| 6 | Mobile app testing: device matrix, checklist and strategy | Mobile testing fails in the gaps between devices, networks and interruptions, not in the happy path on the flagship phone the developer owns. | Practitioner | 8 min |
| 7 | Test coverage: four kinds and why 80 percent tells you little | Coverage is the most quoted and least understood number in testing. | Practitioner | 8 min |
Where to start, by the question you have
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 and recovers an application security PDF the old site hosted. 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.