Testing Interfaces, APIs, and Business Logic

Test the Request Tracker as Its User

You do not need to read the code to check the promised workflow. Write the expected result before trying it, use fictional records, and record the actual result. An agent saying that its build passes is useful evidence, but your own acceptance check tests whether it solved the problem you described.

Start with two records so you can notice one action accidentally changing another. Run the following checks in the preview and repeat the important ones on the deployed version. If shared accounts were added, use two different test users and a signed-out session.

1. Add a valid request. It appears once with the correct title and initial status.
2. Submit an empty title. The app explains the problem and creates no record.
3. Edit request A. Request B keeps its original values.
4. Cancel deletion. The record remains. Confirm deletion. Only that record disappears.
5. Reload and reopen the browser. Records behave according to the agreed storage rules.
6. Export records. Open the export and check that it contains the expected fields and values.
7. Use only the keyboard and a phone-width view. You can identify and operate every required control.
8. Try a long title, unusual characters, and an empty list. Text stays readable and the interface remains usable.

Check the Cases a Smooth Demonstration Misses

If the app uses a network service, test a slow or unavailable connection. The user should receive a clear status rather than a false success message. Try submitting twice while the first action is running; decide whether the app prevents duplicates or safely treats the repeated action as the same request.

For shared records, check the agreed roles: a private record must stay private, while an intentionally shared record must be available only to the allowed team. Ask the agent to test a direct server or database request as well as the visible screen, including a signed-out request. Give it the expected read, edit and delete boundaries; let it produce automated tests appropriate to the stack. If your app has no server, shared accounts, or network requests, record those checks as outside the current scope rather than claiming they passed.

A lint check catches some code-quality issues; a type check checks certain value mismatches; a build check confirms that the project can produce its deployable output. None of those proves that a customer workflow, permission rule, or backup works. Ask what each check established and what still needs a browser or operational check.

Create a test report with columns for scenario, expected result, actual result, evidence, and pass/fail. Run the checks that fit this project and state what you did not test. Prioritize losing data, unauthorized access, duplicate actions, and false success messages. Fix failures and rerun the affected checks before saying it is ready.

Use a Small Release Gate

Ask a second person or reviewer to repeat the main task with your written instructions. Record the version and date of the test. Change the code after that check and you need to retest the affected behavior. For a learning demo, show fictional examples and label its storage limits clearly.

• The agreed add/edit/delete/export workflow passes in the preview and deployed app.
• No known critical data-loss or access-control failure remains.
• The source and configuration can be recovered, and a previous working release is identified.
• For stored shared data, a backup has been restored into a separate test environment and checked.
• The owner can see failures and costs, has a support contact, and knows how to pause the app.
• The first user group is small enough to support, with clear limits and a way to report problems.

What Should You Test in the Interface?

Interface testing checks how the product behaves from the user’s perspective.

Test:

• navigation
• buttons
• forms
• validation
• loading states
• empty states
• error states
• success feedback
• keyboard access
• responsive layout
• different browsers

Do not test only one narrow desktop browser window.

At minimum, inspect:

• a small mobile width
• a larger mobile width
• tablet width
• laptop width
• wide desktop width

Check for:

• clipped text
• horizontal scrolling
• buttons outside the viewport
• overlapping controls
• unreadable tables
• hover-only actions
• modals larger than the screen
• navigation that cannot be closed
• touch targets that are difficult to select

What Should You Test Through the API?

Examples:

GET /api/projects
POST /api/projects
PATCH /api/projects/123
DELETE /api/projects/123

Postman can send requests directly to an endpoint without requiring the normal application interface.

This allows the tester to inspect:

• request method
• URL
• headers
• authentication token
• request payload
• response status
• response data
• error messages

For a project-creation endpoint, test:

• valid data
• missing project name
• extremely long project name
• invalid customer identifier
• unauthenticated request
• user without permission
• duplicate request
• unexpected extra fields

Do not test only the successful request.

Examples:

• volume must remain between 0 and 100
• inventory cannot fall below zero
• a booking end time must occur after its start time
• a refunded payment cannot remain marked as pending
• only an administrator can delete a workspace
• one company cannot access another company’s records

These rules should be enforced in the system rather than assumed from the interface.

A frontend may prevent a user from entering 130% volume. An attacker, faulty integration, or software bug may still send 130 directly to the backend.

Important rules should therefore be validated at the authoritative layer, usually the backend and database.

How Do You Test the Whole Workflow?

A workflow test follows a complete user goal across multiple screens and systems.

For a booking application:

1. find an available time
2. select the time
3. enter details
4. confirm the booking
5. store the booking
6. send confirmation
7. display the booking to the business

Each individual page may work while the full workflow fails.

Examples:

• the booking is stored but no confirmation is sent
• confirmation is sent but the booking is missing
• two users reserve the same slot
• refreshing the page submits the booking twice
• a failed payment still creates a confirmed order

What Should You Ask a Consultant?

• Which user workflows have been tested end to end?
• Which invalid values have been tested?
• Are permissions tested through direct API requests?
• What happens when an external service fails?
• Can an action be submitted twice?
• Which rules are enforced by the frontend, backend, and database?
• How are failed tests recorded and prioritised?
• Which tests run automatically before deployment?