Guidelines, hints/tips for test design at L2
| Level | Input interface cleanliness |
| Objective | To ensure that the interface through which the inputs are accepted is clean. The interface can be a GUI, API, Command line etc. |
| What to test | EUT at this level can be a screen, form, an API that is invoked with some inputs from another system, an API that is invoked from the command line. |
| Test for what | Typical issues looking for at this level are interface related issues. For a GUI, issues like layout of the screen, placement and grouping of elements in the screen, font/color/size, spelling mistakes, enable/disable behavior of screen elements etc and for API, issues like number of arguments, order of arguments, type of arguments, return type and accessibility of the API etc will be targeted at this level. |
| Design guidelines | Since the objective is to validate for the cleanliness of the interface through which the application accepts inputs, it is mandatory to know about the type of interface (GUI/API), the expected elements in the screen, the layout, other interface specifications like styling to be used for the screen etc for the GUI and signature of the API, if the interface is an API. |
| Hints/Tips | At this level, typically no need to write design scenarios/cases explicitly. Understand the interface specification and think of the possibility of potential issues as mentioned above and then come up with a check list with applicable issues to be looked for based on the context of the application. Run through this check list with all the applicable screen/API and ensure that such issues are not escaped to the later stages. |