Software Testing Techniques: Types With Worked Examples

What Are Software Testing Techniques?

In the words of the ISTQB syllabus, test techniques "support the tester in test analysis (what to test) and in test design (how to test)." A technique turns a requirement or a piece of code into a small set of test cases with a stated coverage target, such as one test per partition or both outcomes of every decision.

Each of these related terms answers a different question:

For the other axes, see the guides to types of software testing, testing methodologies, and software testing strategies. A technique works at any level: boundary value analysis applies to a unit test of one validation function and to an acceptance test of a whole signup form.

The first of the seven principles of software testing explains why the choice matters: testing shows the presence of defects, not their absence, so the cases you pick decide which defects you can find. Dynamic testing runs the software, and the static techniques in the next section examine it without running it.

The Manual Testing certification covers test design techniques such as boundary value analysis and equivalence partitioning, along with the SDLC, the STLC, and the defect lifecycle.

Static Testing Techniques

Static testing finds defects in requirements, designs, and code without executing them, through manual reviews or tool-based static analysis. A review can start on the first draft of a requirement, and an analyzer can run on every pull request.

Black-Box Testing Techniques

Black-box testing techniques, also called specification-based techniques, design tests from what the system is supposed to do and treat its code as unseen. On the registration form, the error messages act as the specification:

• First Name must be between 1 and 32 characters.
• Telephone must be between 3 and 32 characters, with the field hint "Enter valid phone number with country code!"
• Password must be between 4 and 20 characters.
• The Privacy Policy must be accepted before an account is created.

White-Box Testing Techniques

White-box testing techniques, also called structure-based techniques, design tests from the code's structure and measure code coverage: the share of a structural element that the tests exercise. Every coverage formula has the same shape, coverage = (items exercised / total items) × 100, whether the items are statements, decisions, or condition combinations. The guide to black-box vs white-box testing compares the two families side by side.

Statement, Decision, and Condition Coverage

This function waives shipping for members or for orders over 50:

function shippingFee(isMember, total) {
  let fee = 5;
  if (isMember || total > 50) {
    fee = 0;
  }
  return fee;
}

A suite that only calls shippingFee(true, 20) executes all 4 executable statements, which is full statement coverage. The if statement never takes its false outcome, so decision coverage reaches only one of two outcomes, and ISTQB branch coverage, which also counts unconditional branches, stays incomplete because the branch from the if straight to return fee never runs. That is why the ISTQB syllabus notes that full statement coverage does not ensure that all the decision logic has been tested.

With both conditions, isMember and total > 50, always evaluated, the stronger criteria need these tests:

Criterion	Coverage items	Minimum tests	Example inputs (isMember, total)
Statement	Executable statements	1	(true, 20)
Decision	True and false outcome of each decision	2	(true, 20), (false, 20)
Condition	True and false value of each condition	2	(true, 20), (false, 60)
MC/DC	Each condition shown to change the outcome on its own	3 (usually n + 1)	(false, 20), (true, 20), (false, 60)
Multiple condition	Every combination of condition values	4 (2n)	All four true and false combinations

The condition-coverage pair makes the decision true both times, so condition coverage alone does not guarantee decision coverage. Modified condition/decision coverage (MC/DC) closes that gap, usually with n + 1 tests for n conditions, while multiple condition coverage needs up to 2ⁿ combinations.

Those counts assume both conditions are always evaluated. JavaScript, Java, and C short-circuit ||, so total > 50 never runs when isMember is true; condition coverage then needs a third test, (false, 20), and only three of the four multiple-condition combinations can be observed.

Google's code coverage guidance treats 60% as acceptable, 75% as commendable, and 90% as exemplary. The same post calls project-wide goals above 90% most likely not worth it, while per-commit goals of 99% are reasonable.

Mutation testing checks whether the assertions would notice a bug in the code that ran: it injects small faults, such as flipping || to && in shippingFee, and counts how many the suite catches.

Coverage also applies to black-box suites. In this Testμ 2024 session, Kulas Angeles, Director of Software Quality Engineering at Sun Life Financial, shows how to measure code coverage for black-box tests:

Experience-Based Testing Techniques

Experience-based techniques draw on the tester's knowledge of past defects, the domain, and how users behave. The ISTQB syllabus groups the following techniques in this family:

• Error guessing - Anticipating likely mistakes, such as empty input, leading spaces, letters in a numeric field, or a double-clicked submit button, and testing them directly. The syllabus describes fault attacks as one way to implement it: build a list of possible errors, then design a test for each.
• Exploratory testing - Designing, executing, and evaluating tests at the same time while learning the product, often in time-boxed sessions guided by a test charter.
• Checklist-based testing - Working through a list of test conditions built from experience, standards, or past defects. For a form, the list might cover trimming, maximum length, pasted input, and browser autofill.

