Review this website or app before it is shown to users. Match the scope to the actual project. Do not invent bugs or missing features.

Work on a local or test copy with test accounts. Do not deploy changes, modify production data, run real payments or send real messages. Use the available sandbox when testing external services. Do not reveal secrets in the report.

1. UNDERSTAND THE PRODUCT

From the code, determine: the type of app, its main promise, user roles, how data is stored, integrations and deployment. Name the three most important user paths. Check existing tests and the results of available scanners. Mark areas that don't exist as not applicable.

2. CHECK THE OUTCOMES

Walk the paths from entry to the actual result. Check buttons, links, search, filters, export and saving where present. Confirm the file contents, the database state or the test service, not just the success message. Compare normal data, no data and a larger dataset. Check pagination, completeness of statistics, refreshing and opening subpages directly.

3. CHECK ACCESS BOUNDARIES

Use only your own test accounts: user A, user B and the relevant roles or organizations. Check reading, editing, files and export across accounts. Check server operations while bypassing the UI, including with no session and without the required plan. Account for intended sharing. Do not treat a hidden button as security.

4. CHECK MONEY AND INTEGRATIONS

If present: check a confirmed and a failed payment, a repeated or late event, the correct access period after cancellation, and a customer who never returns to the site. Verify webhook signatures and protection against the same operation taking effect twice. Check server-side usage limits, concurrent requests and error handling. Distinguish public keys from secret ones. Do not run expensive load tests.

5. REPRODUCE AND DOCUMENT

For each problem give: the scenario, expected and actual result, evidence and the cause in code or configuration. Separate confirmed bugs, risks that need a test and things not checked. Prioritize access to other users' data, data loss, payment errors, uncontrolled costs and anything blocking the main action.

6. FIX AND REPEAT

Make minimal fixes for reproduced problems. Keep the design, existing safeguards and business rules. Do not disable validation or access control to make a test pass. Then repeat the identical scenarios and the three main paths, including on a narrow screen. Where a business decision is unclear, leave a specific question.

Finish with a report: problem, fix, retest, evidence. List missing access and manual tests. Reading code is not a completed test. Without access to a browser, backend or sandbox, do not claim an area works. Emulation does not replace checking on a physical phone.