1. Florida A&M University
Testing in the Capstone Course: Foundations and Patterns for a Value-Added Experience
Edward L. Jones
Florida A&M University
Tallahassee, FL 32307

2. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

3. CCSC Tutorial -- Testing
Purpose
This tutorial gives practical ways testing can be incorporated into the capstone course in such a way as to achieve two complementary goals:
solid specification
well defined test plan
EL Jones
CCSC Tutorial -- Testing 5

4. CCSC Tutorial -- Testing
Approach
System elements have properties and behavior
These need to be specified
Good specification facilitates testing
Test-focused specification kills two birds with one stone!!
Testing involves either executing a unit or inspecting a unit -- with the intent of finding errors.
EL Jones
CCSC Tutorial -- Testing

5. CCSC Tutorial -- Testing
Philosophy
Document as if you were testing
Test using documentation
Exploit behavior patterns in the software elements
Test worksheets
Testing involves either executing a unit or inspecting a unit -- with the intent of finding errors.
EL Jones
CCSC Tutorial -- Testing

6. Form Testing Worksheets
Template Set
Master template
Separate template for each form element
Website:
Preview Worksheets
The worksheet templates satisfy the goals of
SPECIFICATION driven
PREMEDITATION -- systematic design process
REPEATABILITY -- same templates used by all.
ACCOUNTABILITY -- the worksheet are a record of what was planned, what was tested, and what the results were.
ECONOMY -- the effort to design and execute tests is bounded. Expect it to reduce through reuse (copy, paste, edit).
EL Jones
CCSC Tutorial -- Testing 5

7. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

8. Typical Project Architecture
Data Control
Operation
Navigation
Main Menu
(Form)
Form
Database
EL Jones
CCSC Tutorial -- Testing

9. PATIENT MEDICATION MANAGEMENT SYSTEM (PMMS)
System Main Menu
PATIENT MEDICATION MANAGEMENT SYSTEM (PMMS)
Account
Name
Calculate Dosage
Update Patient Chart
Exit System
EL Jones
CCSC Tutorial -- Testing

10. CCSC Tutorial -- Testing
Calculate Dosage Form
PATIENT DOSAGE FORM
Account
Name
Calculate Dosage
Weight
Age
Recommended
Dosage
=> 12 and under
=> 13-65
=> 65-80
=> over 80
Clear
Save
Go Back
EL Jones
CCSC Tutorial -- Testing

11. CCSC Tutorial -- Testing
Typical Experience
System design is fun for students
Behavior specification is weak
System elements implemented inconsistently
System test is ad hoc
Discovers major problems too late.
Testing involves either executing a unit or inspecting a unit -- with the intent of finding errors.
EL Jones
CCSC Tutorial -- Testing

12. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

13. CCSC Tutorial -- Testing
WHAT IS TESTING?
Executing a software element to determine whether it meets its specification
Executing a software element to discover defects or anomalies
Testing involves either executing a unit or inspecting a unit -- with the intent of finding errors.
EL Jones
CCSC Tutorial -- Testing

14. CCSC Tutorial -- Testing
LEVELS OF TESTING
UNIT -- testing small elements in isolation
INTEGRATION -- testing subsets of elements in combination
SYSTEM -- testing the completed system
When we think of units, we generally think SMALL. In addition to being small, there are other features of a unit:
NAMED SOFTWARE ELEMENT THAT CAN BE SEPARATELY INVOKED
LOGICALLY COHERENT -- Performs a SINGLE function or a GROUP OF RELATED FUNCTIONS.
EL Jones
CCSC Tutorial -- Testing

15. CCSC Tutorial -- Testing
WHAT IS A UNIT?
Named software element
properties
behavior
Separately invokable
Performs single function
Logically cohesive set of the above
When we think of units, we generally think SMALL. In addition to being small, there are other features of a unit:
NAMED SOFTWARE ELEMENT THAT CAN BE SEPARATELY INVOKED
LOGICALLY COHERENT -- Performs a SINGLE function or a GROUP OF RELATED FUNCTIONS.
EL Jones
CCSC Tutorial -- Testing

