Black-Box Test of an Access-Control Unit: 19-Soft-A6 Software Quality Assurance, December 2013, Q5

Question 5: Black-Box Test of an Access-Control Unit (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Given. Username: 4–8 characters, must exist in the system database. Password: 8–10 characters, must contain at least one capital letter, one digit, and one special character.

Find. A black-box test-case set (equivalence partitioning + boundary value analysis) that exercises every valid and invalid class of both fields, including the character-composition conditions on the password, without reference to the unit's internal code.

Approach. Apply the range guideline from Question 4(b) to each field's LENGTH condition (one valid class, two invalid classes, tested additionally at all four boundary points), and partition the password's three composition requirements as three independent single-condition checks — standard black-box practice for input governed by several ANDed conditions is to violate exactly ONE condition per test case while holding the others valid, so a failure can be attributed to a specific condition rather than a confounded combination.

Partition the username field. Length is a range condition (4–8): valid class V_U1 = length in [4,8] AND present in the database; invalid classes V_U2 = length < 4 (too short), V_U3 = length > 8 (too long), V_U4 = length in [4,8] but NOT present in the database (a fourth invalid class specific to the "in the database" clause, beyond the pure length range). Boundary points for the length range: $3, 4, 8, 9$ (one below the minimum, the minimum itself, the maximum itself, one above the maximum).
Partition the password field. Length is a range condition (8–10): valid class V_P1 = length in [8,10] with all three composition rules satisfied; invalid classes for length alone: V_P2 = length < 8, V_P3 = length > 10. Boundary points: $7, 8, 10, 11$. Composition is three further Boolean-style conditions, each contributing one more invalid class when violated alone: V_P4 = correct length, no uppercase letter; V_P5 = correct length, no digit; V_P6 = correct length, no special character.
Assemble the test-case table. One representative value per class, plus the four boundary lengths on each field, holding the OTHER field valid in every row so a failure is attributable to the row's own field/condition.

#	Username	Password	Condition under test	Expected result
TC1	`bsmith` (6 ch., in DB)	`Passw0rd!` (9 ch.)	V_U1 & V_P1 — both fields fully valid	Access granted
TC2	`bob` (3 ch.)	`Passw0rd!`	V_U2 / boundary 3 — below minimum length	Rejected: username too short
TC3	`alex` (4 ch., in DB)	`Passw0rd!`	Boundary 4 — minimum valid length	Accepted (username field)
TC4	`bsmith01` (8 ch., in DB)	`Passw0rd!`	Boundary 8 — maximum valid length	Accepted (username field)
TC5	`bsmith012` (9 ch.)	`Passw0rd!`	V_U3 / boundary 9 — above maximum length	Rejected: username too long
TC6	`zqxvwt` (6 ch., not in DB)	`Passw0rd!`	V_U4 — correct length, unregistered	Rejected: unknown username
TC7	`bsmith`	`Pw0!xyz` (7 ch.)	V_P2 / boundary 7 — below minimum length	Rejected: password too short
TC8	`bsmith`	`Passw0r!` (8 ch.)	Boundary 8 — minimum valid length	Accepted (password field)
TC9	`bsmith`	`Passw0rd12!` (10 ch.)	Boundary 10 — maximum valid length	Accepted (password field)
TC10	`bsmith`	`Passw0rd123!` (11 ch.)	V_P3 / boundary 11 — above maximum length	Rejected: password too long
TC11	`bsmith`	`password1!` (9 ch., no capital)	V_P4 — missing uppercase letter	Rejected: needs one capital letter
TC12	`bsmith`	`Passsword!` (10 ch., no digit)	V_P5 — missing digit	Rejected: needs one number
TC13	`bsmith`	`Password12` (10 ch., no special char.)	V_P6 — missing special character	Rejected: needs one special character

Concept & Theory

Topic. Black-box test design by equivalence partitioning and boundary value analysis.

Key relations. Each independent input condition (length range, database membership, each of three composition rules) contributes its own valid/invalid class set (Question 4(b)); BVA then adds the four boundary points $\{min-1, min, max, max+1\}$ around every range.

Why this works. Testing one violated condition per case, with every other condition held valid, isolates cause from effect — a failing TC11 unambiguously implicates the uppercase-letter rule, not length or database membership, because those remain valid in that row.

Common pitfall. Combining several invalid conditions in one test case (e.g. a too-short password that also lacks a digit) — a single reported failure then cannot tell the tester which rule actually fired, or whether both did.

Source. Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 20 (Black-box testing — equivalence partitioning, boundary value analysis).

Question 5 of 8: Black-Box Test of an Access-Control Unit

Question 5: Black-Box Test of an Access-Control Unit (10 marks)