Test Design Techniques

Practical application of black-box test design techniques to the SlotsOne slot machine project

6 Techniques

78 Test scenarios

4 Modules covered

100% Black-box

Registration Module Equivalence Partitioning Boundary Value Analysis Decision Table State Transition Pairwise Testing Error Guessing

R

Registration Module

AUTH

The registration form (/register) collects email, password, and an age confirmation checkbox (18+). Backend validates email format (Zod z.string().email()), password min length (8 chars), normalizes email to lowercase, and returns 201 with JWT on success. Below — every test design technique applied to this single module.

EP Equivalence Partitioning — Registration Inputs

ID	Field	Type	Class	Representative	Expected
REP-01	Email	Valid	Standard email format	user@example.com	Accepted
REP-02	Email	Invalid	Missing @ symbol	userexample.com	400 invalid_body
REP-03	Email	Invalid	Missing domain	user@	400 invalid_body
REP-04	Email	Invalid	Empty string	""	400 invalid_body
REP-05	Email	Valid	Already registered	existing@mail.com	409 email_taken
REP-06	Email	Valid	Case variation of existing	User@Example.COM	409 email_taken (lowercased)
REP-07	Password	Valid	8+ characters	SecureP8	Accepted
REP-08	Password	Invalid	< 8 characters	Short1	400 invalid_body
REP-09	Age checkbox	Valid	Checked	true	Submit enabled
REP-10	Age checkbox	Invalid	Unchecked	false	Submit disabled (frontend)

BVA Boundary Value Analysis — Password Length

ID	Boundary	Password	Length	Expected
RBVA-01	Below min	Abcdef7	7	Rejected — button disabled + 400 if bypassed
RBVA-02	At min	Abcdefg8	8	Accepted
RBVA-03	Above min	Abcdefgh9	9	Accepted
RBVA-04	Empty	""	0	Rejected — button disabled + 400
RBVA-05	Single char	A	1	Rejected
RBVA-06	Very long	a × 10 000	10000	Accepted (no max limit — verify server handles)

DT Decision Table — Registration Outcome

Conditions / Actions	R1	R2	R3	R4	R5	R6
Conditions
Valid email format?	N	Y	Y	Y	Y	Y
Password ≥ 8 chars?	—	N	Y	Y	Y	Y
Age confirmed? (frontend)	—	—	N	Y	Y	Y
Email already registered?	—	—	—	Y	N	N
Server reachable?	—	—	—	—	N	Y
Actions
Return 400 invalid_body	X	X
Submit button disabled	X	X	X
Return 409 email_taken				X
Show network error					X
Return 201 + JWT						X
Set refresh token cookie						X
Redirect to /slots						X

ST State Transition — Registration Flow

ID	Current State	Event	Next State	Valid?
RST-01	Landing	Click /register link	Register Form	Valid
RST-02	Register Form	Fill email + password + age check	Form Filled	Valid
RST-03	Register Form	Click submit (button disabled)	Register Form	Invalid (blocked)
RST-04	Form Filled	Click Create Account	Submitting	Valid
RST-05	Submitting	Server returns 201	Authenticated	Valid
RST-06	Submitting	Server returns 409 / 400	Error	Valid
RST-07	Submitting	Network timeout	Error	Valid
RST-08	Error	User corrects input, re-submits	Submitting	Valid
RST-09	Submitting	Click submit again (double-click)	Submitting	Invalid (blocked by loading state)
RST-10	Landing	Has valid refresh cookie	Authenticated	Valid (silent refresh)

PW Pairwise Testing — Registration Parameters

Email Format (3 levels): Valid · Invalid (no @) · Empty

Password Length (3 levels): Short (5) · Min (8) · Long (100)

Age Checkbox (2 levels): Checked · Unchecked

Email Uniqueness (2 levels): New · Already registered

Full combination: 3 × 3 × 2 × 2 = 36 tests → Pairwise reduction: 9 tests (75% reduction)

ID	Email	Password	Age	Unique?	Expected
RPW-01	new@test.com	8 chars	Y	New	201 Created
RPW-02	new2@test.com	5 chars	Y	New	400 password too short
RPW-03	new3@test.com	100 chars	N	New	Blocked button disabled
RPW-04	badformat	8 chars	Y	New	400 invalid email
RPW-05	badformat	100 chars	Y	Existing	400 invalid email
RPW-06	badformat	5 chars	N	New	Blocked button disabled
RPW-07	""	8 chars	N	New	Blocked button disabled
RPW-08	""	5 chars	Y	Existing	Blocked button disabled
RPW-09	exist@test.com	8 chars	Y	Existing	409 email_taken

EG Error Guessing — Registration Edge Cases

