As I presented in my last post, a lot of test coverage is either data-specific or triggered by data combinations. This is an easy kind of tests to automate assuming well-known and explicit inputs and outputs.

Below I enlist most common patterns and test ideas.

General Patterns

• All major business requirements (the ones that are explicitly documented) must be covered in isolation, with a minimum of one distinct test case.
• All implicit business requirements – the ones that are not documented but assumed, for example, – “application should reject non-existing dates”, “person’s age cannot be negative”, etc. – can be covered in groups but only if consistent “coverage density” is maintained and all targeted requirements are documented in test purpose field.
  Example: if testing for max possible string length in textual fields of person’s record, give max First Name, max Last Name, Street Address, etc, but the data of other kind (for example, credit card data) should stay generic – otherwise failure of one condition will mask other conditions under test.
• Use “one condition per negative test” rule to ensure that the application is capable to recognize and reject all of the invalid conditions. If multiple invalid inputs are provided in a single transaction, the application may reject it because it recognized some but not all.
• Unless it’s purely client-side functionality, a requirement cannot be considered fully covered if it’s not covered by at least two tests: one to create (successfully sending data to the back-end), one to retrieve and verify (using the previously input data as expected results). Recommended coverage scenario: Create -> Verify -> Modify -> Verify.

Coverage Types and Data Samples

1. Business Rules Coverage
• All distinct combinations of data used in calculations.
• Variable coverage: all fields, parameters, and variables that are transmitted between client-server components and stored in database. Ask developers for all important inner/interim variables affected by user input.
• For reports and all other types of queries: target stored procedures with boundary values, invalid parameters, too many results, no results, + query for just created, modified or just deleted records.
• Trigger all combinations of on-screen and back-end dependencies. Examples: checkbox enables/disables input box; payment rate is ignored if checkbox is set; etc.
• For negative tests: obtain from developers (and/or BA) full set of error messages for invalid data to reproduce each.
• All data combinations and workflows to set a business object in all defined states and try setting not allowed states.
• Use all pre-populated business data (i.e. create a record using each State or Province), and any other pre-populated or hard-coded data, especially if they trigger different code branches.
2. Values, Boundaries, Formatting, Special Cases
• Date
   Today’s date, Today’s +1, Today’s – 1
   Feb. 29 in Leap Year
   Feb. 29 in Non-Leap Year (negative)
   Always invalid days/months (negative)
   Two digit and one digit numbers (2010/9/30)
   Dates before and past Y2K
   Min. allowed (by requirements) past date, Min. allowed past date+1, Min. allowed past date-1 (negative)
   Max. possible (to enter) future date
   Min. possible (to enter) past date
   Right and wrong separator characters
   Mix of valid separator characters (2010/09-30)
   Mix of valid and invalid separator characters (2010/09.30)
   Special characters (“ ‘ ` | , ; : & < > ^ * ?(){}[]%$)
   Expressions instead of numbers (2020-10/09/30, 2E+3/09/30)
   Heading and trailing spaces
• Numbers
   Empty, Space, Zero
   Max integer, Max integer+1 (negative)
   Same for negative numbers
   Min. allowed (by requirements) number, Min. allowed +1, Min. allowed -1 (negative)
   Max. possible (to enter) number
   Min. possible (to enter) number
   High-precision data: every position after decimal point, rounding rules for .1, .4, .5, .6, .9; accumulated rounding error
   Floating point: values outside of business rules ($0.009)
   Empty field, space char
   Heading and trailing spaces
   Different magnitude
   Special characters (“ ‘ ` | / \ , ; : & < > ^ * ?(){}[]%$)
   Expressions instead of numbers
• Strings
   Empty, Space, EOL, EOF, Printer-control chars
   Min field length, max field length
   Multiple words, multiple spaces, web space character #160
   Different charsets (French, German, Chinese)
   Special characters (all keyboard specials)
   HTML-restricted characters and their codes (& & < < etc)
   In case of output to other systems and formats – their restricted characters and codes
   HTML injection, JavaScript injection, SQL injection