- Published
- Updated
Accepting a correct file demonstrates only the expected path. The handling of incomplete, duplicate or unauthorised inputs deserves separate attention when an interface carries data that matter to a study’s critical decisions.
Preserve the meaning of data
Link negative tests to realistic failure modes. Determine whether rejection produces an understandable message, record status and trace reaching an accountable owner. Users should know when a file is partly accepted. There is no universal choice between rejecting the whole delivery and accepting valid rows; define the appropriate behaviour for the intended use.
Worked example
For example, one laboratory row contains an unknown test code. The interface displays completed while silently dropping that row. The test includes both invalid and valid rows, compares counts and notifications, and examines resubmission behaviour. A visible error message alone is not treated as acceptance evidence if the resulting data state remains unclear.
Review checks
- Create examples with malformed fields, missing identities and unknown codes.
- Check for lost or duplicated records after partial acceptance.
- Test corrected resubmission through the complete interface flow.
Acceptance and boundaries
Acceptance means rejection or limited acceptance is explained as intended and the correction route remains traceable. Select examples representing critical workflows rather than generating arbitrary lists of errors. Evidence should identify the actual failed input and expected outcome. Negative testing complements, rather than replaces, checks that correct inputs can be processed successfully under the intended conditions.
Frequently asked questions
- Must every imaginable error be tested?
- Prioritise realistic, discriminating failure types linked to risk instead of attempting unlimited combinations.
- Does an error message mean the test passed?
- The resulting data state, evidence trail and behaviour after correction should also match expectations.