Guidelines, hints/tips for test design at L1
| Level | Input cleanliness |
| Objective | To ensure that invalid input data are rejected gracefully. |
| What to test | EUT at this level can be any structural component like a screen, API, class, service, or a task. Here we are not considering the entire ‘unit’ as an entity. |
| Test for what | Typical issues looking for at this level are validation issues for the input data. Issues like data type issue, data format issue, data boundary issue, data dependency issue etc will be targeted at this level. |
| Design guidelines | Since the objective is to validate for the rejection of invalid input data, it is mandatory to know about the inputs used by the EUT and the data specifications like type of inputs, accepted limits, expected input format etc. These information may not be available as a detailed document, in that case, get these information by discussing with the concerned people or exploring the application. |
| Hints/Tips | For each input data, identify the wrong/invalid set of values based on the specification and design scenarios/cases to ensure that the invalid data are rejected gracefully by the application. We can come up with a set of test cases as check list that can be executed for similar kind of inputs, instead of design for each input of same type. Same type inputs means inputs that accept text, numeric, date etc will have a common set of issues that need to be validated against each. |