Guidelines for Test Case Structure and Writing

Guidelines for Test Case Structure and Writing

In general all test scenarios will be contained in a single test case document by type. If these test cases become too large, then test cases can be split into smaller documents. The goal is to have a manageable list of test cases for tracking and reporting purposes.

• Preconditions must be available for the test case

• All data requirements for the test cases have been identified.

• All the interface requirements for the test cases are identified

• Main Flow (which is denoted by "M" in place of "Z") - The main flow should outline the simplest happy path of the use case, it should avoid optional steps in main flow until the simple case has been executed. Main flow 01 typically will be the simplest case.

• All the alternate scenarios are addressed in test cases and denoted by AF01, AF02…etc in the test cases.

• All the Business Rules are addressed in Test case/ Design Steps

• All the Error Messages are addressed in the design steps

• All the interface related test cases are available.

PN: For interface related test cases we only check the feedback coming from the interface and feedback going into the interface

• When a use case is calling another use case only conditions required to fulfill the first use case will be tested in the second use case. Ex. Use case A calls a screen in use case B. In that screen user needs to fill up a form, click continue button to come back to use case A. Here the user will not do details validation checking of use case B.

• Negative Flows (denoted by "N") - The negative test cases, flows that return error responses

• User Interface (denoted by "U") - This test cases validates the user interface, this checks that the expected fields and field values are correct according to the Use cases, validated via the DB views or other external client systems. The following standard checklist will be used to write UI relates test cases:
UI Testing Checklist:

1. Check that mandatory fields cannot be left blank before moving on the process.

2. "For Date fields a Mask should be present to indicate one of the valid input formats :

• dd/mm/yyyy (e.g. 12/01/2006)

• dd/Mmm (e.g.""12/Jan"")

• Mmm/yyyy (e.g. ""Jan/2006"")"

3. Ensure javascript causes the / separators to be automatically added for date fields.

4. "Date fields accept only valid dates.

5. Check 29th Febuary for a leap year (2008) and non leap year.

6. Invalid dates include : 99/99/9999, 29/02/2005 or 31/04/2005

7. Today, previous & future dates are allowed unless otherwise specified.

8. All valid dates are allowed unless working days has been specified."

9. For Time fields a Mask should be present to indicate the valid input format which is hh:mm.

10. "Time fields accept only valid times of day.

11. Seconds are not required unless specified."

12. "Amount fields should only accept numerical values. (Numeric with 2 decimal places).

13. If no decimal point is entered it is assumed to be a whole number (i.e .00).

14. This format must be automatically enforced when the field is exited (ie the decimal places are put in for you)

15. Negatives and zero amounts are not allowed unless specified.

16. Ensure the maximum length is checked. It is assumed to be 16 (9,999,999,999.99) unless specified otherwise."

17. Ensure javascript causes the - separators to be automatically added for sort codes.

18. "Numeric fields (e.g. account number, sort code, telephone number) only accept numeric data. Should be positive, none zero unless specified otherwise.

19. Check minimum value, maximum value, negative value and zero."

20. "Rate fields (e.g. interest rate) only accept numeric data.

21. The % symbol can be entered but is ignored.

22. Should be positive, none zero unless specified otherwise.

23. Check minimum value, maximum value, negative value and zero."

24. "Text fields will accept all forms of text (Including alphanumeric, carriage return etc.) up to specified limit for the field. If the content is significant, a range of valid values will be tested.

25. Ensure fields hold values up to the maximum possible value. Always use capital Ws as these are the largest characters, and enter random alphanumeric characters (especially carriage return). Ensure that text can be entered in any case."

26. Radio buttons are mutually exclusive.

27. Tick box can be disabled as well as enabled and are not mutually exclusive.

Error testing:

28. Enumerated values - test values which are not legal for this operation

29. Numeric values - include just > maximum, just <>

30. "For text, include (as appropriate) invalid lengths, invalid contents

31. Supply null values (e.g. null strings) where these are invalid

32. Provoke all possible error responses / diagnostics where achievable using just input values

33. Ensure all errors are reported by either a javascript popup (where local validation is possible), or appear alongside an exclamation icon at the top of the page (where server validation is required).

34. Ensure null values can be entered where these are valid values."