QA Tester 1

Use this when

An app needs an end-to-end QA pass that exercises the same browser UI a person uses. Check functional flows, component behavior, and layout, along with network responses and persistence where the app uses them.

Use the project's documented setup, test environment, and inspection tools. Apply the checks relevant to each flow. Mark network or persistence checks as not applicable only when the flow does not involve them; unavailable access to a required backend or data store is a verification gap, not a reason to omit the check or claim a pass.

The output is a test report with flow outcomes, screenshots, relevant network and persistence evidence, issues, and cleanup status.

Steps

1. Discover the app and establish the test environment

Begin by inspecting the codebase, routes, and any backend endpoints or persistence models:

• Find available pages, navigation routes, primary user flows, forms, and key UI components.
• Read frontend routes, components, state management, form logic, and validation.
• Where present, read backend endpoints, request validation, business logic, and persistence writes.
• Inspect relevant schemas, data models, migrations, relationships, ownership rules, timestamps, status fields, and deletion behavior.
• Use existing tests alongside that code to determine expected behavior.

Identify the app's test environment, seed data, or clearly identifiable test records. Confirm the browser session and any backend or persistence targets belong to that environment. Do not mutate production data.

Find the documented way to inspect the app's data stores and their configuration. Use the project's supported tools to query relevant records or inspect equivalent persisted state. Establish the expected values and relationships before changing them. If required access is unavailable, record what cannot be verified.

If expected behavior remains unclear after inspecting frontend code, backend code, schemas, and tests, classify that flow as Needs clarification and record the unresolved requirement.

2. Prepare the test plan and resolve destructive-action approval

List the flows to test before executing them. For every flow, record:

• Preconditions, including account, permissions, seed data, and starting state.
• Ordered user steps through the UI.
• Expected UI result, component states, and messages.
• Expected network requests, responses, and any explicitly expected error status, where applicable.
• Expected persistence changes, or the expectation that no change occurs, where applicable.
• Cleanup steps and how the test records will be identified.

Include create, read, update, and delete flows where applicable, plus the relevant failure scenarios and viewport sizes. Identify which steps involve deletion or permanent data mutations, including cleanup that has those effects.

Present the concrete plan and wait for approval before executing destructive actions such as delete flows or permanent data mutations. Keep any action awaiting approval out of execution and report it as untested. Approval to test does not permit production data mutations.

3. Execute each flow through the browser

Start at the UI and use browser automation to follow the planned user path. Prefer deterministic selectors such as data-testid, labels, roles, and accessible names.

Click buttons and links, fill and submit forms, navigate pages, open and close modals or dropdowns, trigger validation, and perform the applicable CRUD operations. Do not skip UI steps by calling APIs directly. Direct API calls are permitted only to verify backend behavior after a UI action.

For each action:

1. Observe the UI transition and resulting state.
2. Capture all API requests and other relevant network responses triggered by that action.
3. For actions affecting persistence, inspect the data store and compare the result with the baseline and expected state.
4. Preserve evidence before continuing, so a later action does not obscure what happened.

Verify response payloads are valid and relevant to the triggering action. Flag HTTP 4xx or 5xx responses as failures unless the test plan explicitly expects them. Note slow, duplicated, or unexpected API calls even when their status is successful.

4. Verify persistence and side effects

Use the project's supported inspection tools to read the relevant database, collection, or other persistent storage. Record the storage target, query or inspection performed, expected state, and actual results. Do not write directly to storage to simulate the UI action under test.

After each relevant action, verify:

• Create: The expected record was inserted with the expected values.
• Update: The intended record changed to the expected values.
• Delete: The intended record was removed or soft-deleted according to the app's behavior.
• Related state: Relationships, foreign keys, ownership fields, timestamps, and status fields are correct where relevant.
• Unintended effects: No unrelated records were created, modified, or deleted. Check the affected storage and relationships identified during discovery.

A successful HTTP response or success message is not sufficient evidence of a correct persistence change. Preserve inspection results from before and after mutations, and clearly identify any mismatch.

5. Check components, failure scenarios, and layout

Within the tested flows, verify buttons, links, forms, inputs, dropdowns, tabs, modals, tables, filters, pagination, and navigation. Check loading, empty, success, error, and validation states, plus correct enabled and disabled controls.

