Development Checklist
- James Seabrook
Checklist for design, requirements specification and implementation
User Awareness
The reason for a system being built is primarily to replace manual work and make life more efficient. This means a system must be
predictable
handle events gracefully
tell users exactly what is going on and what is expected
report successful outcomes
report unsuccessful outcomes with reasons
report uncontrolled errors in a graceful manner
Handling Unexpected Events
Unexpected events must be dealt with properly. This means that
every error which could happen is accounted for as far as possible
any error which occurs which has not been controlled can be shown to the user in a controlled way
Error Trapping
Error trapping has to be taken seriously for the smooth-running and predictable behaviour of an application. Anything which is done as part of a calculation where user-supplied values are involved, has to have the information validated properly and any unexpected calculation results relayed to the user.
Example - Product Size in SEKO 360
There have been problems where an email is not sent because the product dimensions have not been in the appropriate format. This could be either
because there was no validation and the process failed, or
because the process didn’t fail but there was a choice not to send the document
The product size is manually entered and the following must happen:
Product size field must be validated to make sure it has three values, separated by “x”
If the values are not separated by “x” then the product dimensions cannot be shown, but any screen or document should still be produced without them.
A failure in the product size validation should not cause a failure in the whole system
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 | Result |
|---|---|---|---|
On submission | Validation error | Form cannot be submitted | Validation error |
Email/report | Value too large | Display shortened value, keep processing | Data cut |
Email/report | Value too large | Controlled error back to user, stop processing | Fatal error |
Email/report | Format incorrect | Don’t show value at all, keep processing | No data |
Email/report | Format incorrect | Controlled error back to user, stop processing | Fatal error |
Addressee missing | Controlled error back to user, stop processing | Fatal error |
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):
https://bigdigit.atlassian.net/browse/WG-544
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 .