Testing web applications

An application built with AI: what to check before the first release

AI helped you build a web application, sign-in works and the main form can be submitted. Before inviting your first customers, however, you need to know whether the application completes their work correctly, preserves data and keeps account access separate. This guide is for a founder or small team with a working prototype who needs clear evidence to make a decision about the first release.

What a successful demonstration does not yet confirm

During a demonstration, you usually use a prepared account, valid data and a familiar sequence of steps. A customer may submit a form twice, return to an unfinished task or open a link from an old email. The transitions between screens, stored data and external services need their own checks.

Where code came from does not, by itself, determine its quality. During rapid development with AI, it is useful to record product rules outside the conversation with the assistant: who may do what, what should be saved and what should happen when something fails. GitHub notes that generated suggestions may not match the developer’s intent and recommends reviewing and testing the code. GitHub Copilot documentation.

Treat an AI explanation that a feature has been fixed as a description of the change. Confirm the result by repeating the original scenario and checking its expected outcome. Otherwise, you may miss a situation where the error message has disappeared but data is still being saved incorrectly.

Worked example: appointment booking for a small studio

Imagine a website where a customer books a consultation. They have their own account, choose an available slot, receive an email confirmation and can later cancel the booking. A staff member manages availability and sees customer bookings. This is an illustrative example of the approach, not a report of results from a particular project.

Agree on the rules before testing: each slot accepts one booking, customers see only their own records and cancellation makes the slot available again. If email is unavailable, the booking should remain saved and the team should know about the unsent confirmation. If your rules differ, adjust the expected results before checking them.

Prepare two customer accounts, a staff account and several test appointment slots. Use a separate test environment and email addresses controlled by the team. Record the application version and integration settings so that a finding can be reproduced later.

Follow the complete user journey

Start with the link a new user receives and continue through to the completed outcome. For a booking, this means registration, sign-in, slot selection, confirmation and reopening the booking. Also check sign-out, signing in again and cancelling the appointment. At each step, observe whether the user can understand the current state and continue.

Try signing in with an incorrect password and after the login session expires: this is the period during which the system considers the user signed in. A form in progress must not suggest that saving succeeded if the server rejected the request. If the product offers password recovery, check the whole process, including following the link from the email.

For each scenario, record its starting conditions, steps and expected result. Replace “booking works” with a verifiable description: one record is created with the correct customer and appointment, it is visible in the account and the staff member can find it in their list. This description can support both manual checks and automation.

Check the data after reloading the page

A “Saved” message alone does not confirm that a change reached persistent storage. Reload the page, sign out and open the booking again. Compare the appointment, customer, status and time information. Then check the same record from the staff account. If the results differ, investigate both reading and saving the data.

Try editing the record, cancelling and submitting the form again. Two browser tabs or two accounts may try to book the same slot simultaneously. Under the rules of the example product, only one booking should succeed and the other user should receive a clear explanation. Hiding the occupied slot only after the page is refreshed is insufficient.

When recording a finding, include the booking identifier, the time of the attempt and both outcomes. The person checking the server or database can then trace the specific operation. Use test data in the bug report so that sharing it does not require exposing customer information.

Permissions must also be enforced on the server

A hidden administration button is not evidence that access is denied. Permissions must be enforced on the server for every request involving protected data or an operation. OWASP explicitly warns that a browser-only check must not decide whether access is granted. OWASP Authorization Cheat Sheet.

In the example application, create a booking with account A and try to open it with account B using a direct link. Check reading, editing and cancellation. The same rules must apply to a direct API request: the API is the interface through which the website communicates with the server. Assign this part to someone who can prepare and evaluate the request.

Also check a visitor who is not signed in and an ordinary account attempting staff operations. The operation should be refused without exposing or changing another customer’s record. Functional permission checks help verify product rules; they do not replace a security audit of the application and its infrastructure. The necessary scope of a security assessment also depends on the data processed and how the application is deployed.

Deliberately test failures and integrations

Check an empty required field, an invalid email address, an already occupied slot and a connection interrupted during submission. Observe the message, what remains saved and whether the user can sensibly retry. When the outcome is uncertain after an outage, another click should not create a second booking for the same operation.

For the email service, distinguish between saving the booking, handing the message to the provider and delivery to the test inbox. Then prepare a case where the service rejects the request or does not respond within the expected time. Check the booking status and the information available to the team against the agreed rules. If the application receives notifications back from the service, also try repeated delivery of the same notification.

Some responses can be simulated with a substitute for the service, known as a mock. Also check the real integration in the provider’s test environment, if one is available. The differences and limitations are covered in mock, sandbox or real service. Direct test emails to your own inboxes and avoid creating real customer bookings during these checks.

Try the customer’s device and method of interaction

Follow the main journey on a phone and a computer, using the browsers you intend to support. On smaller screens, look for obscured buttons, problems with date selection and error messages. Try operating the form with a keyboard: the user should be able to track the active element, complete the fields and finish the booking. These basic accessibility checks complement functional testing; they do not, by themselves, confirm the accessibility of the whole website.

Create a repeatable minimum before release

Build the initial suite from scenarios you already understand. Keep the written steps and expected outcomes, and focus automation on checks you will repeat after further changes. A useful starting point for the example product is:

• signing in and creating one booking;
• checking the saved record after loading it again;
• refusing access to a second customer;
• cancelling a booking and making the slot available;
• repeated submission and failure of the email service.

Prepare each automated test with its own data and a known starting state. It should not depend on a booking created by a previous test. The Playwright documentation also recommends independent tests because they make reproduction and failure diagnosis easier.

Some checks can go through the website, while others verify rules directly through the API. The choice is discussed in which test scenarios to automate first. Run the suite using the same procedure and save the results with the application version. For each important bug fixed, add a check that also verifies the original failing situation.

What should stop the first release

Agree on priorities based on the consequences for the user and the ability to recover. Decisions for the example application might look like this:

Decide using results you can reproduce

Before deployment, record what passed, what failed and what was outside the scope. Name the person responsible for the decision and the checks after deployment. Prepare a response to problems, including data recovery; reverting to older code alone may not repair incorrectly saved records.

This gives you a concrete view of application readiness and a foundation for subsequent releases. The next step is to select one main user journey, write down its rules and follow it with two separate accounts. The findings will show which fixes and automated checks deserve priority.