ID	Category	Scenario	Risk
REG-01	Race	Two users register with the same email simultaneously	Duplicate users if UNIQUE constraint not checked atomically
REG-02	Race	Double-click "Create Account" — two POST requests sent	Second request should return 409, not create duplicate session
REG-03	Input	Email with leading/trailing spaces: `user@test.com`	Should trim or reject; not store spaces in DB
REG-04	Input	Email with unicode characters: `user@тест.com`	Zod .email() may accept IDN; verify DB stores correctly
REG-05	Input	Extremely long email (500+ chars) with valid format	PostgreSQL TEXT has no limit — may cause issues downstream
REG-06	Security	SQL injection in email: `'; DROP TABLE users;--@x.com`	Parameterized queries must prevent injection
REG-07	Security	XSS payload in email: `<script>alert(1)</script>@x.com`	Must not execute if email displayed in admin panel
REG-08	State	Close browser tab during "Please wait…" loading state	Account may be created but user never receives JWT
REG-09	State	Navigate away (browser back) while request is in-flight	Orphaned request; user may not know account was created
REG-10	API	Send POST with extra fields: `{"email":"…","password":"…","role":"admin"}`	Strict schema must reject — no mass assignment
REG-11	API	Send POST with Content-Type: text/plain instead of JSON	Server must reject with 400, not crash
REG-12	UX	Switch between Login and Register tabs — error message persists	Error from login attempt should clear when switching to register

1

Equivalence Partitioning

EP

Divides input data into groups (classes) where each member is expected to be processed the same way. Testing one representative value per class is sufficient, reducing test count while preserving coverage.

Bet Amount — Input Classes

Class	Type	Range	Representative	Expected Result
EP-01	Invalid	bet < 0.20	0.05	Error: bet below minimum
EP-02	Valid	0.20 ≤ bet ≤ 100.00	5.00	Spin executes, balance debited
EP-03	Invalid	bet > 100.00	250.00	Error: bet above maximum
EP-04	Invalid	bet = 0	0	Error: bet must be positive
EP-05	Invalid	bet < 0	-10.00	Error: invalid bet value

Paylines Count — Input Classes

Class	Type	Range	Representative	Expected Result
EP-06	Invalid	lines < 1	0	Error: at least 1 payline required
EP-07	Valid	1 ≤ lines ≤ 20	10	Spin with 10 active paylines
EP-08	Invalid	lines > 20	25	Error: max 20 paylines

2

Boundary Value Analysis

BVA

Focuses on values at the edges of equivalence classes — the exact boundary, one step below, and one step above. Most defects cluster at boundaries, making this technique highly effective at catching off-by-one and range errors.

Bet Amount Boundaries (min: 0.20, max: 100.00)

ID	Boundary	Value	Expected
BVA-01	Below min	0.19	Rejected
BVA-02	At min	0.20	Accepted
BVA-03	Above min	0.21	Accepted
BVA-04	Below max	99.99	Accepted
BVA-05	At max	100.00	Accepted
BVA-06	Above max	100.01	Rejected

Balance Boundaries for Spin Execution

ID	Scenario	Balance	Bet	Expected
BVA-07	Balance = 0	$0.00	$1.00	Insufficient funds
BVA-08	Balance < bet	$0.50	$1.00	Insufficient funds
BVA-09	Balance = bet	$1.00	$1.00	Spin (balance → $0)
BVA-10	Balance > bet	$50.00	$1.00	Spin (balance → $49)

3

Decision Table Testing

DT

Captures complex business rules where multiple conditions produce different outcomes. Each column represents a unique rule combining condition values and their expected actions. Ensures complete coverage of all meaningful condition combinations.

Spin Outcome Decision Table

Conditions / Actions	R1	R2	R3	R4	R5	R6	R7	R8
Conditions
User authenticated?	N	Y	Y	Y	Y	Y	Y	Y
Balance ≥ bet?	—	N	Y	Y	Y	Y	Y	Y
Valid bet amount?	—	—	N	Y	Y	Y	Y	Y
Winning combination?	—	—	—	N	Y	Y	N	Y
Scatter ≥ 3?	—	—	—	—	N	Y	Y	Y
Actions
Return 401	X
Return insufficient funds		X
Return invalid bet error			X
Debit balance				X	X	X	X	X
Credit winnings					X	X		X
Trigger free spins						X	X	X
Record round in history				X	X	X	X	X

4

State Transition Testing

ST

Models the system as a finite state machine. Tests are derived from valid and invalid transitions between states. Especially useful for UI flows and game lifecycle where the same event may produce different results depending on the current state.

Game Session State Diagram

State Transition Table

