Fast, Easy to Use and Secure

A usable condition names the quality sub-characteristic, the operation, the conditions of measurement, and a measurable outcome.

Performance efficiency - three sub-characteristics, not one:

• Time behaviour: 'Searching for a patient's open appointments returns results within 2 seconds at the 95th percentile, measured under the peak load profile defined below.'
• Resource utilisation: 'Application and database CPU stay below 70% sustained at peak, and memory does not grow monotonically across a 4-hour endurance run.'
• Capacity: 'The portal supports 20% above modelled peak without exceeding the response-time target.'

Usability - five sub-characteristics, and 'easy to use' maps to more than look and feel:

• Learnability: a new receptionist books, moves and cancels an appointment unaided after a 10-minute briefing.
• Operability: no task in the top-10 task list requires more than N interactions or a keyboard/mouse mode switch.
• User error protection: cancelling an appointment requires confirmation and is reversible for 24 hours.
• Accessibility: the booking journey passes WCAG 2.1 AA checks, including keyboard-only operation.

Security - expressed as conditions the test analyst can verify, not just 'secure': authentication and session timeout, authorisation (can a receptionist at site A see site B's patients?), input validation and injection resistance, protection of patient data in transit and at rest, and audit logging of every record viewed.

A condition with no measurement condition cannot produce a pass or a fail, which means it cannot be reported on.

What I would tell them: 10 users is not a load profile - it is a smoke test. It has no relationship to 4,000 staff, no transaction mix, no think time and no pass/fail criterion, so a 'feels slow' result cannot be defended either way.

How to build the profile. The interesting number is not headcount, it is arrival rate per transaction type.

• Bookings: 9,000/day, 60% between 08:00 and 09:30 - about 5,400 bookings in 5,400 seconds, so roughly 1 booking per second average across the window, with the real peak above that. Staff do not work at a steady rate, so the profile must model a burst, not a flat line.
• Browse traffic is the volume driver. Looking at schedules, checking a patient, then booking means read transactions may outnumber writes several-fold. A profile built only on bookings would under-load the database badly.
• Transaction mix and think time: receptionists pause between actions; a load tool driven with zero think time manufactures a load the real system will never see, and measures a bottleneck nobody will hit.
• Shape: ramp-up, sustained peak (at least 60 minutes, not 3), and a separate spike test above the peak to see how the system degrades and recovers.

Acceptance criteria are agreed before the run and expressed per transaction, at a percentile, not as an average - a 1.9-second mean with a 12-second tail is a bad system that reports well. Error rate under load (target under 0.1%) matters as much as speed, because a fast wrong answer is still wrong.

If real production-like volumes cannot be estimated confidently, that uncertainty is itself a test condition to record - and a reason to test well above the estimate.

Usability without a lab

• Heuristic evaluation by two or three reviewers against a checklist (Nielsen's heuristics or an internal one) - cheap, finds genuine problems fast, but the evaluators are not representative users and will miss domain-specific friction.
• A small moderated user test: 5–8 actual receptionists, realistic tasks on realistic data (not dummy names), measured by task completion, time on task, error count and a satisfaction score. This is the highest-value activity available to you.
• Checklist-based accessibility review with keyboard-only and screen-reader passes.

Limits to state openly: a sample of 5–8 finds problems but does not support statistical claims; there is no controlled environment, so results are indicative; and a passing heuristic review is not evidence of usability, only absence of the defects the heuristics cover. Record it that way in the summary report.

On the penetration test

It cannot be the security strategy for three reasons:

1. Timing. One week before go-live leaves no time to fix and retest anything serious. A finding then becomes a risk-acceptance conversation, not a defect.
2. Scope. A pen test attacks what it can reach in the time available; it does not systematically cover authorisation across roles and sites, audit logging completeness, or session handling - all of which are test conditions you can design and run now.
3. Ownership. The test analyst designs security test conditions and, where the team has the skill, executes functional security tests. The pen test is a complementary specialist activity, not a substitute.

I would raise the pen-test booking to earlier in the schedule as a scheduling risk, with the impact stated in business terms.