Run any Skill in Manus with one click

test-design-techniques

Stars9

Forks1

UpdatedMarch 30, 2026 at 17:00

Test design techniques reference — Equivalence Partitioning (EP), Boundary Value Analysis (BVA), Decision Table Testing, State Transition Testing, Pairwise Testing, Error Guessing, Checklist-based Testing. Used by QA Engineer agent to generate structured, coverage-driven checklists from feature descriptions.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ikovinski

ikovinski/Claude

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

Test Design Techniques Skill

Reference for QA Engineer agent. For each feature, select techniques based on what type of logic is being tested. Each technique: what it is, when to use, how to apply, and concrete checklist examples.

1. Equivalence Partitioning (EP)

What

Divide input data into groups (partitions) where all values in the group are expected to behave identically. Test one representative value per partition instead of every possible input.

Quantity of tests must be equal to quantity of partitions.

For non-numeric partitions (file types, roles, statuses, etc.): if requirements list multiple valid values explicitly, test them as one valid partition — not individually. Write the test using "A or B or C" form.

Only use partitions explicitly defined or implied by the requirements. Do not invent invalid, empty, or edge-case partitions — those are covered by Error Guessing. Exception: for naturally bounded inputs (Age, Quantity, Length, Size) that cannot be negative, 0 is an implied lower boundary even if not stated explicitly.

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Partitions:

0 ≤ Age < 18
18 ≤ Age ≤ 65
Age > 65

Tests:

User with Age = 10 sees error message and cannot sign up
User with Age = 36 is successfully signed up
User with Age = 80 sees error message and cannot sign up

Example 2: User can add avatar in png, jpg or jpeg formats. Other formats are unsupported and error message appears.

Partitions:

files in png, jpg or jpeg format
files not in png, jpg or jpeg format

Tests:

User can successfully add avatar in png, jpg or jpeg format
When user tries to add avatar not inpng, jpg or jpeg format error message appears

2. Boundary Value Analysis (BVA)

What

Errors cluster at the boundaries between partitions. Test the exact boundary values, one below, and one above — not just a value in the middle.

For a range [min, max], always test: min-step, min, min+step, max-step, max, max+step, where step defined by the input type.

If step cannot be defined from the requirements use the following values:

step for double values (like currency or file size) values is 0.01
step for integer values (like age or length) is 1
step for date is 1 day
step for time is 1 minute

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Partitions:

0 ≤ Age < 18
18 ≤ Age ≤ 65
Age > 65

Tests:

User with Age = 0 sees error message and cannot sign up
User with Age = 1 sees error message and cannot sign up
User with Age = 17 sees error message and cannot sign up
User with Age = 18 is successfully signed up
User with Age = 19 is successfully signed up
User with Age = 64 is successfully signed up
User with Age = 65 is successfully signed up
User with Age = 66 sees error message and cannot sign up

Example 2: User can transfer money from his card if the amount does not exceed its actual balance. Otherwise, he sees an error message.

Partitions:

Amount ≤ Balance
Amount > Balance

Tests:

User can successfully transfers amount of Balance-0.01 from his card
User can successfully transfers amount of Balance from his card
User cannot transfer amount of Balance+0.01 from his card and sees error message

Example 3: Users who regisered in the system before 23 June, 2000 have discount of 10% for their purchases.

Partitions:

Registration Date < 23 June, 2000
Registration Date ≥ 23 June, 2000

Tests:

User with Registration Date = 22 June, 2000 has discount of 10%
User with Registration Date = 23 June, 2000 doens't have discount of 10%
User with Registration Date = 24 June, 2000 doens't have discount of 10%

3. Decision Table Testing

What

Model complex business logic where multiple conditions combine to produce different outcomes. Each column is a unique combination of conditions → one test case. Best for: "if A and B but not C, then result X; if A but not B, then result Y".

Two types of decision table can be used:

Limited-entry decision table if conditions are boolean values (true or false)
Expected-entry decision table if at least 1 condition isn't a boolean value (ex: condition Day of week takes 7 values Sun, Mon, Tue, Wed, Thu, Fri, Sat)

Example (Limited-entry decision table): Persons that study at a university and have parents whose total annual income is less than €30.000, receive a scholarship. In addition to these qualifications, if they also live away from home, they receive an addition to their scholarship.

Conditions:

Study at a university?
Annual income less than €30.000?
Live away from home?

Resulting actions:

Receive a scholarship
Receive an addition

Limited-entry decision table:

Full decision table contains all combinations for the conditions.

Condition / Action	TC1	TC2	TC3	TC4	TC5	TC6	TC7	TC8
Study at a university?	0	0	0	0	1	1	1	1
Annual income less than €30.000?	0	0	1	1	0	0	1	1
Live away from home?	0	1	0	1	0	1	0	1
→ Receive a scholarship							X	X
→ Receive an addition								X

Collapced Decision Table:

To collapse the table:

Remove all columns with impossible combinations for conditions (no any impossible combinations in the table above).
Collapce columns with identical set of Actions (ex: TC1 and TC2 in the table above has identical values for Receive a scholarship and Receive an addition actions. For these test cases we have different values for Live away from home condition. It means that this condition doesn't influence on the resulting actions and it is possible to collapce TC1 and TC2 into 1 test where Live away from home is any).
Repeat point 2 while there are columns that can be collapced.

Note: a column where ALL conditions are any is invalid - at least one condition must have a specific value.

Condition / Action	TC1	TC2	TC3	TC4
Study at a university?	0	1	1	1
Annual income less than €30.000?	any	0	1	1
Live away from home?	any	any	0	1
→ Receive a scholarship			X	X
→ Receive an addition				X

Tests:

TC1 -> Person who doesn't study at a university doesn't receive a scholarship and an addition to to their scholarship
TC2 -> Person who studies at a university and whose parents annual income is not less than €30.000 doesn't receive a scholarship and an addition to to their scholarship
TC3 -> Person who studies at a university, whose parents annual income is less than €30.000 and who doesn't live away from home receives a scholarship but doesn't receive an addition to to their scholarship
TC4 -> Person who studies at a university, whose parents annual income is less than €30.000 and who lives away from home receives a scholarship and an addition to to their scholarship

Example (Expected-entry decision table): As a Regular or Special user, I want to be able to use my electronic floor card, to access specific floors. Acceptance Criteria: AC1: Regular users have access to floors 1 to 3. AC2: Floor 4 is only accessible to Special users. AC3: Special users have all the access rights of Regular users. AC4: Error is shown if no access.

Conditions:

User = {Regular, Special}
Floor = {1-3, 4}

Resulting actions:

Access granted
Error

Expected-entry decision table:

Full decision table contains all combinations for the conditions.

Condition / Action	TC1	TC2	TC3	TC4
User	Regular	Regular	Special	Special
Floor	1-3	4	1-3	4
→ Access granted	X		X	X
→ Error		X

Collapced Decision Table:

To collapse the table:

Remove all columns with impossible combinations for conditions (no any impossible combinations in the table above).
Collapce columns with identical set of Actions (ex: TC1 and TC3 in the table above has identical values for Access granted and Error actions. For these test cases we have different values for User condition. It means that this condition doesn't influence on the resulting actions and it is possible to collapce TC1 and TC3 into 1 test where User is any).
Repeat point 2 while there are columns that can be collapced.

Note: a column where ALL conditions are any is invalid - at least one condition must have a specific value.

Condition / Action	TC1	TC2	TC3
User	any	Regular	Special
Floor	1-3	4	4
→ Access granted	X		X
→ Error		X

Tests:

TC1 -> Any user can access Floors 1-3
TC2 -> Regular user cannot access Floor 4, he sees error
TC3 -> Special user can access Floor 4

4. State Transition Testing

What

Model an entity that moves through defined states in response to events/actions. Test valid transitions and invalid transitions.

Example: There is a system that is responsible for checking the PIN code when you want to withdraw money from an ATM or check your balance. User inserts his card, enters PIN code. If the PIN is correct he is able to access his account. If not, user has 2 more tries to enter correct PIN. If PIN is incorrect for the 3rd time, the ATM eats the card.

flowchart LR
    start(["start"])
    wait(["wait for\nPIN"])
    try1(["1st try"])
    try2(["2nd try"])
    try3(["3rd try"])
    access(["access\nto\naccount"])
    eat(["eat card"])

    start -->|card inserted| wait
    wait -->|enter PIN| try1
    try1 -->|PIN not OK| try2
    try2 -->|PIN not OK| try3
    try3 -->|PIN not OK| eat
    try1 -->|PIN OK| access
    try2 -->|PIN OK| access
    try3 -->|PIN OK| access

States:

start
wait for PIN
1st try
2nd try
3rd try
access to account
eat card

Events:

card inserted
PIN entered
PIN is OK
PIN is not OK

Valid Transitions:

start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is not OK) -> 3rd try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is not OK) -> 3rd try -> (PIN is not OK) -> eat card

Invalid Transitions:

start -> (enter PIN)
start -> (PIN is OK)
start -> (PIN is not OK)
wait for PIN -> (card inserted)
wait for PIN -> (PIN is OK)
wait for PIN -> (PIN is not OK)
1st try -> (card inserted)
1st try -> (enter PIN)
2nd try -> (card inserted)
2nd try -> (enter PIN)
3rd try -> (card inserted)
3rd try -> (enter PIN)
access to account -> (card inserted)
access to account -> (enter PIN)
access to account -> (PIN is OK)
access to account -> (PIN is not OK)
eat card -> (card inserted)
eat card -> (enter PIN)
eat card -> (PIN is OK)
eat card -> (PIN is not OK)

Tests that covers valid transitions:

User inserts his card and enters correct PIN from the 1st try -> he has access to his account
User inserts his card and enters correct PIN from the 2nd try -> he has access to his account
User inserts his card and enters correct PIN from the 3rd try -> he has access to his account
User inserts his card and enters incorrect PIN 3 times in a row -> his card is eaten