ID	Current State	Event	Next State	Valid?
ST-01	Logged Out	Login with valid credentials	Idle	Valid
ST-02	Logged Out	Click Spin	Logged Out	Invalid
ST-03	Idle	Click Spin (balance ok)	Spinning	Valid
ST-04	Idle	Click Spin (no balance)	Idle	Valid (error shown)
ST-05	Spinning	Reels stop — no win	Lose	Valid
ST-06	Spinning	Reels stop — winning combo	Win	Valid
ST-07	Spinning	Click Spin again	Spinning	Invalid (blocked)
ST-08	Win	Scatter ≥ 3 detected	Free Spins	Valid
ST-09	Lose / Win	Continue	Idle	Valid
ST-10	Free Spins	All free spins used	Idle	Valid
ST-11	Spinning	Session token expires	Logged Out	Valid

5

Pairwise Testing

PW

Instead of testing all possible combinations (which can be exponential), pairwise testing ensures every pair of parameter values is covered at least once. Studies show that most defects are caused by interactions between 2 parameters, making this a highly efficient combinatorial technique.

Spin Parameters

Bet Amount (3 levels): Min ($0.20) · Mid ($5.00) · Max ($100.00)

Paylines (3 levels): 1 · 10 · 20

Balance State (3 levels): Low ($1) · Medium ($50) · High ($1000)

Client Seed (2 levels): Default · Custom

Full combination: 3 × 3 × 3 × 2 = 54 tests → Pairwise reduction: 9 tests (83% reduction)

ID	Bet	Paylines	Balance	Client Seed	Note
PW-01	$0.20	1	Low	Default	Min bet, single line, low funds
PW-02	$0.20	10	Medium	Custom	Min bet, custom seed
PW-03	$0.20	20	High	Default	Min bet, all lines
PW-04	$5.00	1	Medium	Default	Mid bet, single line
PW-05	$5.00	10	High	Custom	Mid bet, custom seed
PW-06	$5.00	20	Low	Default	Mid bet + all lines vs low funds
PW-07	$100.00	1	High	Default	Max bet, single line
PW-08	$100.00	10	Low	Custom	Max bet vs insufficient balance
PW-09	$100.00	20	Medium	Default	Max bet, all lines, medium funds

6

Error Guessing

EG

Leverages tester's experience and intuition to anticipate likely defects. Not systematic like other techniques, but invaluable for catching edge cases that formal methods miss. Focuses on historically problematic areas: concurrency, rounding, null values, network failures, and race conditions.

ID	Category	Scenario	Risk
EG-01	Concurrency	Double-click spin button — two requests sent simultaneously	Double debit from wallet
EG-02	Concurrency	Open game in two browser tabs, spin in both at the same moment	Race condition on balance update
EG-03	Rounding	Win amount produces repeating decimal (e.g. $1.00 / 3)	Floating point drift in balance
EG-04	Rounding	Many small wins accumulate — check total matches sum of individual credits	Cent rounding errors over time
EG-05	Network	Network drops during spin — response never arrives	Balance debited but no result shown; stuck UI
EG-06	Network	Timeout on spin API — client retries with same spin_id	Idempotency must return same result, not re-debit
EG-07	Auth	JWT expires mid-session — spin request returns 401	User loses context; auto-redirect vs error
EG-08	Auth	Tampered JWT token (modified payload, invalid signature)	Must reject; not bypass authentication
EG-09	State	Browser back button during spinning animation	Orphaned round; UI desync from server state
EG-10	State	Refresh page immediately after spin response received	Win animation skipped; verify balance reflects result
EG-11	Input	Bet amount sent as string "abc" via API (bypass UI validation)	Server must validate; no 500 errors
EG-12	Input	Extremely large bet via API: $999999999.99	Integer overflow in BIGINT cents conversion
EG-13	Security	Replay a previous spin request with captured spin_id	Must return cached result, not new spin

Technique Coverage Summary

How each technique contributes to overall quality across Spin and Registration modules

Equivalence Partitioning: Reduces redundant tests by grouping inputs into classes. Applied to bet amounts, paylines, email format, and password — 18 scenarios from infinite inputs.

Boundary Value Analysis: Targets off-by-one defects at min/max edges. Applied to bet limits, balance thresholds, and password length boundaries — 16 boundary checks.

Decision Table: Maps 14 business rules across spin outcomes (auth, balance, wins, scatters) and registration flow (email, password, age, uniqueness).

State Transition: Models game states (6 states, 11 transitions) and registration flow (6 states, 10 transitions) — catches invalid UI actions and blocked paths.

Pairwise Testing: Covers all 2-way interactions: 9 spin parameter combos (83% reduction) + 9 registration combos (75% reduction) = 18 efficient tests.

Error Guessing: 25 experience-driven edge cases: concurrency, rounding, network, security (spin) + race conditions, injection, state bugs (registration).