Checklist for design, requirements specification and implementation
Error Categorisation
What should stop an email being sent?
What sort of response should there be if there is an error and the checklist cannot be sent?
Stage | Error | Action to take | Criticality |
|---|---|---|---|
Prior to submission | Validation error | Form cannot be submitted | Critical |
Email/report | Value too large | Display shortened value, keep processing | Not critical |
Email/report | Value too large | Controlled error back to user, stop processing | Critical |
Email/report | Format incorrect | Don’t show value at all, keep processing | Not critical |
Email/report | Format incorrect | Controlled error back to user, stop processing | Critical |
Addressee missing | Controlled error back to user, stop processing | Critical |
Example 27th September 2022 - Pre Alert
Pre-Alert not sent
Pre-Alert was not sent out because the product size returned from SEKO 360 was invalid. The requirements stated that if there was not an “x” (case sensitive) between the product sizes it shouldn’t be shown in the documentation. (It didn’t state that the email should not be sent):
WG-544 - Getting issue details... STATUS
Requirements states: If the ProductSize field does not contain “x” between the dimensions it should not be included in the documentation. [Although this was not in the acceptance criteria]
Booking Confirmation not sent
The “Floor location” value length was greater that the value allowed so an error occurred and the email was not sent. This needs to be dealt with.
Uncontrolled Error Handling
Errors which are uncontrolled perhaps because
they are controllable but not yet covered by code, or
cannot be controlled at all even with code
Simple Testing Strategies
On UAT so that user can test the next stage:
Using Swagger, allow user to add a record with a particular status
Using Swagger, allow a user to change the status back regardless of the data integrity .