Example for Dealing with Functional and Non-Functional Requirements in Testing
World Widgets, working on its next major product release, includes the following in its requirements specification:
A323. An authorized user creates a new customer record with all required fields (as designated by red text) filled in and which, upon saving, will get a a non-modifiable unique customer id (functional requirement).
B323. All new releases must be modified to be 508 compliant (non-functional requirement).
A test team reviews the requirements and writes the following test case:
Test Name: Create new customer record.
Req. ID: A323 (traceability)
Step 1: File - New - Customer Record
Expected Result: Customer Record dialog box appears (with id field blank)
Step 2: User enters information into required fields.
Expected Result: fields are populated with text.
Step 3: User clicks Save button
Expected Result: Dialog box displays a unique id
Expected Result: Status line appears saying record is saved
Expected Result: Dialog box Edit button becomes active
Expected Result: Verify 508 compliancy ==> this 'check' gets added to every test case (traceability)
Because 508 compliance is a set of criteria which can be adopted in whole or in part and is subject to some interpretation, this 'check' should link to a document or checklist which outlines the extent of the compliance. This saves the test case from numerous and repetitive checks being listed while still reminding the tester of the global requirement. In this case, the document might specify that the system cannot overwrite user-specified black and white style sheets as one of many of the checks adopted which can be confirmed.