Tests that covers invalid transitions:

(Define most realistic invalid transitions and add test)

User enters his PIN without inserting his card (no any reaction from the ATM side)
User inserts his card and just after that inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 1st try and inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 2nd try and inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 3rd try and inserts one more card (the ATM doesn't accept it)
User enters incorrect PIN 3 times in a row (card is eaten) and inserts one more card (the ATM waits for PIN)

5. Pairwise Testing

What

When there are many parameters with multiple values, testing all combinations is impossible (N^K explosion). Pairwise guarantees that every pair of parameter values appears in at least one test case — catching ~75% of defects with ~10-20% of test cases.

To generate pairwise combinations, use a pairwise algorithm or tool (e.g. PICT, AllPairs). After generating, verify manually that every pair of parameter values appears in at least one test case.

Note: Pairwise does not guarantee a happy path test case - add it separately if not generated.

Example: For success registration in the system user should fill Name, Age and Weight. Name cannot be empty and should have length from 3 to 30 characters (any characters). Age cannot be empty, range from 12 to 65 is acceptable (type is integer). Weight cannot be empty, range from 34 to 260 is acceptable (type is double). If user enters unacceptable value into 1 or more fields error message is shown. The same error is shown when user doesn't fill 1 or more fields.

Parameters and values (EP technique is applied to define values):

Name (values: strings with length 0..2, strings with length 3..30, strings with length 31+)
Age (values: empty, integer 0..11, integer 12..65, integer 66+, not integer)
Weight (values: empty, double from 0.0 to 33.99, double from 34.0 to 260.0, double 260.01+, not double).

Tests (every pair of values is tested at least once):

Try to register user with Name length 0..2, leave Age empty, leave Weight empty -> Error message is shown
Try to register user with Name length 0..2, Age 0..11, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 0..2, Age 12..65, Weigth from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 0..2, Age 66+, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age not integer, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age 0..11, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 3..30, Age 12..65, Weight 260.01+ -> Error message is shown
Try to register user with Name length 3..30, Age 66+, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age not integer, empty Weigth -> Error message is shown
Try to register user with Name length 3..30, empty Age, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 31+, Age 12..65, Weight not double -> Error message is shown
Try to register user with Name length 31+, Age 66+, empty Weight -> Error message is shown
Try to register user with Name length 31+, Age not integer, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 31+, empty Age, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 31+, Age 0..11, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age 66+, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 0..2, Age not integer, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 0..2, empty Age, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age 0..11, Weight not double -> Error message is shown
Try to register user with Name length 0..2, Age 12..65, empty Weight -> Error message is shown
Try to register user with Name length 3..30, Age not integer, Weight 260.01+ -> Error message is shown
Try to register user with Name length 3..30, empty Age, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age 0..11, empty Weight -> Error message is shown
Try to register user with Name length 3..30, Age 12..65, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 3..30, Age 66+, Weight from 34.0 to 260.0 -> Error message is shown

6. Error Guessing

What

Use experience, intuition, and domain knowledge to predict where defects are likely to be — without a formal model. Fills the gaps left by systematic techniques.

Categories of Errors to Guess

Input & Data

Empty / null / undefined / whitespace-only
Maximum length exceeded, minimum not reached
Special characters: <, >, ", ', &, \, /, %, null as string, undefined as string
SQL/XSS injection strings: '; DROP TABLE users;--, <script>alert(1)</script>
Unicode edge cases: emoji 🎉, RTL text (Arabic), zero-width characters, surrogate pairs
Numeric edge cases: 0, -1, very large numbers (int overflow), float precision (0.1 + 0.2)
Date edge cases: 29 Feb (non-leap year), timezone boundaries, DST change day, past dates, far future dates

File Uploads

Zero-byte file
File with wrong extension (rename .exe to .jpg)
File without extension
Filename with special characters or spaces
Duplicate filename
Corrupted file (truncated, wrong magic bytes)
Extremely long filename

Authentication & Sessions

Login with correct credentials after failed attempts (lockout recovery)
Access resource after session expires
Use refresh token twice (rotation check)
Simultaneous login from 2 devices
Password reset token used twice
Password reset token after password already changed

Concurrency & Race Conditions

Submit the same form twice rapidly (double-click)
Two users performing the same write operation simultaneously
Place order and cancel simultaneously
Apply two mutually exclusive promotions at the same time

Async & Integration

External API returns 500 / timeout / malformed response
Message processed twice (broker re-delivery)
Webhook arrives before the related entity is created
Partial failure mid-transaction (DB write succeeds, event dispatch fails)

UI & UX

Browser back button after completing a multi-step form
Refresh page in the middle of a wizard
Copy-paste values with leading/trailing spaces
Very long text that overflows UI layout
Rapid tab switching or navigation

7. Checklist-based Testing

What

Use pre-defined checklists.

Checklists for different cases

A/B testing (distribution takes place on the Backend)

A new A/B test is created in the admin panel with the correct name
All split groups possible for entry have been added, with correct names and the percentage of users who can enter
Users are assigned to the A/B test at the split point(e.g. after choosing best fit program, after first login etc.) according to the requirements
Only new users are included in the A/B test if defined in the requirements
Old users are excluded from the A/B test if defined in the requirements
Only users meeting all test requirements are included
Check that if each individual requirement is not met, users do not enter the AB test
If the test is configured for only one platform, it does not trigger on the other platform
If the test is configured for both platforms, users are assigned correctly on both iOS and Android
Users are distributed evenly across groups (e.g., 50/50, 33/33/34) if configured so
Users are not redistributed into AB test if they hit the distribution point again
Users are not reassigned to the AB test upon re-login
For the AB test platform, it is possible to define the minimum application version from which users will be included in the distribution
When setting the version to 0.0.0 all users will be included in the AB test, regardless of their app version
When group A is rolled out 100%, all new target users see group А; users already in group B remain in group B
When group B is rolled out 100%, all new target users see group B; users already in group A remain in group A
When AB test is disabled, no new users are distributed to the test
[Database] New A/B test exists in the split table with correct values (name, enabled, site_id for bodyfit, started_at, ended_at, etc.)
[Database] All test groups exist in the split_group table
[Database] Group distribution percentages are correctly displayed in the split_group table
[Database] If a user is assigned to the test, a new record is created in user_split_group with the correct user_id and split_group_id
[Database] Only one record per split exists for each user in user_split_group
[API, if features/availability is used] For a user in the test group, the features/availability endpoint returns a feature access field with value true
[API, if features/availability is used] For a user in the default group, the features/availability endpoint returns the feature access field with value false
[API, if features/availability is used] For a user not in the A/B test, the features/availability endpoint returns the feature access field with value false
[API bodyfit] If the user is in the A/B test, their split group is correctly returned in the response of GET api/mobile/v3.0/user-profile
[API HA] If the user is in the A/B test, their split group is correctly returned in the response of GET api/v1/user/split-groups

A/B testing (distribution takes place on the iOS/ Android side)

Config for A/B test has correct structure in remote config
User Distribution when enabled = true (A/B test active)
[Analytics]: splitExp is correctly sent when the test is active (enabled = true) (e.g. catalogNewTab|A for Control Group, catalogNewTab|B for Test Group)
Winner rollout groups are applied only when enabled = false (A/B test inactive)
[Analytics]: splitExp is no longer sent after the test is completed (enabled = false)
"winnerRollout": "newUser" option
"winnerRollout": "ABTestAndNewUsers" option
"winnerRollout": "allUsers" option

API testing

API documentation is up to date
Missing Authorization header for protected endpoints
Empty Authorization header for protected endpoints
Invalid Authorization header for protected endpoints
Expired Authorization header for protected endpoints
Access token of REGULAR_USER and ANONYMOUS_USER in the Authorization header for protected endpoints
Perfomance (response time is less than 500 ms)
Errors handling (missing/ invalid data in the request body, missing/ invalid headers, missing/ invalid query string parameters)

iOS/ Android apps testing

Dark/ Light theme
Different screen resolutions (small, medium, large)
Different OS versions (iOS, Android)
UI/UX consistency (font, alignment, button style)
Scrolling works as expected
Pagination works as expected
Performance (screen is fully rendered during 2-3 seconds)
Connectivity (no internet connection, slow internet connection, WiFi/ Mobile internet)
Skeleton is used when loading takes some time
No excessive caching on the screens
Integration with API Service (handling of errors, no double calls to the same API endpoint etc.)
Navigation back (Back button, swiping back) for all the screens from the requirements
User closes the app in the middle of the flow
User backgrounds and foregrounds the app in the middle of the flow
User re-installs the app
User updates the app
Permissions are handled correctly (the app asks for Notifications, Location, Camera, Storage and so on permissions)
Localization (translations exist, texts are too long/ too short, date/ currency/ measurement system formats)
Screens UI looks good with enlarged fonts

Output Format

- [ ] <Specific, actionable check> -> <Expected result>
- [ ] <Specific, actionable check> -> <Expected result>

name	test-design-techniques
description	Test design techniques reference — Equivalence Partitioning (EP), Boundary Value Analysis (BVA), Decision Table Testing, State Transition Testing, Pairwise Testing, Error Guessing, Checklist-based Testing. Used by QA Engineer agent to generate structured, coverage-driven checklists from feature descriptions.
version	1.0.0

Test Design Techniques Skill

1. Equivalence Partitioning (EP)

What

Divide input data into groups (partitions) where all values in the group are expected to behave identically. Test one representative value per partition instead of every possible input.

Quantity of tests must be equal to quantity of partitions.

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Partitions:

0 ≤ Age < 18
18 ≤ Age ≤ 65
Age > 65

Tests:

User with Age = 10 sees error message and cannot sign up
User with Age = 36 is successfully signed up
User with Age = 80 sees error message and cannot sign up

Example 2: User can add avatar in png, jpg or jpeg formats. Other formats are unsupported and error message appears.

Partitions:

files in png, jpg or jpeg format
files not in png, jpg or jpeg format

Tests:

User can successfully add avatar in png, jpg or jpeg format
When user tries to add avatar not inpng, jpg or jpeg format error message appears

2. Boundary Value Analysis (BVA)

What

Errors cluster at the boundaries between partitions. Test the exact boundary values, one below, and one above — not just a value in the middle.

For a range [min, max], always test: min-step, min, min+step, max-step, max, max+step, where step defined by the input type.

If step cannot be defined from the requirements use the following values:

step for double values (like currency or file size) values is 0.01
step for integer values (like age or length) is 1
step for date is 1 day
step for time is 1 minute

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Partitions:

0 ≤ Age < 18
18 ≤ Age ≤ 65
Age > 65

Tests:

User with Age = 0 sees error message and cannot sign up
User with Age = 1 sees error message and cannot sign up
User with Age = 17 sees error message and cannot sign up
User with Age = 18 is successfully signed up
User with Age = 19 is successfully signed up
User with Age = 64 is successfully signed up
User with Age = 65 is successfully signed up
User with Age = 66 sees error message and cannot sign up

Example 2: User can transfer money from his card if the amount does not exceed its actual balance. Otherwise, he sees an error message.

Partitions:

Amount ≤ Balance
Amount > Balance

Tests:

User can successfully transfers amount of Balance-0.01 from his card
User can successfully transfers amount of Balance from his card
User cannot transfer amount of Balance+0.01 from his card and sees error message

Example 3: Users who regisered in the system before 23 June, 2000 have discount of 10% for their purchases.

Partitions:

Registration Date < 23 June, 2000
Registration Date ≥ 23 June, 2000

Tests:

User with Registration Date = 22 June, 2000 has discount of 10%
User with Registration Date = 23 June, 2000 doens't have discount of 10%
User with Registration Date = 24 June, 2000 doens't have discount of 10%

3. Decision Table Testing

What

Two types of decision table can be used:

Limited-entry decision table if conditions are boolean values (true or false)
Expected-entry decision table if at least 1 condition isn't a boolean value (ex: condition Day of week takes 7 values Sun, Mon, Tue, Wed, Thu, Fri, Sat)

Example (Limited-entry decision table): Persons that study at a university and have parents whose total annual income is less than €30.000, receive a scholarship. In addition to these qualifications, if they also live away from home, they receive an addition to their scholarship.

Conditions:

Study at a university?
Annual income less than €30.000?
Live away from home?

Resulting actions:

Receive a scholarship
Receive an addition

Limited-entry decision table:

Full decision table contains all combinations for the conditions.

Condition / Action	TC1	TC2	TC3	TC4	TC5	TC6	TC7	TC8
Study at a university?	0	0	0	0	1	1	1	1
Annual income less than €30.000?	0	0	1	1	0	0	1	1
Live away from home?	0	1	0	1	0	1	0	1
→ Receive a scholarship							X	X
→ Receive an addition								X

Collapced Decision Table:

To collapse the table:

Remove all columns with impossible combinations for conditions (no any impossible combinations in the table above).
Collapce columns with identical set of Actions (ex: TC1 and TC2 in the table above has identical values for Receive a scholarship and Receive an addition actions. For these test cases we have different values for Live away from home condition. It means that this condition doesn't influence on the resulting actions and it is possible to collapce TC1 and TC2 into 1 test where Live away from home is any).
Repeat point 2 while there are columns that can be collapced.

Note: a column where ALL conditions are any is invalid - at least one condition must have a specific value.

Condition / Action	TC1	TC2	TC3	TC4
Study at a university?	0	1	1	1
Annual income less than €30.000?	any	0	1	1
Live away from home?	any	any	0	1
→ Receive a scholarship			X	X
→ Receive an addition				X

Tests:

TC1 -> Person who doesn't study at a university doesn't receive a scholarship and an addition to to their scholarship
TC2 -> Person who studies at a university and whose parents annual income is not less than €30.000 doesn't receive a scholarship and an addition to to their scholarship
TC3 -> Person who studies at a university, whose parents annual income is less than €30.000 and who doesn't live away from home receives a scholarship but doesn't receive an addition to to their scholarship
TC4 -> Person who studies at a university, whose parents annual income is less than €30.000 and who lives away from home receives a scholarship and an addition to to their scholarship

Example (Expected-entry decision table): As a Regular or Special user, I want to be able to use my electronic floor card, to access specific floors. Acceptance Criteria: AC1: Regular users have access to floors 1 to 3. AC2: Floor 4 is only accessible to Special users. AC3: Special users have all the access rights of Regular users. AC4: Error is shown if no access.

Conditions:

User = {Regular, Special}
Floor = {1-3, 4}

Resulting actions:

Access granted
Error

Expected-entry decision table:

Full decision table contains all combinations for the conditions.

Condition / Action	TC1	TC2	TC3	TC4
User	Regular	Regular	Special	Special
Floor	1-3	4	1-3	4
→ Access granted	X		X	X
→ Error		X

Collapced Decision Table:

To collapse the table:

Remove all columns with impossible combinations for conditions (no any impossible combinations in the table above).
Collapce columns with identical set of Actions (ex: TC1 and TC3 in the table above has identical values for Access granted and Error actions. For these test cases we have different values for User condition. It means that this condition doesn't influence on the resulting actions and it is possible to collapce TC1 and TC3 into 1 test where User is any).
Repeat point 2 while there are columns that can be collapced.

Note: a column where ALL conditions are any is invalid - at least one condition must have a specific value.

Condition / Action	TC1	TC2	TC3
User	any	Regular	Special
Floor	1-3	4	4
→ Access granted	X		X
→ Error		X

Tests:

TC1 -> Any user can access Floors 1-3
TC2 -> Regular user cannot access Floor 4, he sees error
TC3 -> Special user can access Floor 4

4. State Transition Testing

What

Model an entity that moves through defined states in response to events/actions. Test valid transitions and invalid transitions.

Example: There is a system that is responsible for checking the PIN code when you want to withdraw money from an ATM or check your balance. User inserts his card, enters PIN code. If the PIN is correct he is able to access his account. If not, user has 2 more tries to enter correct PIN. If PIN is incorrect for the 3rd time, the ATM eats the card.

flowchart LR
    start(["start"])
    wait(["wait for\nPIN"])
    try1(["1st try"])
    try2(["2nd try"])
    try3(["3rd try"])
    access(["access\nto\naccount"])
    eat(["eat card"])

    start -->|card inserted| wait
    wait -->|enter PIN| try1
    try1 -->|PIN not OK| try2
    try2 -->|PIN not OK| try3
    try3 -->|PIN not OK| eat
    try1 -->|PIN OK| access
    try2 -->|PIN OK| access
    try3 -->|PIN OK| access

States:

start
wait for PIN
1st try
2nd try
3rd try
access to account
eat card

Events:

card inserted
PIN entered
PIN is OK
PIN is not OK

Valid Transitions:

start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is not OK) -> 3rd try -> (PIN is OK) -> access to account
start -> (card inserted) -> wait for PIN -> (PIN entered) -> 1st try -> (PIN is not OK) -> 2nd try -> (PIN is not OK) -> 3rd try -> (PIN is not OK) -> eat card

Invalid Transitions:

start -> (enter PIN)
start -> (PIN is OK)
start -> (PIN is not OK)
wait for PIN -> (card inserted)
wait for PIN -> (PIN is OK)
wait for PIN -> (PIN is not OK)
1st try -> (card inserted)
1st try -> (enter PIN)
2nd try -> (card inserted)
2nd try -> (enter PIN)
3rd try -> (card inserted)
3rd try -> (enter PIN)
access to account -> (card inserted)
access to account -> (enter PIN)
access to account -> (PIN is OK)
access to account -> (PIN is not OK)
eat card -> (card inserted)
eat card -> (enter PIN)
eat card -> (PIN is OK)
eat card -> (PIN is not OK)

Tests that covers valid transitions:

User inserts his card and enters correct PIN from the 1st try -> he has access to his account
User inserts his card and enters correct PIN from the 2nd try -> he has access to his account
User inserts his card and enters correct PIN from the 3rd try -> he has access to his account
User inserts his card and enters incorrect PIN 3 times in a row -> his card is eaten

Tests that covers invalid transitions:

(Define most realistic invalid transitions and add test)

User enters his PIN without inserting his card (no any reaction from the ATM side)
User inserts his card and just after that inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 1st try and inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 2nd try and inserts one more card (the ATM doesn't accept it)
User enter correct PIN from the 3rd try and inserts one more card (the ATM doesn't accept it)
User enters incorrect PIN 3 times in a row (card is eaten) and inserts one more card (the ATM waits for PIN)

5. Pairwise Testing

What

To generate pairwise combinations, use a pairwise algorithm or tool (e.g. PICT, AllPairs). After generating, verify manually that every pair of parameter values appears in at least one test case.

Note: Pairwise does not guarantee a happy path test case - add it separately if not generated.

Example: For success registration in the system user should fill Name, Age and Weight. Name cannot be empty and should have length from 3 to 30 characters (any characters). Age cannot be empty, range from 12 to 65 is acceptable (type is integer). Weight cannot be empty, range from 34 to 260 is acceptable (type is double). If user enters unacceptable value into 1 or more fields error message is shown. The same error is shown when user doesn't fill 1 or more fields.

Parameters and values (EP technique is applied to define values):

Name (values: strings with length 0..2, strings with length 3..30, strings with length 31+)
Age (values: empty, integer 0..11, integer 12..65, integer 66+, not integer)
Weight (values: empty, double from 0.0 to 33.99, double from 34.0 to 260.0, double 260.01+, not double).

Tests (every pair of values is tested at least once):

Try to register user with Name length 0..2, leave Age empty, leave Weight empty -> Error message is shown
Try to register user with Name length 0..2, Age 0..11, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 0..2, Age 12..65, Weigth from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 0..2, Age 66+, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age not integer, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age 0..11, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 3..30, Age 12..65, Weight 260.01+ -> Error message is shown
Try to register user with Name length 3..30, Age 66+, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age not integer, empty Weigth -> Error message is shown
Try to register user with Name length 3..30, empty Age, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 31+, Age 12..65, Weight not double -> Error message is shown
Try to register user with Name length 31+, Age 66+, empty Weight -> Error message is shown
Try to register user with Name length 31+, Age not integer, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 31+, empty Age, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 31+, Age 0..11, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age 66+, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 0..2, Age not integer, Weight from 34.0 to 260.0 -> Error message is shown
Try to register user with Name length 0..2, empty Age, Weight 260.01+ -> Error message is shown
Try to register user with Name length 0..2, Age 0..11, Weight not double -> Error message is shown
Try to register user with Name length 0..2, Age 12..65, empty Weight -> Error message is shown
Try to register user with Name length 3..30, Age not integer, Weight 260.01+ -> Error message is shown
Try to register user with Name length 3..30, empty Age, Weight not double -> Error message is shown
Try to register user with Name length 3..30, Age 0..11, empty Weight -> Error message is shown
Try to register user with Name length 3..30, Age 12..65, Weight from 0.0 to 33.99 -> Error message is shown
Try to register user with Name length 3..30, Age 66+, Weight from 34.0 to 260.0 -> Error message is shown

6. Error Guessing

What

Use experience, intuition, and domain knowledge to predict where defects are likely to be — without a formal model. Fills the gaps left by systematic techniques.

Categories of Errors to Guess

Input & Data

Empty / null / undefined / whitespace-only
Maximum length exceeded, minimum not reached
Special characters: <, >, ", ', &, \, /, %, null as string, undefined as string
SQL/XSS injection strings: '; DROP TABLE users;--, <script>alert(1)</script>
Unicode edge cases: emoji 🎉, RTL text (Arabic), zero-width characters, surrogate pairs
Numeric edge cases: 0, -1, very large numbers (int overflow), float precision (0.1 + 0.2)
Date edge cases: 29 Feb (non-leap year), timezone boundaries, DST change day, past dates, far future dates

File Uploads

Zero-byte file
File with wrong extension (rename .exe to .jpg)
File without extension
Filename with special characters or spaces
Duplicate filename
Corrupted file (truncated, wrong magic bytes)
Extremely long filename

Authentication & Sessions

Login with correct credentials after failed attempts (lockout recovery)
Access resource after session expires
Use refresh token twice (rotation check)
Simultaneous login from 2 devices
Password reset token used twice
Password reset token after password already changed

Concurrency & Race Conditions

Submit the same form twice rapidly (double-click)
Two users performing the same write operation simultaneously
Place order and cancel simultaneously
Apply two mutually exclusive promotions at the same time

Async & Integration

External API returns 500 / timeout / malformed response
Message processed twice (broker re-delivery)
Webhook arrives before the related entity is created
Partial failure mid-transaction (DB write succeeds, event dispatch fails)

UI & UX

Browser back button after completing a multi-step form
Refresh page in the middle of a wizard
Copy-paste values with leading/trailing spaces
Very long text that overflows UI layout
Rapid tab switching or navigation

7. Checklist-based Testing

What

Use pre-defined checklists.

Checklists for different cases

A/B testing (distribution takes place on the Backend)

A new A/B test is created in the admin panel with the correct name
All split groups possible for entry have been added, with correct names and the percentage of users who can enter
Users are assigned to the A/B test at the split point(e.g. after choosing best fit program, after first login etc.) according to the requirements
Only new users are included in the A/B test if defined in the requirements
Old users are excluded from the A/B test if defined in the requirements
Only users meeting all test requirements are included
Check that if each individual requirement is not met, users do not enter the AB test
If the test is configured for only one platform, it does not trigger on the other platform
If the test is configured for both platforms, users are assigned correctly on both iOS and Android
Users are distributed evenly across groups (e.g., 50/50, 33/33/34) if configured so
Users are not redistributed into AB test if they hit the distribution point again
Users are not reassigned to the AB test upon re-login
For the AB test platform, it is possible to define the minimum application version from which users will be included in the distribution
When setting the version to 0.0.0 all users will be included in the AB test, regardless of their app version
When group A is rolled out 100%, all new target users see group А; users already in group B remain in group B
When group B is rolled out 100%, all new target users see group B; users already in group A remain in group A
When AB test is disabled, no new users are distributed to the test
[Database] New A/B test exists in the split table with correct values (name, enabled, site_id for bodyfit, started_at, ended_at, etc.)
[Database] All test groups exist in the split_group table
[Database] Group distribution percentages are correctly displayed in the split_group table
[Database] If a user is assigned to the test, a new record is created in user_split_group with the correct user_id and split_group_id
[Database] Only one record per split exists for each user in user_split_group
[API, if features/availability is used] For a user in the test group, the features/availability endpoint returns a feature access field with value true
[API, if features/availability is used] For a user in the default group, the features/availability endpoint returns the feature access field with value false
[API, if features/availability is used] For a user not in the A/B test, the features/availability endpoint returns the feature access field with value false
[API bodyfit] If the user is in the A/B test, their split group is correctly returned in the response of GET api/mobile/v3.0/user-profile
[API HA] If the user is in the A/B test, their split group is correctly returned in the response of GET api/v1/user/split-groups

A/B testing (distribution takes place on the iOS/ Android side)

Config for A/B test has correct structure in remote config
User Distribution when enabled = true (A/B test active)
[Analytics]: splitExp is correctly sent when the test is active (enabled = true) (e.g. catalogNewTab|A for Control Group, catalogNewTab|B for Test Group)
Winner rollout groups are applied only when enabled = false (A/B test inactive)
[Analytics]: splitExp is no longer sent after the test is completed (enabled = false)
"winnerRollout": "newUser" option
"winnerRollout": "ABTestAndNewUsers" option
"winnerRollout": "allUsers" option

API testing

API documentation is up to date
Missing Authorization header for protected endpoints
Empty Authorization header for protected endpoints
Invalid Authorization header for protected endpoints
Expired Authorization header for protected endpoints
Access token of REGULAR_USER and ANONYMOUS_USER in the Authorization header for protected endpoints
Perfomance (response time is less than 500 ms)
Errors handling (missing/ invalid data in the request body, missing/ invalid headers, missing/ invalid query string parameters)

iOS/ Android apps testing

Dark/ Light theme
Different screen resolutions (small, medium, large)
Different OS versions (iOS, Android)
UI/UX consistency (font, alignment, button style)
Scrolling works as expected
Pagination works as expected
Performance (screen is fully rendered during 2-3 seconds)
Connectivity (no internet connection, slow internet connection, WiFi/ Mobile internet)
Skeleton is used when loading takes some time
No excessive caching on the screens
Integration with API Service (handling of errors, no double calls to the same API endpoint etc.)
Navigation back (Back button, swiping back) for all the screens from the requirements
User closes the app in the middle of the flow
User backgrounds and foregrounds the app in the middle of the flow
User re-installs the app
User updates the app
Permissions are handled correctly (the app asks for Notifications, Location, Camera, Storage and so on permissions)
Localization (translations exist, texts are too long/ too short, date/ currency/ measurement system formats)
Screens UI looks good with enlarged fonts

Output Format

- [ ] <Specific, actionable check> -> <Expected result>
- [ ] <Specific, actionable check> -> <Expected result>

test-design-techniques

More from this repository

Test Design Techniques Skill

1. Equivalence Partitioning (EP)

What

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Example 2: User can add avatar in png, jpg or jpeg formats. Other formats are unsupported and error message appears.

2. Boundary Value Analysis (BVA)

What

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Example 2: User can transfer money from his card if the amount does not exceed its actual balance. Otherwise, he sees an error message.

Example 3: Users who regisered in the system before 23 June, 2000 have discount of 10% for their purchases.

3. Decision Table Testing

What

Example (Limited-entry decision table): Persons that study at a university and have parents whose total annual income is less than €30.000, receive a scholarship. In addition to these qualifications, if they also live away from home, they receive an addition to their scholarship.

4. State Transition Testing

What

5. Pairwise Testing

What

6. Error Guessing

What

Categories of Errors to Guess

Input & Data

File Uploads

API & Network

Authentication & Sessions

Concurrency & Race Conditions

Async & Integration

UI & UX

7. Checklist-based Testing

What

Checklists for different cases

A/B testing (distribution takes place on the Backend)

A/B testing (distribution takes place on the iOS/ Android side)

API testing

iOS/ Android apps testing

Output Format

Test Design Techniques Skill

1. Equivalence Partitioning (EP)

What

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Example 2: User can add avatar in png, jpg or jpeg formats. Other formats are unsupported and error message appears.

2. Boundary Value Analysis (BVA)

What

Example 1: Only users with Age field from 18 to 65 years are able to sing up in the system. Users with Age less than 18 or greater than 65 see an error message.

Example 2: User can transfer money from his card if the amount does not exceed its actual balance. Otherwise, he sees an error message.

Example 3: Users who regisered in the system before 23 June, 2000 have discount of 10% for their purchases.

3. Decision Table Testing

What

Example (Limited-entry decision table): Persons that study at a university and have parents whose total annual income is less than €30.000, receive a scholarship. In addition to these qualifications, if they also live away from home, they receive an addition to their scholarship.

4. State Transition Testing

What

5. Pairwise Testing

What

6. Error Guessing

What

Categories of Errors to Guess

Input & Data

File Uploads

API & Network

Authentication & Sessions

Concurrency & Race Conditions

Async & Integration

UI & UX

7. Checklist-based Testing

What

Checklists for different cases

A/B testing (distribution takes place on the Backend)

A/B testing (distribution takes place on the iOS/ Android side)

API testing

iOS/ Android apps testing

Output Format

More from this repository