In a wider Chrome run against the same form, the browser's built-in email validation blocked an address without an @ sign before the request reached the server, so a tester working in Chrome never sees the server's own email check for that input.

TestMu AI's Real-Time Testing gives interactive access to 3,000+ browser, OS, and resolution combinations for exploratory sessions, and it lets you switch browser or OS mid-session to compare how each one handles the same input. When a session turns up a defect, Mark as Bug files it to the tracker with the browser, OS, URL, and a link to the session recording attached.

Grey-Box Testing

Grey-box testing combines elements of black-box and white-box testing, as the ISTQB glossary defines it. Testers design black-box cases with partial knowledge of internals such as the database schema, API contracts, or architecture.

Database testing is a typical case. A tester registers a user through the UI, which is black-box, and then queries the customer table to confirm the stored row, for example that the email was saved as entered and the password was stored as a hash rather than plain text.

The same partial knowledge shapes API testing and regression suites, where schemas and contracts point testers at the fields most likely to break.

How to Run Technique-Derived Tests

Every technique above can be executed by hand or automated. Manual testing means people execute the tests without automated scripts, which suits exploratory sessions and usability judgments. Automation testing means scripts execute and check the tests, which suits the repeatable tables that partitioning and BVA produce.

The script below turns the registration form's boundary and partition cases into one data-driven Playwright test. Each row changes one field (password rows also copy the value into Password Confirm), and the expected result follows the form's error message, or its field hint for letters in the telephone field.

// bva-registration.mjs: boundary value analysis and equivalence partitioning
// on the TestMu AI ecommerce playground registration form
import { chromium } from "playwright";

const capabilities = {
  browserName: "Chrome",
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 11",
    build: "Testing Techniques - BVA and ECP",
    name: "Registration form boundaries",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
    network: true,
    console: true,
    video: true,
  },
};

const FORM = "https://ecommerce-playground.lambdatest.io/index.php?route=account/register";
const valid = {
  firstname: "Ann", lastname: "Tester", email: `bva-${Date.now()}@example.com`,
  telephone: "+14155550123", password: "Passw0rd", confirm: "Passw0rd",
};
const chars = (n) => "a".repeat(n);

// One field changes per case (password rows also copy the value into confirm).
// "expected" follows the form's error message, or its field hint for TEL-ABC.
// The Privacy Policy box is never ticked, so the server never creates an account.
const cases = [
  ["FN-0", "firstname", "", "reject"],
  ["FN-1", "firstname", chars(1), "accept"],
  ["FN-32", "firstname", chars(32), "accept"],
  ["FN-33", "firstname", chars(33), "reject"],
  ["PW-3", "password", chars(3), "reject"],
  ["PW-4", "password", chars(4), "accept"],
  ["PW-20", "password", chars(20), "accept"],
  ["PW-21", "password", chars(21), "reject"],
  ["PW-40", "password", chars(40), "reject"],
  ["PW-41", "password", chars(41), "reject"],
  ["TEL-2", "telephone", "12", "reject"],
  ["TEL-3", "telephone", "123", "accept"],
  ["TEL-33", "telephone", "1".repeat(33), "reject"],
  ["TEL-ABC", "telephone", "abcdefgh", "reject"],
];

const browser = await chromium.connect(
  `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(JSON.stringify(capabilities))}`
);
const page = await browser.newPage();
let failures = 0;

try {
  for (const [id, field, value, expected] of cases) {
    const data = { ...valid, [field]: value };
    if (field === "password") data.confirm = value;

    await page.goto(FORM);
    for (const [name, v] of Object.entries(data)) await page.fill(`#input-${name}`, v);
    await page.click("#content form input[type=submit]");
    // Every submit returns the Privacy Policy warning (the box is never ticked), so the
    // warning marks the server's response page; then wait for that page to finish parsing.
    await page.locator(".alert-danger", { hasText: "Privacy Policy" }).waitFor();
    await page.waitForLoadState("domcontentloaded");

    const message = await page.evaluate(
      (f) => document.querySelector(`#input-${f}`).parentElement.querySelector(".text-danger")?.textContent.trim() ?? "",
      field
    );
    const actual = message ? "reject" : "accept";
    const verdict = actual === expected ? "PASS" : "FAIL";
    if (verdict === "FAIL") failures++;
    console.log(`${id.padEnd(8)} length=${String(value.length).padEnd(3)} expected=${expected} actual=${actual}  ${verdict}  ${message}`);
  }

  await page.evaluate(() => {}, `lambdatest_action: ${JSON.stringify({
    action: "setTestStatus",
    arguments: { status: failures ? "failed" : "passed", remark: `${failures} boundary mismatches` },
  })}`);
  console.log(`\n${cases.length - failures} passed, ${failures} failed`);
} finally {
  await browser.close();
}