16. CCSC Tutorial -- Testing
EXAMPLES OF UNITS
User-Visible software elements
Fields on forms
Buttons on forms
Entire forms (reports)
Program-Internal software elements
Subprograms
Classes
Databases
This break-out of units into VISIBLE and INTERNAL is related to how the unit is INVOKED DURING TESTING
VISIBLE -- test scripts, human tester
INTERNAL -- test drivers, automated tester
EL Jones
CCSC Tutorial -- Testing

17. CCSC Tutorial -- Testing
ELEMENTARY UNITS
Form
Field
Navigation Button
Operation Button
Database
Stored Procedure
Query
Program Code
Main
Method
Function
Script
FORMS, DATABASE and CLASSES are COMPOSITE UNIT made up of elementary units.
A composite unit is tested by testing each of its elementary units, in a bottom-up fashion.
EL Jones
CCSC Tutorial -- Testing

18. CCSC Tutorial -- Testing
Objective
The practice of unit testing adds value to the development process by surfacing areas of incompleteness, inaccuracy or ambiguity. Extensive use of aids (checklists, worksheets) minimize the effort but encourages thorough analysis.
A message of this course is that UNIT TESTING PAYS when addressed early in the life cycle.
The COST of unit testing is reduced through the use of worksheets and checklists … and through AUTOMATION (as we will see later).
EL Jones
CCSC Tutorial -- Testing 5

19. Required Elements of a Testing Methodology
Specification for the software
Process for designing test cases
Repeatable process for designing, running and evaluating tests
Accountable artifacts of testing activities
Economical use of human, time and computing resources
Recall that sound testing practice is based on the SPECIFICATION and a systematic, repeatable process for test case design.
This session deals with achieving ACCOUNTABILITY -- producing evidence that such a systematic process has been followed -- in a COST-EFFECTIVE way.
EL Jones
CCSC Tutorial -- Testing

20. CCSC Tutorial -- Testing
Recommended Practice
Specification,
Code
Analysis
Design
Implementation
Execution
Evaluation
Decision Table
Worksheet
(Test Cases)
Workbook
This session focuses on the middle three phases.
1) Test Case Design, which results in the completion of test cases that are recorded in a test worksheet.
2) Test Implementation, which results in manual scripts (e.g., worksheet) or automated test drivers.
3) Test Execution involves performing the tests according to the scripts/drivers and recording results within worksheets or driver output files.
4) The PRIMARY RESULT is BUG COUNTS
FINDING BUGS IS GOOD … DURING TESTING!!
Test Results
(Workbook)
#Bugs Found
EL Jones
CCSC Tutorial -- Testing

21. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

22. CCSC Tutorial -- Testing
WHY IS A FIELD A UNIT?
Field has properties
Data type and domain (size, value set, default)
Visual appearance (color, case, alignment)
Accessibility" Read-only, write-only, R/W
Field has behavior
Validation -- reject if property rule violated
Messaging -- to report violation
Global status -- bad field invalidates form
1) A field has the characteristics of a unit. It is an ELEMENTARY VISIBLE UNIT.
2) Of the properties of a field, some depend on the form (e.g., color, usage for input/output), while others depend on the application (set of values, default value).
3) Activation of a field results in several important behaviors
a) Validation
b) Messaging -- if validation fails
c) Setting of FORM STATUS (e.g., SUBMIT button DISABLED UNTIL all fields contain valid data.
EL Jones
CCSC Tutorial -- Testing

23. FIELD ATTRIBUTES and BEHAVIOR
Data type
Length
Format
Domain
Default value
Validation rules
Error messages
1) Unit tests are required to ensure the correct implementation of field attributes and behavior.
TESTS OF FORM-INDEPENDENT ATTRIBUTES & BEHAVIORS ARE REUSABLE!!
EL Jones
CCSC Tutorial -- Testing

24. TESTING AN INPUT FIELD An Error-Handling Approach
A primary function of an input field is to validate data entered into a field, and to notify the user if an error occurs.
Properties of the field determine error conditions and the correct response
Input field testing ensures that only valid input is accepted, and proper error handling occurs.
The major focus of field testing is VALIDATION and ERROR HANDLING.
Validation can be programmed using property sheets of the field (Lotus Notes) or written in the target language (e.g., Java).
EL Jones
CCSC Tutorial -- Testing

