Follow the complete task using test data
Start with the task that justifies the application and follow it from entry to the result someone uses. Work with data prepared for testing and check what is saved, what appears afterwards and what happens when returning. Opening individual screens does not establish that the journey works as a coherent whole.
Imagine an association building an application for activity registrations. The main journey might include choosing a session, entering the necessary details and checking the request status. To test it, you need to confirm that the selected session reaches the record the team will handle, with the correct information attached.
Then close the page and return to the request. If the information existed only while the form was open, the initial demonstration did not validate persistence. Compare against the expected result defined for the application, including the fields that need to remain available after the person submits the registration.
Try another journey with a relevant difference, such as a session with no places or a registration already recorded. Choose these cases according to the rule they exercise. You do not need dozens of purposeless scenarios, but you do need to check those that can change a user's or team's decision.
The criteria should come from planning the application before coding. If there is no clear answer about what should happen, record an outstanding decision. A test cannot resolve the ambiguity of a requirement that still allows incompatible behaviours or determine which of those behaviours the business should choose.
To prepare your next step, explore Security for applications developed with AI.
Check incomplete and invalid data
Tests should include missing information, values outside the rules and attempts to repeat an action. Confirm that the application explains the situation without saving an inconsistent result. Visible form validation helps the person, but the rules must continue to apply when the request reaches the system that processes or stores it.
In the hypothetical registration, check what happens when a required contact is missing or someone selects a session that has stopped accepting requests. The message should guide correction without presenting an unrecorded registration as complete. Also observe whether the other information the person entered is preserved when the problem appears.
For a submission action, test repetition that is relevant to your case. A person may click again because they did not understand whether the first request finished. The expected behaviour should prevent confusion between a legitimate new registration and a repetition of the same request, following the project's agreed rule.
Ask the agent to distinguish presentation tests from tests of rules enforced by the server. A disabled button can improve the journey while remaining insufficient as a control. The report should explain which behaviour was exercised, which input was used and what result was observed in each of the checks.
Use accounts with different responsibilities
Test access with the intended types of user and include someone who is not signed in. Check both permitted actions and those that should be refused. An administrator account cannot demonstrate the boundaries of other accounts because it may legitimately access information that those people should not be able to see.
In the association, a participant may need to consult their own request while the team organises all registrations for an activity. Prepare fictional records for two different people and confirm separation. The test should observe the data the system delivers as well as the options that appear in the menu.
Perform these checks in an environment you control and with test identities. Do not use real customer accounts to explore how far a failure reaches. The objective is to reproduce access conditions without exposing information or performing actions involving people who are not taking part in the validation process.
Before starting, confirm where the local environment sends requests. An application open on your computer may connect to real services. Preparing the environment and access for work with Claude Code should include identifying those destinations so a test does not produce effects beyond the space in which it is intended to run.
Observe what happens when a dependency fails
An application may work while every service responds yet fail confusingly when a connection slows down or becomes unavailable. Simulate those conditions in the test environment. Confirm that the user receives useful information and that the application does not present a conclusion it has not actually been able to confirm.
If the service saving the registration does not respond, the page should not display success simply because the form was submitted. You need to know whether the request is pending, failed or was recorded. That answer determines whether the person should wait, correct something or repeat the operation in question.
It also matters what happens when work resumes. A repeated attempt should not accidentally create duplicate effects, and a partial failure needs to be investigated. Keep enough information to identify the failed step while avoiding personal data or credentials that are unnecessary in the technical records used for that investigation.
The principle matches testing an automation before delivery: verify the normal journey and exceptions that change the outcome. A deliberate failure test can reveal more about the application's readiness than repeatedly following a path you already know works, particularly when the next user may encounter less favourable conditions.
Close local testing and identify what remains online
Before release, confirm that the delivery version passes the technical checks defined for the project and can be prepared without known blocking errors. Combine that result with behavioural tests. If a condition depends on hosting or an external integration, record it as awaiting validation in the environment where it actually applies.
Ask for a short list connecting each check with the version examined. Distinguish executed tests from recommendations still outstanding and points assessed only by reading the code. That distinction supports a decision based on available evidence instead of treating a general statement of approval as though it represented a complete review.
The public address, hosting configuration and connections between services may introduce conditions different from those on the local computer. Release therefore needs its own checks after the transition, using appropriate authorisation and data. Local success is a necessary stage in the defined process without replacing observation of the final environment.
If a failure affects the main journey, fix it and repeat the related checks before proceeding. With the evidence organised, you can explain what is ready, which limitations are known and what will be confirmed next. That clarity makes the decision to put an application online more responsible and easier to assess.