Test Case Design Techniques & When to Change Them

What does Test Case Design mean?

Test case design refers to the format of a test case as well as the test case content. The goal of creating test cases is to identify defects in the software application. A solid test case design strategy enables a QA testing team to provide business value by repeatedly and efficiently identifying defects before customers experience them.

Test case design requires a thoughtful approach to identify missing requirements and defects without wasting resources or time. In other words, a solid test case design strategy creates tests that are useful, concise, and re-usable over the application's lifetime. Test design techniques influence how test cases are written to provide maximum code coverage. Effective test technique and test case design combined enables QA test teams to create fewer tests that still verify and validate all application functionality.

When developing a test case design strategy, consider using some or all of the following types of test design techniques:

• Specification
• Boundary value analysis
• Equivalence partitioning
• Decision tables
• State transition
• Use case scenarios
• Structure
• Code statement
• Decision statement branches
• Condition code coverage
• Experience
• Error guessing
• Exploratory testing

The three groups above line up with the categories in the ISTQB Certified Tester Foundation Level v4.0 syllabus, currently published as document version 4.0.1, so use its wording when you write the strategy down. Specification techniques are named black-box testing techniques there, structure techniques are named white-box testing techniques, and experience techniques are named experience-based test techniques. Version 4.0 adds a fourth group, collaboration-based test approaches, which covers acceptance criteria that a business representative, a developer, and a tester agree on before the code is written. New testers arrive already knowing these terms, so matching them saves you from teaching an in-house vocabulary first.

Note: You can use TestMu AI Cloud to test on a variety of simulators, emulators and real devices. No need to install anything, just sign up for a free account and start testing. Try TestMu AI Today!

In most QA testing teams, using all test design techniques is not realistic. Consider choosing one or two that best suit the development team structure, QA resources, and the software application's needs.

For example, a test case design strategy for a mobile app that tracks patient lab results and alerts doctors when a lab result is in a negative range must be thoroughly covered.

For more thorough test coverage, use decision tables combined with use case scenarios or user story acceptance criteria and exploratory testing. The combination provides detailed input and output verification while also ensuring all requirements are met. Adding exploratory testing techniques helps to uncover defects caused by missing requirements or design features.

Define the strategy based on what works best for ensuring the application release exceeds customer expectations consistently across releases.

Key Takeaway: Test case design means choosing a test technique and a test case format together, and most QA teams get further by combining one or two techniques, such as decision tables with exploratory testing, than by attempting every available technique.

Why is Test Case Design important to Software Quality?

Test case design is important for producing high-quality software applications that satisfy customer needs and create positive user experiences. Effective test case design documents application functionality based on requirements, acceptance criteria, or expected use case scenarios. Exceptional test case design also identifies defects in design or missing requirements. For example, test cases may find a story or feature that requires more work to function properly.

Well-designed test cases also provide application feature documentation that serves as the basis for help documentation or even end-user training or documentation needs.

Other benefits of test case design include:

• Thorough code test coverage
• Reduced maintenance and documentation creation costs
• Software validation for user acceptance
• Improved customer experience
• Reduced customer support tickets for customer defects and inquiries

Key Takeaway: Test case design raises software quality because well designed test cases document application functionality, expose missing requirements, and cut the support tickets customers raise after a release.

Why is Test Case Design one part Test Technique and one part Design Format?

An exceptional test case design strategy includes both test techniques and an effective design format. Test case design format refers to how a test case design is structured. Many QA test teams use test case management tools that support several formats, and some teams keep their cases in the code repository next to the tests those cases describe.

Common test case design formats include:

• Sequential steps
• User journey stories
• Functional tours
• Feature Checklists

The format impacts the technique used when developing test cases. QA teams frequently use sequential or ordered steps that test a single functional verification point. A series of sequential steps are used to create an end-to-end or system test that verifies the functional workflow of the application.

User journey stories are test cases written in paragraphs that describe how a user steps through a function in the application. The text does not list the exact steps taken in a specific order but rather leaves the steps up to the user. User journey stories are an excellent approach for including positive and negative test scenarios in a single test case.

Functional tours are typically also written in paragraphs that describe the function to be verified. Functional tours can be based on customer workflow scenarios or simply exercise and verify separate functions within an application. Tours are excellent ways to test integration points between applications and dependent systems such as APIs and databases in an indirect fashion that simulates a real user experience.

Feature checklists are test cases formatted in the form of a list. Checklists are quick to write and can ensure all critical points are covered for each application function. One problem with checklists is they don't provide the detail necessary for user or reference documentation.

When choosing a test case design strategy, including selecting the format(s) combined with the testing technique(s) that work best for ensuring customer satisfaction and exceptional application quality.

Key Takeaway: The test case format decides what a technique can express, so sequential steps suit a single verification point, user journey stories hold positive and negative scenarios in one case, functional tours reach integration points, and feature checklists trade documentation detail for speed.

How do you design test cases when there are too many input combinations?