25. Relationships Between Attributes and Validation
Validation rules perform self-checking at field, form, and/or database level
Error prevention in LotusNotes/Access
Input masking prevents formatting and data type errors
List boxes prevent input errors
Certain "semantic" errors still must be checked (inconsistency)
VALIDATION ensures that the intended ATTRIBUTES have been correctly implemented.
Certain technology, such as Microsoft Office or Lotus Notes can prevent certain errors from occurring, eliminating the need for validation.
Even then, the CORRECT USE of these features must be TESTED.
EL Jones
CCSC Tutorial -- Testing

26. WHEN IS VALIDATION PERFORMED?
At the field level, immediately upon changing focus from field (e.g., client side)
Supports build & test
At the form level, upon clicking a button that requires the data (e.g., server side)
Deferred field test, rolled into form test.
Testing a field is easiest when validation occurs IMMEDIATELY upon leaving the field. The developer can follow a BUILD-then-TEST approach, correctly implementing one field before implementing the next field.
CLIENT-SIDE validation permits this.
DEFERRED VALIDATION occurs when a field is validated only WHEN USED -- when a button is selected. The BUILD-then-TEST approach is hard in this case.
SERVER-SIDE validation is deferred validation.
EL Jones
CCSC Tutorial -- Testing

27. BEFORE WE CONTINUE … A LOOK AHEAD
We derive generic test case specifications for certain types of fields
Text boxes -- string and numeric data
List boxes -- string and numeric data
These become worksheet templates for designing field test cases
WORKSHEET = SPECIFICATION
In the next section we will DERIVE a set of generic test case descriptions for testing input fields implemented as text boxes and list boxes.
The result will be WORKSHEET TEMPLATES that will be tailored to a given situation.
The purpose of showing the DERIVATION is to show you how to construct worksheet templates for other types of fields or other units that FOLLOW A PATTERN.
EL Jones
CCSC Tutorial -- Testing

28. WHERE IS THE WORK? … A LOOK AHEAD
Developer supplies actual test cases for each test case specification
Developer may derive additional generic test case specs for new field types
Developer combines test cases into a test workbook.
Don’t forget that these are TEMPLATES, so some critical thought must be put into making them reflect the situation at hand.
The INTENT is to GUIDE the developer through a TEST CASE DESIGN PROCESS>
EL Jones
CCSC Tutorial -- Testing

29. Deriving Generic Test Case Specs for a Text Box
c1: Wrong Data type | Y N N N N Condition
c2: Wrong Length | - Y N N N
c3: Wrong format | - - Y N N
c4: Illegal value | Y N
c5: Default value used | N Y
c6: Wrong default value | Y
a1: PREVENTED | Action
a2: Data Type Error Msg | X
a3: Length Error Msg | X
a4: Format Error Msg | X
a5: Domain Error Msg | X
a6: Field set to Default | X
a7: Truncated/padded | X
a8: Input accepted | X
a9: FIELD ERROR | X
This decision table reflects the outcomes of entering data into a text box field.
1) ROWS 1-4 reflect responses to errors
a) Wrong type of input characters (numeric, alpha)
b) Too much/too little data
c) Wrong format (layout, appearance, punctuation)
d) Illegal value
2) The last two rows address the selection of the default value, or the observation that the WRONG DEFAULT is being displayed.
3) The APPLICATION RESPONSE to these errors should include issuing an error message and other appropriate actions.
EL Jones
CCSC Tutorial -- Testing

30. TEXT BOX Functional TEST CASES (Generic)
Stimulus
Expected Response 1
Wrong data type
Data type error message 2
Good type, too short
Length error message 3
Good type, too long
Length error message, truncate 4*
Good type, length; bad format
Format error message 5
Illegal value only.
Value error message
The next step in the derivation is to DERIVE FUNCTIONAL TEST CASES from the decision table, following the process defined in the Unit Test Concepts session. 6
Non-Default value entered
ACCEPT value 7
Default value selected
ACCEPT Default value. 8
Wrong Default value displayed
UNEXPECTED: FIELD Error.
* Expand based on format syntax
EL Jones
CCSC Tutorial -- Testing