Set LT_USERNAME and LT_ACCESS_KEY to your account credentials, then run it:

npm install playwright

# macOS or Linux
LT_USERNAME=<your-username> LT_ACCESS_KEY=<your-access-key> node bva-registration.mjs

# Windows PowerShell
$env:LT_USERNAME="<your-username>"; $env:LT_ACCESS_KEY="<your-access-key>"; node bva-registration.mjs

This is the console output from the run on September 25, 2026, on Chrome on Windows 11:

FN-0     length=0   expected=reject actual=reject  PASS  First Name must be between 1 and 32 characters!
FN-1     length=1   expected=accept actual=accept  PASS
FN-32    length=32  expected=accept actual=accept  PASS
FN-33    length=33  expected=reject actual=reject  PASS  First Name must be between 1 and 32 characters!
PW-3     length=3   expected=reject actual=reject  PASS  Password must be between 4 and 20 characters!
PW-4     length=4   expected=accept actual=accept  PASS
PW-20    length=20  expected=accept actual=accept  PASS
PW-21    length=21  expected=reject actual=accept  FAIL
PW-40    length=40  expected=reject actual=accept  FAIL
PW-41    length=41  expected=reject actual=reject  PASS  Password must be between 4 and 20 characters!
TEL-2    length=2   expected=reject actual=reject  PASS  Telephone must be between 3 and 32 characters!
TEL-3    length=3   expected=accept actual=accept  PASS
TEL-33   length=33  expected=reject actual=reject  PASS  Telephone must be between 3 and 32 characters!
TEL-ABC  length=8   expected=reject actual=accept  FAIL

11 passed, 3 failed

The three failures are two defects. PW-21 and PW-40 trace to the upstream OpenCart 3.0.3.8 register controller, which sets the password's upper limit at 40 characters while the language file's message says 20. TEL-ABC is the letters-in-telephone defect from the equivalence partitioning section.

Pointing the script at the cloud took only a connection string and a capabilities object. On TestMu AI's Automation Cloud, a larger case table can be sharded across parallel sessions, and the network, console, and video flags in the capabilities above attach network logs, console logs, and a video recording to each session for debugging a failed case.

Note: To run the script against your own form on localhost or a staging host, start LT Tunnel and set the tunnel capability in LT:Options so the cloud session can reach it. Create a free account to get the username and access key the script reads. Sign up free

What Is the Difference Between Functional and Non-Functional Testing Techniques?

Functional testing checks what a feature does against its requirement, such as whether the registration form rejects a 21-character password, while non-functional testing checks what the ISTQB syllabus calls "how well the system behaves," such as response time under load. Both are test types from the table at the top of this guide, and the techniques above design the test cases for either.

Functional testing is where black-box techniques do most of their work: every table in the black-box section is a functional test design.

Non-functional testing checks quality characteristics other than functionality, such as performance, compatibility, security, and usability, and the same techniques carry over:

• Performance testing - For a stated capacity of 500 concurrent users, boundary value analysis says to run at 500 users, where response times must still meet the target, and at 501, where the system should show its specified over-capacity behavior, such as queuing requests or returning a clear error, instead of failing.
• Security testing - Error guessing and checklist-based testing supply the inputs: injection strings, script tags, and overlong values sent to every field the form accepts.
• Compatibility testing - Group browsers by rendering engine (Blink, Gecko, WebKit) as equivalence partitions, test one version from each, and use pairwise testing to combine browser, OS, and screen resolution.
• Usability testing - Exploratory sessions with a charter such as "register using only the keyboard" test the flow the way a real user meets it.

How to Choose the Right Software Testing Technique

Start from the kind of defect you most need to catch, then pick the technique built for it:

• Risk - Spend the most techniques on the features where failure costs the most; risk-based testing ranks features by likelihood and impact.
• Test level - White-box coverage fits unit and component tests, where the code is at hand; black-box techniques fit system and acceptance tests, where the specification is the reference.
• Timing - Reviews and static analysis can run before any code executes, which is the core of shift-left testing.

Technique tables turn into dozens of cases quickly, and TestMu AI's Test Manager keeps each one tied to its requirement by linking requirements, test cases, runs, and defects in one traceability matrix. It also generates structured test cases, with steps, expected results, preconditions, and priority, from a user story or requirement document, and can add edge cases and negative scenarios to an existing case. The guide to generating test cases with AI walks through the workflow.

Conclusion

Pick the input field in your product that collects the most bug reports, apply the software testing techniques above to list its partitions and boundary values, and script one test for each. Run that script on TestMu AI's Automation Cloud by following the Playwright testing guide.