Equivalence Class Partitioning and Boundary Value Analysis

Overview
Many functions have an almost infinite number of input values. Testing all of these values is not possible in most cases, and doesn't necessarily tell us more than testing a few values. How do you choose the best values to test? Equivalence class partitioning can be used to divide the test inputs into classes so that each class contains the same kinds of input (in another word, you may only need to test one input from each class), thus reducing the number of test cases to a manageable size. The task is to use Equivalence Class partitioning and Boundary Value Analysis (which means to test the input at the boundary of the equivalence class partition) to analyze the valid and invalid inputs for Microsoft WinWord or any other software package that you have installed on your computer. If you choose to test different software than WinWord, please make sure that the software has several functions for user input (e.g., the zoom menu that needs user input or the search/replace menu).
Identify categories
First you need to identify a list of function/menus that you need to test. For each function, identify one or more input categories that apply to it. Please focus on functions that require input values.
Define valid and invalid classes
For each input category identified, define the valid and invalid equivalence classes. Do not specify a test case or specific test input value for the equivalence classes; specify the entire equivalence class.
Define sub classes
If appropriate, divide each valid equivalence class into sub-classes based on how the software interface handles the input.
Identify boundaries
For equivalence (sub-)classes that have boundaries, identify boundary values for the boundaries between valid and invalid classes, or between valid sub-classes.
For lower bounds, specify a set {first invalid, lowest valid}; for upper bounds, specify a set {highest valid, first invalid}.
Do not specify a test case; just specify the boundary values as shown.

Document results
Document your results in a table, as follows and submit it to the hand in assignment folder by the deadline: Note: please follow this table format, to facilitate evaluation and ensure the grader has a favorable attitude toward your work.
Input Input Type Valid Equivalence (Sub-)Class Invalid EC Lower Bounds Upper Bounds
switch enum {-s, -n, -c} not {-s, -n, -c} N/A N/A
number of switches card [0, 1] [2, infinity] {N/A, 0} {1, 2}
time_t range [0, 2^^32] [-infinity, 0], [2^^32, infinity] {-1,0} {2^^32, 2^^32+1}
time_t before millennium range [0, 946713599] (sub-class) {N/A,0} [946713599, 946713600]
time_t after millennium range [946713600,2^^32] (sub-class) {946713599, 946713600} [2^^32, 2^^32+1]
date string constraint conforms to parsedate(3) spec complement of valid N/A N/A
Notes:
• Indent sub-classes from their parent. Also, mark the invalid column ``(sub-class)'' for sub-classes: sub-classes do not have an associated invalid class, because by definition all sub-classes are valid.
• Use ``N/A'' to indicate that a column does not apply.
• The examples shown above are only intended to illustrate the table format to use; they are not exhaustive (or necessarily correct).

Appendix: Equivalence Class and Boundary Value Analysis
1. Terminology
Test Case
Specification of
1. environment
2. inputs
3. expected results
Test or Test Procedure
Test case(s) plus instructions for running them:
1. set-up
2. execution
3. evaluation
4. tear-down
Implementation of one or more test cases.
Test Suite
Collection of tests. We make a distinction between tests and test suites because of shadowing and granularity.
2. Design Issues
Shadowing
Test A shadows B if
• B depends on results of A and A fails.
• B follows A and A corrupts the environment somehow.
Granularity
This is a measure of how many test cases a test contains.
• Valid input tests should be large to reduce overhead: we expect them to succeed.
• Invalid input tests should have one case, as we expect the system under test to report an error at least, perhaps halt or fail gracefully.
Strategy
Requirements-based
Black box testing, cases derived from requirements specification.
Function-based
Black box testing, cases derived from functional specification.
Internals-based
White box testing, cases derived from design or code.
Coverage
A measure of test suite completeness, in terms of
• requirements tested;
• functions tested;
• code statements, branches, conditions, paths executed.
3. Test Case Development Methods
• Happy Path
Input values chosen from those known or expected to work.
• Equivalence Class Partitioning
Divide the input into equivalence classes.
1. Identify equivalence classes for each input type.
 Range - one valid, two invalid classes.
Year between 1902 and 2038
 Number of inputs (two to four args) - one valid, two invalid classes.
Recurring type entries shall have exactly three fields.
 Set (enumeration) - one valid class (the set), one invalid class (the set complement).
Weekly, Monthly, Quarterly type.
 Exists/constraint (must be) - one valid class (input satisfying constraint), one invalid class (input not satisfying constraint).
Start date must precede End date.
 Sub-classes - an equivalence class should be divided into sub-classes if we believe (or suspect) elements of a given EC are handled differently by the program.
2. Write test cases to cover each valid equivalence. Combine these into as few tests as possible.
3. Write test cases to cover each invalid equivalence class. Specify a separate test for each of these.
• Boundary value analysis
1. (Optional) Define output ECs, according to the criteria above
2. Define test cases for the boundaries of each EC:
 Range, Cardinality
Test case one before, at, one after boundary.
 Set, Constraint
No boundaries, so choose a representative from each.
• Error Guessing
Test designer uses skill and experience to devise test cases to uncover errors.
o null input.
o long input.
o random input.
o almost correct input.
 spaces in strings.
 quoted strings.
 all CAPS.
o negative numbers.
4. Deriving Test Cases from Test Outline
Following outline paths from major nodes to leaves, define test cases for each leaf:
• Id
• Outline leaf number
• Input state
dateconv: command line switches: "+1 -5"
• Input data
dateconv: "12:59:59 GMT Dec 31, 1999 The Eve of the Millenium"
• Expected results
dateconv: "946645199"
• Actual results
dateconv: "12:59:59GMTDec31,1999 The Eve of the Millenium"