31. TEXT BOX Boundary TEST CASES (Generic)
Stimulus
Expected Response 9
GOOD: Length = minimum
ACCEPT field 10
GOOD: Length = maximum
ACCEPT field 11
GOOD: value = "minimum"
ACCEPT field 12
GOOD: value = "maximum"
ACCEPT field
The BOUNDARY TEST CASES apply to the attributes for which LIMITS APPLY -- field length and field domain (legal values).
NOTE: These conditions may not apply to all fields.
Tester sees only the Generic Test Cases, not
the process followed to derive them.
EL Jones
CCSC Tutorial -- Testing

32. CCSC Tutorial -- Testing
Calculate Dosage Form
PATIENT DOSAGE FORM
Account
Name
Calculate Dosage
Weight
Age
Recommended
Dosage
=> 12 and under
=> 13-65
=> 65-80
=> over 80
Clear
Save
Go Back
EL Jones
CCSC Tutorial -- Testing

33. DOSAGE CALCULATION FORM -- Specification
Field/Button
Description (Specification)
Patient Name
Name alpha/comma chars. Format: Last, First Middle
Patient Age
List box: {12 and under, (default), 65-80, over 80}.
Patient Weight
Weight in pounds. Whole number, in range
Dosage
Computed output field. Whole number, in range 0-5.
Calculate Dosage Button
Action button. Compute dosage based on Age, Weight, and display in Dosage field.
Consider the form with this specification.
1) THREE INPUT FIELDS
a) Text box for text data
b) List box
c) Text box for numeric data
2) ONE OUTPUT FIELD
3) Two ACTION BUTTONS
4) One FORM button -- Clear
5) One NAVIGATION button -- GoBack
Clear Button
Form button. Clear all input and output fields.
Save Button
Action button. Save form data to Trials Database.
GoBack Button
Navigation button. Return to previous screen.
EL Jones
CCSC Tutorial -- Testing

34. Your Turn -- Error Test Cases (Dosage Form Weight Field)
1. Use the Form Test Worksheet, Section A. 2. Complete the TextBox-Numeric Data template
a) Fill in FIELD NAME b) Create TEST DATA for each row. c) Complete the expected result -- at minimum, issue a message if an error occurs. d) If a test condition does not apply for the field, delete the row from the worksheet.
Now, create test cases for the Weight field.
This is also a text box, but because the data type is NUMERIC, certain test cases that were not applicable for the Name field ARE APPLICABLE for the Weight field.
EL Jones
CCSC Tutorial -- Testing

35. Weight Field Test Worksheet Text Box (Numeric)
When you get finished, we will view a solution (click on ARROW).
EL Jones
CCSC Tutorial -- Testing 5

36. Weight Field Test Worksheet
EL Jones
CCSC Tutorial -- Testing 5

37. Deriving Generic Test Case Specs for a List Box
Condition
c1: Wrong Data type | N
c2: Wrong Length | N
c3: Wrong format | N
c4: Invalid value | N
c5: Default selected | Y N -
c6: Wrong default value | N N Y
a1: PREVENTED | X X X X Action
a2: Field set to Default | X
a3: Input accepted | X
a4: FIELD ERROR | X
The data entry errors shown in RED are PREVENTED by list boxes -- because data entry has been replaced by DATA SELECTION.
Consequently, there are just THREE functional test conditions.
List boxes prevent these input errors.
EL Jones
CCSC Tutorial -- Testing

38. List Box: Functional/Boundary Test Cases (Generic)
Stimulus
Expected Response 1
Select Default value.
ACCEPT DefaultValue 2
Select k'th value from List.
ACCEPT ListValue_k 3
Wrong Default value displayed.
FIELD Error, no message. 4
First list item
ACCEPT first ListValue. 5
Last list item
ACCEPT last ListValue
Boundary test cases relate to the POSITION of values within the LIST OF VALUES.
* Boundary test cases.
EL Jones
CCSC Tutorial -- Testing