Exercise required fields, invalid input, boundary values, and duplicate values where applicable. Also test unauthenticated or unauthorized access, duplicate submissions, empty states, and error states when applicable and safe in the test environment. Verify that rejected actions produce the expected UI and network response and do not cause unintended persistence changes.

Repeat the relevant flows at desktop, tablet, and mobile viewport sizes. Record the actual dimensions tested. Look for:

• Broken layout, overlapping elements, clipped text, and unexpected horizontal scrolling.
• Missing spacing, unreadable text, and incorrect alignment.
• Broken icons or images and controls that cannot be used.

Capture screenshots of important steps, failures, and visual issues. Inspect console errors and warnings, and relevant backend logs when available.

6. Classify the results and clean up

A flow is Passed only when the user completes it from start to finish, its components behave correctly, its layout remains usable, there are no unexpected console errors or relevant network failures, applicable persistence checks match expectations, and no unintended side effects are detected. Document why any check is not applicable; missing evidence for an applicable check prevents a pass.

A flow is Failed when the expected path cannot be completed, a component behaves incorrectly, layout degrades usability, an unexpected API error occurs, persistence is wrong, or unintended records change. A known expected result that cannot be verified is also a failed verification; state the missing evidence rather than claiming a product defect without support.

Use Needs clarification when the expected behavior itself remains unclear. Never turn an ambiguous result into a pass. Record planned flows that were not executed separately from tested-flow totals.

Clean up created test data only when it is safe and within the approved plan. Confirm the cleanup result in the relevant storage. If cleanup is unsafe or unapproved, preserve the records and list their identifiers and remaining state clearly. Report records created, updated, and deleted, including pre-existing test data that was changed.

7. Write the failure reports and final report

For each failure, include all of these fields. If evidence is unavailable, say so and explain the gap.

Flow name:
Failed step:
Severity: Critical / High / Medium / Low
Expected result:
Actual result:
UI evidence:
Network evidence:
  Request method:
  Request URL:
  Status code:
  Response body or error:
Persistence evidence:
  Table/collection or storage target:
  Query or inspection used:
  Expected state:
  Actual state:
Console/backend errors:
Suspected cause:
Suggested fix, if identifiable:

Keep suspected causes distinct from proven observations. Reference the screenshots, network details, before-and-after persistence results, console output, and backend logs that support each finding. Mark evidence fields as not applicable when the flow does not involve that layer.

Write the final report with these eight sections:

1. Summary: Total flows tested, passed, failed, needs clarification, and critical issues. Note unexecuted flows and verification gaps.
2. Tested flows: Each flow's name, status (Passed, Failed, or Needs clarification), and notes.
3. Failures: Detailed reports using the failure format above.
4. Network/API issues: Every unexpected 4xx/5xx response or relevant network failure, including route, method, status, and triggering UI action. Also note slow, duplicate, or unexpected calls.
5. Persistence verification: Mutations verified, mismatches, and unintended side effects, with query or inspection evidence.
6. UI/layout issues: Visual and interaction issues, viewport dimensions, and screenshot references.
7. Cleanup: Records created, updated, and deleted; whether cleanup completed; and identifiers of any records left behind.
8. Recommendations: Prioritized fixes, additional tests needed, and unclear requirements requiring clarification.

Check that report totals match the individual flow outcomes and that every claimed pass has UI, network, and persistence evidence appropriate to the flow.

Done when

• Discovery and a concrete test plan preceded execution.
• Tested flows were driven through browser interactions without bypassing the UI.
• UI behavior, relevant viewport layouts, network responses, and persistence were checked against explicit expectations where applicable.
• Environment setup and persistence inspection used the project's documented tools; no particular stack or storage engine was assumed.
• Expected failure scenarios were exercised where safe, with no unexpected persistence changes.
• No production data was mutated, and destructive actions or permanent mutations stayed behind the approval gate.
• Every flow has an evidence-supported outcome; unclear requirements and untested scope are reported.
• Failures and the final report contain the required fields, with consistent totals and evidence references.
• Cleanup is verified, or remaining test records and their state are clearly listed.