Accept custom software: assess complete tasks and agreed boundaries

Agree beforehand what the trial should demonstrate

Translate the assignment into recognisable outcomes. A customer views a delivery proposal and confirms a valid time window. A planner subsequently sees exactly which arrangement was recorded. An unauthorised user cannot access the enquiry. These statements help select input, roles and states. They also identify where showing separate screens does not yet demonstrate the complete task that the project was intended to support.

Distinguish a first-release requirement from a later wish. Otherwise a review can turn into a fresh inventory of everything users might someday want. Keep new ideas without silently replacing assessment of the current agreement. The goal is to establish what was demonstrably delivered and how observed discrepancies affect the selected task, rather than allowing either party to redefine the original result after seeing the application.

Give each case an expected final result

A useful case contains a starting situation, operation and observable outcome. For example, a fictional customer with one open proposal chooses an available slot, after which the same reference shows a confirmed appointment. Describe the outcome before execution. Otherwise a team can retrospectively explain any observed behaviour as reasonable even when users needed something different from what the application happened to produce.

Assess behaviour users actually observe and use. Playwright presents that as a technical testing principle. For project acceptance, this does not require every check to use one particular tool. The customer sees confirmation, the planner can retrieve it and an accountable operator can investigate a failure. Select an evidence route suited to the outcome being assessed instead of treating the chosen testing technology as the definition of success.

Playwright: Best Practices ↗

Use information exposing important distinctions

A trial containing only one simple customer may miss important boundaries. Include two organisations, an enquiry with missing information and a revised proposal. Use safe fictional records representing different meanings and explain why they were chosen. A large volume of random information is less useful than a bounded collection exposing the decisions that materially shape the design and its intended use.

Check trial-environment preparation as well. Which accounts, versions and connections apply? Reviewers working unknowingly with different information can report apparently contradictory findings. Retain relevant references and arrangements without putting access secrets into ordinary reports. A later correction or change investigation can then recognise the same business situation and review it deliberately rather than attempting to reconstruct a disappearing test environment from memory.

Existing software may need a bounded investigation before useful acceptance criteria can be agreed: Scoping a software audit: which decision should the evidence support?.

Let the appropriate roles perform the task

An administrator account often has more authority than an ordinary customer or employee. Use roles matching daily operation. A customer confirms an arrangement, a planner proposes a change and support investigates an alert. Check that information and next steps are understandable without the original developer explaining every operation while the user performs it. Observe where actual users need help or interpret the same instruction differently.

Include a refused operation too. A customer from another organisation must not view or alter the appointment through a direct reference. Assess the operation’s result rather than only button visibility. This combines normal usability with important agreed process boundaries, without suggesting that a small acceptance trial replaces a complete security assessment. Record what was tested and what other examination remains necessary under the project agreement.

Assess changes, repetition and uncertain outcomes

Work through a proposal changed after review. Does the earlier confirmation still apply, or is new approval needed? Test a double click or repeated submission where it could produce the same business action twice. Describe what the user sees and what the planner finds stored. Together these checks help prevent a convincing interface from concealing a different business state in the underlying records.

Select an appropriate failure situation too. An external planner might save a change while confirmation is lost. The application should support the agreed investigation or recovery path. Projects differ in integrations and consequences, so choose cases from the actual assignment. A general catalogue of every imaginable interruption can enlarge acceptance without providing better decision evidence about the particular task and responsibilities being introduced.

Review explanations, mobile use and interaction

Ask people to perform important tasks on genuinely relevant devices. Examine long text, failure messages, file selection and the position of the next action. A technically submittable form with confusing instructions can create substantial support work. Ask users what they expect an operation to do and compare that expectation with the actual result, rather than judging usability from a polished demonstration alone.

Include suitable accessibility checks, such as keyboard use, visible focus and understandable labels. W3C WAI presents preliminary checks as a starting point rather than a complete assessment. Record what was examined and what additional expertise or evaluation is agreed. A successful mobile screenshot or short keyboard exercise should not be represented as proof that every user can perform every task without barriers in all relevant circumstances.

W3C WAI: Easy Checks — A First Review of Web Accessibility ↗

Make each finding investigable

A useful report identifies version, role, starting reference, operation, expected outcome and actual behaviour. Include appropriate evidence only. “The portal is broken” can describe many things; a missing appointment following a particular selected slot can be investigated directly. Explain business impact so the team understands why that case does or does not prevent the initial task from being used under the proposed conditions.

Separate a defect from a new wish or ambiguous agreement. Classification may require joint investigation; it is not a way to dismiss awkward observations. Identify who resolves substantive interpretation and how the developer explains technical cause. Associate the report with the trial case so a correction is checked against the same outcome, instead of merely confirming that a screen looks different after the developer has changed it.

Decide explicitly about unresolved work

An acceptance decision can confirm some demonstrated tasks while identifying others needing correction. For each open finding, record its consequence, temporary working route and next review. A broad approval without context may create different expectations among the customer, users and whoever takes over operation or support. Explain which observed limitations were accepted and which still prevent the agreed use of the version.

Determine whether those limits justify delaying a phase or narrowing the first user group. That decision belongs to the accountable customer, based on understandable evidence and explained consequences. Acceptance is not a ceremonial endpoint where every issue disappears. It is a traceable decision concerning a particular version and a bounded way of using it, with responsibility for unresolved matters still visible after the meeting ends.

Retain the cases for future changes

After initial acceptance, select cases protecting important boundaries. Reuse them when information, permissions, states or integrations change. A text correction need not rerun every original exercise, while confirmation changes may affect several roles and exceptions. The relationship between a modification and selected reassessment should remain understandable to people who join the project later rather than existing only in the original developer’s judgement.

Deliver trial information, expected outcomes and known limitations in a form the organisation can use. Agree who updates them when working practices change. Acceptance then becomes part of responsible development rather than an isolated historical report. Another developer can understand which behaviour was deliberately agreed, what discrepancy was found before and which check matters after a particular modification. That continuity makes future decisions easier to explain and assess.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic

Continue with a related question