39. Your Turn -- Error Test Cases (Dosage Form Age Field)
a) Fill in FIELD NAME b) Create TEST DATA for each row. c) Complete the expected result -- at minimum, issue a message if an error occurs. d) If a test condition does not apply for the field, delete the row from the worksheet.
Now, create test cases for the Age field.
The test condition “DEFAULT VALUE SELECTED” should be expanded into TWO TEST CASES, since there are really two ways to select the default.
EL Jones
CCSC Tutorial -- Testing

40. Age Field Test Worksheet List Box
EL Jones
CCSC Tutorial -- Testing 5

41. Other Form-Field Attributes (Checklist Verification*)
Field-Level Test
Required Field
Input only access*
Output only access*
Input/Output access*
Visual appearance *
Form-Level Test
Data source
Data destination
Correlated fields
Tab/Cursor sequence *
We have shown how to test input fields designed as text and list boxes. A series of tests is used to test each field.
Other properties (indicated by *) can be tested via checklists. The checklist also provides a specification of required behavior of the form (e.g., tab sequence or cursor movement).
EL Jones
CCSC Tutorial -- Testing

42. GOOD NEWS! A FIELD IS REUSABLE!
Same field used on many forms
Most attributes are the same, so are the validation rules
Field implementation and test are reusable
Only form-specific attributes may change
We have shown how to test input fields designed as text and list boxes. There are other input field designs (also called controls)
a) List box permitting exactly 1 choice
b) List box permitting multiple choices
c) Radio buttons permitting exactly 1 choice
d) Check boxes permitting multiple choices.
NOTE: For testing purposes, a and c are equivalent, so are b and d; that is, the test worksheet templates have the same test conditions.
Insight: There are reusable test patterns based on field attributes.
EL Jones
CCSC Tutorial -- Testing

43. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

44. A button test is a black-box test.
Objective
Testing a button is testing a function that uses form input field data, and may produce form output fields. There may be additional stimuli and responses beyond those observable from the form.
A button test is a black-box test.
EL Jones
CCSC Tutorial -- Testing 5

45. Testing the SAVE Button
Identify stimuli and responses
Schematic diagram
Develop decision table
Ask questions about required behavior
Identify conditions for certain behavior
Develop test cases
Functional and boundary test cases
SAVE is an ACTION BUTTON. The effect of button is to take certain data from the form (the input fields only), and store the data in the Trials database.
Unlike input fields, developing test cases for buttons requires an analysis and design process.
1) ANALYSIS
a) Identify all stimuli and responses -- some will form fields, others will be databases, messages, etc.
b) Develop decision table relating responses to stimuli.
2) DESIGN test cases from decision table.
EL Jones
CCSC Tutorial -- Testing

46. SAVE Button Black-Box Schematic
Stimulus Type
Response Type
Argument
Argument
Name, Age, Weight
Error Msg?
Inputs
Outputs
SAVE
Button
Globals
Globals
1) STIMULI
a) Input fields of the form -- provide data that will be saved.
B) The database must exist
2) RESPONSES
a) Updates to the database
b) Error messages, if unsuccessful
c) Consider additional visual effects, such as cursor movement or color changes.
The next step is to determine the specific circumstances under which each response occurs, and to decide the specific values in each response .
Trials DB
Trials DB
Database
Database
Exception
Exception
EL Jones
CCSC Tutorial -- Testing

47. Asking the Right Questions
Preconditions?
Trials database OPEN and available
Form fields are valid
Postconditions?
Entry for patient in Trials database
#entries per patient?
How are entries stored?
Errors Detected, Messages?
Field data not valid
Unable to update, given field data
EL Jones
CCSC Tutorial -- Testing

48. SAVE Button DECISION TABLE
c1: Trials DB open | N Y Y Y Y Y
c2: Valid Age | Y Y N Y Y
c3: Valid Weight | Y Y N Y
c4: Valid Name | Y Y N
c5: Name already in DB | N Y
a1: "DB not ready" msg | X
a2: Save | X
a3: "Duplicate entry" msg | X
a4: "Invalid Field" msg | X X X
NOTE: (These notes optional -- may confuse)
(1) This is a compressed table that treats SINGLE ERRORS.
(2) The behavior when multiple errors occur at the same time is not reflected
(3) One interpretation is that checking occurs in the order, and checking stops on the first error:
(a) DB open?
(b) Weight valid
(c ) Name Valid>
(d) Duplicate Name?
(4) When the precedence is critical, this table should be expanded to specify responses to multiple errors.
* Impossible to have invalid Age: list box with default.
* (a4) Possibly a different message for each field.
EL Jones
CCSC Tutorial -- Testing

