How to Test an AI-Created Web Application: A Checklist of Features and Hidden Shortcomings

Testing an AI-created web application covers launching, navigation, features, data, and user scenarios. A visual inspection is not enough. A polished screen confirms the presence of markup and styles, but does not show whether the application saves files, handles errors, or carries the user's action through to a result.

In the author's experiment, the AI independently launched a local server for a browser-based operating system. The interface opened search, projects, and images; the dark theme, task list, focus timer, and temperature converter worked. Music files did not open. Notes allowed an existing file to be edited, but did not allow documents to be created or deleted, and the full-screen button did not work in the places tested.

Testing a web application starts with launching it

The first question is simple: can the application actually be opened and used in the stated environment? Record the launch command, local server address, port, browser, operating system, and console state. After reloading the page, check whether the interface remains intact and whether data the user has already entered disappears.

A successful launch is not limited to displaying the start screen. The user should be able to open the main section, move between screens, go back, and repeat the action after refreshing the page. If the interface loads but navigation produces a blank screen, a console error, or a loss of state, mark the result as partially working.

Minimal launch scenario

• Open the application in a clean tab with no pre-existing data.
• Check that the main screen and all visible menu items load.
• Refresh the page on the start screen and inside a separate section.
• Open the application in another supported browser if compatibility is part of the task.
• Inspect the developer console and record errors, warnings, and failed network requests.

What should you do if the local server starts on its own but some features do not respond?

Such a launch should be considered technically successful, while product testing continues separately. The AI's ability to set up the environment saves developer time, but does not replace acceptance scenarios.

A feature table shows the difference between a demo and a product

Compile a list of all features visible in the interface or promised in the description. For each feature, specify the exact result, input data, and expected state after the action. The phrase “works” is too general. It is better to write out the entire scenario: the user enters 30 degrees Celsius, clicks the conversion button, and receives 86 degrees Fahrenheit.

The status “partially works” is needed for cases where a button responds but does not complete the scenario. Notes allowed an existing file to be edited, but the experiment's author found no way to create or delete files, add files, use a save button, or create a new document. The feature looks ready on screen, but does not fulfill the basic task of working with notes.

File operations need to be tested separately

File features often conceal the most serious shortcomings of AI-generated applications. A file list alone does not mean that the application can manage data. For each object, check the complete set of operations: open, create, edit, save, rename, delete, and undo changes.

1. Open the source file and make a noticeable change.
2. Go to another section and return to the file.
3. Refresh the page and check whether the change was saved.
4. Create a new file with a unique name.
5. Delete the test object and check that it disappears from the list.
6. Try to undo the deletion or close the editor without saving.

If the application displays a save button, it should change the state of the data, not merely close the window. After saving, verify the result by reopening it, refreshing the page, and navigating from another section. For a local prototype, data may be stored in the browser, in the process memory, or in a separate file, but the user-facing result should be clear in every case.

Test unsupported formats separately. In the experiment described, music files did not open, even though the browser-based operating system interface created an expectation of full file support. In the report, specify which extensions are supported, what happens with an unknown format, and whether the user receives a clear message instead of a silent failure.

Navigation and interactive elements reveal hidden errors

A button should have a verifiable effect: open a screen, change a value, start a process, or display a message. Click every visible button several times, repeat the action quickly, close the opened window with the Escape key, and return to the previous screen. This scenario reveals handlers that work only on the first click or leave the interface in an intermediate state.

Full-screen mode requires separate testing because browsers do not allow it under all conditions. A web application typically calls the requestFullscreen method on an element after a user action and exits through exitFullscreen; a successful transition can be tracked using the fullscreenElement property and the fullscreenchange event. The browser may also refuse full-screen mode because of compatibility restrictions, permission policy, an embedded frame, or the absence of a user gesture. The application should handle the rejected promise and display a clear status.

If the full-screen button did not work in any of the places tested, record it as a functional defect rather than a minor visual inaccuracy. Testing should include clicking the button, clicking again to exit, launching it from different sections, and using the browser for which support is claimed. The browser's full-screen mode, enabled through a separate browser command, is not the same as the web application's full-screen mode and does not prove that the button works.

A game scenario tests logic, not just clicks

Games and interactive mini-applications are convenient to test because their rules are easy to formulate. In tic-tac-toe, check game creation, turn order, prevention of moves in occupied cells, win and draw detection, restarting, and behavior when clicking again. If a player can play only against themselves, the interface displays a game board but does not provide the claimed competitive scenario.

Test more than the happy path. Make a move in every available cell, try clicking an occupied cell, finish the game, and start a new one. For games with an opponent, record separately whether there is a second player, a computer opponent, or only a decorative mode-selection button. The experiment's author rated the tic-tac-toe game as limited precisely because it could only be played alone.

Visual integrity does not confirm that an application is ready

Consistent colors, icons, and a neat grid create the impression of a finished product, but visual integrity relates to only one layer of testing. In the experiment described, the author positively assessed the design and selection of icons, but considered the browser-based operating system too simple and insufficiently functional. This conclusion applies to the specific test scenario and does not become a universal assessment of all AI-created applications.

Practical readiness is determined by four linked characteristics: the feature is accessible, the action is performed, the result is saved, and the error is explained to the user. If at least one element is missing, a polished interface conceals incompleteness. This happens especially often in prototypes where the AI creates a screen with the expected elements but does not implement server logic, state storage, or exception handling.

How to format the list of improvements

Record each problem as a reproducible defect. The title should describe the action and result, not a general impression: the full-screen button does not switch the workspace to full-screen mode after being clicked from the Notes section. Add the environment, sequence of steps, expected behavior, actual result, and priority to the report.

• Critical defect: the application does not start, loses data, or blocks the main scenario.
• High priority: a key feature does not work, such as creating or saving a file.
• Medium priority: the scenario is available but works only partially or requires a workaround.
• Low priority: an issue with styling, text, spacing, or a secondary animation.

After fixing an issue, do not limit yourself to clicking the broken button again. Repeat the entire scenario from a clean launch, then perform regression testing on adjacent features. Fixing file saving can change navigation, while adding the full-screen API can affect keyboard handling and the closing of modal windows.

Short checklist before handing over a web application

• The server starts with a clear command and the application opens without manual repairs.
• All menu items lead to existing screens.
• Core features have input data and a verifiable result.
• Creating, editing, saving, and deleting objects are tested separately.
• Files of unsupported types produce a clear message.
• Buttons work when clicked repeatedly and do not leave the interface stuck.
• Game rules, wins, draws, and restarts are tested through separate actions.
• Full-screen mode is tested with browser restrictions and the user gesture taken into account.
• Errors are visible in the interface and recorded in the developer console.
• After fixes, the entire main scenario is retested.

AI can quickly assemble a convincing interface and independently launch a local server, but the quality of a web application is determined not by the speed of generation. A reliable result emerges after systematically testing features, file operations, navigation, errors, and relaunching. This approach turns a demonstration mockup into a clear list of tasks for refinement and prevents a visually polished shell from being mistaken for a finished digital product.