Use combinatorial test design. It builds a covering array, a table in which every pair of parameter values appears at least once, so the test count drops while interaction coverage holds. NIST's Automated Combinatorial Testing for Software project states the rule behind it directly: most software bugs and failures are caused by one or two parameters, with progressively fewer by three or more. NIST also reports studies where combinatorial test sets matched the fault detection of exhaustive testing with a 20X to 700X reduction in test set size.

Two generators do this work. Microsoft's PICT reads a plain text model of parameters and values and writes the cases. Its documentation covers the order option, which raises coverage from every pair to every triplet or higher, IF and THEN constraint lines that exclude combinations the system cannot produce, and value weights that tell the generator which value to prefer when coverage allows. NIST's own generator, ACTS 3.3, is public domain with no license required, and NIST reports more than 4,500 corporate and university users. NIST posts a basic ACTS build for direct download and releases the full tool only after an emailed request naming you and your organization, so allow for that step before a team standardizes on it.

Combinatorial design is not on the specification, structure, and experience list earlier in this article, and it does not replace anything on that list. A covering array proves that parameter value pairs were exercised. It proves nothing about a business rule. Keep decision tables for rules that must be checked exactly, and keep boundary value analysis for the edges of each parameter on its own.

The technique earns more attention once a coding assistant drafts the cases. A generated batch carries no coverage model, so you cannot say which parameter interactions it reached and which it skipped. Generate the covering array first, then give the assistant one row at a time and let it write the steps and the expected result for that row. The array decides what gets covered, the assistant writes it up, and the coverage stays a number you can report.

Key Takeaway: Combinatorial test design answers too many input combinations by generating a covering array with a tool such as Microsoft PICT or NIST ACTS, while decision tables and boundary value analysis still cover business rules and parameter edges.

How do AI coding assistants change test case design?

An AI coding assistant changes who writes the test case, not who decides what the test case covers. The technique still selects the cases, the assistant drafts the wording, and a reviewer keeps the judgment. Teams that let the assistant act as the designer lose the one thing a technique gives them, a coverage claim they can defend.

GitHub's guidance on writing tests with Copilot says the assistant generates unit and integration tests and handles edge cases, exception handling and data validation when the prompt is specific enough. The same page states that the tests Copilot generates may not cover all scenarios, that you should always review the generated code and add any additional tests that may be necessary, and that you should supply example inputs and outputs when the generated tests come back invalid. The assistant produces cases, not coverage.

So pair it with a technique that produces a number. The covering array approach above generalizes. For a rules heavy feature, build the decision table first and ask for one case per rule. For a numeric field, work out the boundaries yourself and ask for a case per boundary. The technique fixes the case list, and the assistant fills in the prose.

The certification bodies treat these as two separate skills. The ISTQB Certified Tester AI Testing (CT-AI) v2.0 syllabus covers testing AI based systems, and that same page sends candidates who want to use generative AI to support testing activities to a separate Certified Tester Testing with Generative AI certification. Testing an AI system and using AI to write test cases are different jobs.

Key Takeaway: AI coding assistants draft test case wording quickly but carry no coverage model, so keep a covering array, a decision table or boundary analysis deciding which cases exist, and review every generated case before it enters the suite.

When to Update Your Test Case Design

It's best to review your test case design regularly as part of a continuous improvement effort. Test case design should be updated or changed if test cases are too difficult to follow or are missing defects. For example, if you find that test cases are executed but defects still end up in the customer release, then it's prudent to review the test case design and format.

Don't fear changing the test design format. If change is needed, then simply try a different format, and see which format identifies defects more effectively. Quality metrics are handy for this use and may provide real-time feedback on test design effectiveness over time. Changing formats does not mean re-writing every test. Simply use the new format going forward for new test case development.

If the organization is moving towards increasing test automation, then the sequential step format may enable automated scripting more effectively. The designation of each step helps create small, automated test scripts focused on a single verification point. Automated test tools often struggle with complex workflows with undefined steps. Sequential steps or checklists may assist in creating working automated scripts that are easily maintained.

Generated test cases are a newer reason to revisit the format. When a coding assistant drafts cases from a requirement or a user story, the design format stops being a writing template and becomes a review checklist. Check every generated case for a single verification point, a stated precondition, and an explicit expected result, then reject any case that folds two checks into one step. A format that was loosely enforced while people wrote each case by hand will not hold once cases arrive in batches.

The test case design is important to providing verification and validation of application functionality across an application's lifecycle. Effective test case design includes selecting test techniques and deciding on a format. Remember when deciding on a test case design, that the purpose is to identify defects and improve the application quality when released to customers. Higher-quality application releases result in positive customer experiences. The happier the customer with the application, the higher the business value of QA testing.

Great test designs help create applications with exceptional customer experience. Use test design to your testing advantage.

Key Takeaway: Update the test case design when test cases become hard to follow or defects still reach customers, and apply the new format to new test cases going forward rather than rewriting the whole existing suite.