3.4.1 - Formative project skills: robustness and usability testing

Test the completed solution under difficult conditions

Robustness is the ability to handle adverse inputs or operating conditions in a controlled way, preserving the required behaviour and data. Final testing investigates the completed, integrated version. A developmental test may have shown that a helper worked before the GUI, storage and other features were connected; it cannot by itself establish how the final solution behaves.

In a miniature workshop sign-up tool, a booking accepts an integer group size from 1 to 24 inclusive. A rejected entry must leave existing bookings unchanged and allow the user to correct the input. Test more than whether the form accepts 8. Check the endpoints, just-outside values, malformed input and the state after rejection.

Choose further adverse conditions from the actual solution: an unavailable data file, a failed save, unusually long text or a large permitted dataset may be relevant. Expected failure behaviour must come from a requirement or a justified safety decision. A save failure should not display a success confirmation if nothing was saved. Catching an error and silently discarding a booking is not robustness.

Use disposable copies of data and a controlled environment when deliberately provoking failures. Record the exact final version, environment and starting state. A Python console helper can check numerical validation; genuine interface, storage and device behaviour needs a suitable external IDE or GUI environment. All assessed-project languages require a suitable graphical interface under the current specification; these small text exercises do not meet that requirement for you.

Observe users doing realistic tasks

Usability testing gathers evidence about whether intended users can use the solution effectively, efficiently and with adequate understanding. Functional correctness and usability differ: an Export button may produce a correct file, yet first-time users may not find it or understand its label.

Give participants from a relevant user group a realistic task, such as “Create a booking for three people, find its confirmation and export the attendance list.” State the starting state and what counts as completion. Use neutral instructions rather than pointing at the controls. Record whether the task was completed, errors, time if relevant, and assistance. A participant completing a task after you demonstrate every step has not demonstrated independent discovery of that journey.

Combine observations with feedback. Ask “What did you expect that button to do?” or “Where did you hesitate?” A leading prompt such as “Was the excellent new menu easy?” invites agreement and produces weak evidence. Preserve the participant's actual response rather than replacing criticism with a favourable summary.

In a supplied practice session, three of four new users found Export without help. The fourth selected Archive and required a hint; two said the icons were ambiguous. That supports a specific concern about discoverability. It does not prove that every intended user struggles, nor that every user is satisfied. State the small sample, relevant experience and any developer assistance when interpreting the result. A single favourable quote cannot outweigh recorded task failures.

Stakeholders or representatives of the target audience can provide useful feedback; this is not a rule that every project needs a contracted client or formal end-user sign-off. Match the users and tasks to the intended use. Testing a staff-only interface solely with its developer misses the unfamiliar-user perspective. Include keyboard use or other accessibility needs where relevant to the interface and audience.