49. SAVE Button Functional Test Cases
Stimulus
Expected Response 1 1a 3 5 6
Trials DB not ready, good fields
"DB not ready" msg, no save.
Trials DB not ready, bad Name field
"??" msg, no save.
DB ready, duplicate Name
"Duplicate" msg, no save.
DB ready, bad Weight only.
"Bad Field" msg, no save.
DB ready, bad Name only 2
DB ready, unique Name
SAVED, no msg. 4x
Impossible -- drop
N/A
The SECOND test case conditions tests the occurrence of two errors -- DB-not-ready and bad-Name.
Other test cases handle zero or one error.
* Multiple errors: which one takes precedence?
* Infeasible test case, given list box!
EL Jones
CCSC Tutorial -- Testing

50. Your Turn -- Testing the CalculateDosage Button
Identify stimuli and responses
Schematic diagram
Develop decision table
Ask questions about required behavior
Identify conditions for certain behavior
Develop test cases
Functional and boundary test cases
EL Jones
CCSC Tutorial -- Testing

51. Your Turn -- CalculateDosage Button Black-Box Schematic
Stimulus Type
Response Type
Argument
Argument
ErrorMsg?
Age, Weight
Inputs
Outputs
CALCULATE
DOSAGE
Button
Dosage field
Globals
Globals
Database
Database
Exception
Exception
EL Jones
CCSC Tutorial -- Testing

52. Your Turn -- CalculateDosage Button -- Questions
Preconditions?
Form fields are valid
Initial value of Dosage field (e.g., blank)?
Postconditions?
Dosage field computed
No other fields updated
Cursor position
Dosage blank if error
Errors Detected, Messages?
Form field data not valid
Unable to calculate (Dosage field value: blank or ZERO?)
EL Jones
CCSC Tutorial -- Testing

53. Your Turn -- CalculateDosage Button Decision Table
c1: Weight = blank | Y N N
c2: Valid Weight | - N Y*
c3: Valid Weight | - N Y*
a1: Dosage = calculated #pills | X*
a2: Dosage field = blank | X X
a3: Error msg = "can't compute" | X X
a4: Cursor at Dosage field | X
a5: Cursor at Weight field | X
*NOTE: This table deals with the activation of the button in terms of visible form elements (input/output fields and error messages). Detailed rules for calculating the value are treated elsewhere.
EL Jones
CCSC Tutorial -- Testing

54. Your Turn -- CalculateDosage Button Test Cases
Test Data/Actions
Expected Response 1 2 3 4
Enter Name = "Doe, Joe"
Enter Default Age
Tab through BLANK Weight field
Enter Weight = 925
Enter Name = "Test, Joe"
Enter Age from functional test set
Enter Weight from functional test set
… Remaining functional test cases …
1." Invalid Weight" message
2. Dosage = blank
3. Cursor at Weight
1." Missing Weight" message
1. Dosage = computed value (from test case)
2. Cursor at Dosage
NOTE: These cases begin with form-level error handling for the CalculateDosage
button, and contains functional test cases from the Concepts session.
EL Jones
CCSC Tutorial -- Testing

55. Action Button Test Worksheet
EL Jones
CCSC Tutorial -- Testing 5

56. Button Testing -- Summary
Testing a button is easy when the test analysis has already been performed on the underlying function. The form expands the scope of the function to include visible fields and hidden effects (e.g., database updates).
The basic question remains "what should happen, and where should I look for it?"
Testing an action button combines a form-level test with the test of the underlying function.
The form level test relates to WHEN IS IT OKAY TO SELECT THE BUTTON, and WHAT VISIBLE HAPPENS?
The underlying function test relates specific values of form (input) fields to form output fields. Test cases for the function may be designed independently from the form-level tests.
EL Jones
CCSC Tutorial -- Testing 5

57. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

58. Form Testing -- Process
Perform field tests
Perform button tests
Form buttons*
Navigation*
Action buttons
Perform cursor tests*
Initial position, tab sequence, position after data entry or button activation
A BOTTOM-UP process for testing a form.
1) Start with the tests that can be done in ISOLATION
-- FIELD TESTS
-- FORM BUTTONS
2) Perform tests that require connection to other forms and to underlying functions
-- NAVIGATION BUTTONS
-- ACTION BUTTONS
-- CURSOR MOVEMENT
Some of these tests can be completed using CHECK LISTS.
* via checklist
EL Jones
CCSC Tutorial -- Testing 5

59. Form Test Worksheet: Cursor Movement & Navigation
Here is an example of a CHECKLIST for testing cursor movement.
NOTE: This checklist is a SPECIFICATION of required movement.
NOTE: This is a NEGATIVE CHECKLIST -- it is “tallied” (marked) when a specified MOVEMENT DOES NOT OCCUR
EL Jones
CCSC Tutorial -- Testing 5

60. Visual Properties Checklist
This checklist specifies a set of visual properties that must be satisfied by the form.
The list of properties reflects STANDARDS, BONDING and application look and feel.
NOTE: Even though the SAME STANDARDS may apply to all forms, use ONE CHECKLIST PER FORM.
EL Jones
CCSC Tutorial -- Testing 5

61. CCSC Tutorial -- Testing
Form Testing -- Set Up
Isolated Testing
Form visual attributes
Individual field testing -- validation
Integrated Testing
Form connected to other forms for navigation
Buttons connected to underlying code
Database connected
The set-up for form testing is less for isolated testing, especially when CLIENT-SIDE validation is implemented.
SERVER-SIDE testing requires some level of integration of the FIELDS with at least on BUTTON. Fields can be tested one at a time by providing VALID values for all fields but one, and varying the values of the remaining field.
RULE: TEST AS MUCH AS YOU CAN AS SOON AS YOU CAN!
EL Jones
CCSC Tutorial -- Testing 5

62. Form Testing -- Results
Perform tests specified on Checklists and Worksheets created during design, and record results
Form test worksheet
field test section*
buttons test section
Form test checklist
visuals
cursor movement
navigation
It should be clear that designing test cases goes HAND IN HAND with clearly specifying the behavior of the form.
You are provided with reusable templates that must be customized based on the specifics of the form being designed.
PLEASE NOTE: BE SURE TO INCLUDE TESTS FOR RELATED FIELD GROUPS (e.g., MALE answering FEMALE question). These are not included in the worksheet.
* Generic based on field type.
EL Jones
CCSC Tutorial -- Testing 5

63. Form Testing -- Summary
Form testing is a bottom-up process involving testing of visual properties, cursor movement, data entry and display, and actions triggered by buttons. Certain properties can be tested immediately; others require varying degrees of system integration.
Read as is.
EL Jones
CCSC Tutorial -- Testing 5

64. CCSC Tutorial -- Testing
Agenda
Purpose
Context -- Sample Project
Testing Issues -- Forms
Testing Fields
Testing Buttons
We now look at the products from the unit testing process.
Putting It All Together
For More Information ...
EL Jones
CCSC Tutorial -- Testing 5

65. Form Testing Worksheets
Template Set
Master template
Separate template for each form element
Website:
Preview Worksheets
The worksheet templates satisfy the goals of
SPECIFICATION driven
PREMEDITATION -- systematic design process
REPEATABILITY -- same templates used by all.
ACCOUNTABILITY -- the worksheet are a record of what was planned, what was tested, and what the results were.
ECONOMY -- the effort to design and execute tests is bounded. Expect it to reduce through reuse (copy, paste, edit).
EL Jones
CCSC Tutorial -- Testing 5

66. CCSC Tutorial -- Testing
THANK YOU
The worksheet templates satisfy the goals of
SPECIFICATION driven
PREMEDITATION -- systematic design process
REPEATABILITY -- same templates used by all.
ACCOUNTABILITY -- the worksheet are a record of what was planned, what was tested, and what the results were.
ECONOMY -- the effort to design and execute tests is bounded. Expect it to reduce through reuse (copy, paste, edit).
EL Jones
CCSC Tutorial -- Testing 5