audit-a-product-flow

name	audit-a-product-flow
description	Navigate and test a product flow in the browser, then return a reviewable record of passes, regressions, screenshots, console or network evidence, scope, and uncertainty. Use for proactive product QA, pre-release or post-change checks, and live public-site audits; keep stateful or authenticated testing in staging or dedicated test accounts when possible.

Audit a Product Flow

Test the product as a user and return evidence the team can inspect. This is a proactive flow audit, not a substitute for the team's full test strategy and not an instruction to file every finding as a bug.

1. Set the audit boundary

Clarify the product or URL, environment, user and account state, critical flow, expected result, changed area or release context when relevant, test data, platforms or viewports that matter, deadline, and reviewer.

Define what the audit will and will not cover. Prioritize the smallest set of paths and variations that can answer the user's question. Use existing specifications, acceptance criteria, issue or release context, and known risks when available.

Public live sites support read-only inspection. For authenticated, destructive, transactional, permission-changing, or otherwise stateful paths, prefer staging, a preview environment, or a dedicated test account. If production is the only environment, keep the audit read-only unless Strawberry has active scoped permission for the exact action, account, data, and conditions.

2. Prepare safe test state

Confirm the account, role, data, credentials, and side effects required by the flow. Never expose secrets or private user content in screenshots, logs, URLs, or reports. Use synthetic or approved test data and make cleanup needs explicit.

Record the starting environment, build or version when known, browser state, feature flags, and other conditions needed to reproduce the result. If the expected behavior is unclear, establish it from the accepted product source or label the uncertainty before testing.

3. Navigate and test the flow

Use Strawberry's visible browser workspace to follow the flow end to end. Interact with the real interface, inspect transitions and resulting state, and let the user observe or take over when needed.

Check the critical path first, then the few variations most likely to reveal a material regression: entry state, validation and recovery, permissions, empty or error states, responsive behavior, and the changed area. Adapt to the flow rather than running a generic checklist.

Capture evidence as the work happens:

• steps, URLs or product locations, and expected versus observed behavior;
• screenshots or recordings where they make the result easier to verify;
• console errors, failed requests, response details, or timing evidence when relevant and safely available;
• environment, account role, version, and test data; and
• passes, failures, blocked paths, exclusions, and uncertainty.

4. Recheck important findings

Repeat a failure when safe to confirm it is not a transient state or test mistake. Check a nearby control path when that helps isolate the changed condition. Do not claim a root cause from browser symptoms alone.

Distinguish:

• a confirmed regression or failure;
• unexpected behavior whose requirement is unclear;
• an observation or usability concern;
• a blocked or untested path; and
• a pass within the stated scope.

5. Deliver the audit and route real bugs

Provide a concise audit record with the scope, environment, flow, evidence, passes, regressions, blocked paths, exclusions, cleanup state, and remaining uncertainty. Lead with findings that could change a release or product decision.

When a finding should become a grounded issue, use strawberry/product-engineering/research-and-report-a-bug with the audit evidence. Do not create an issue solely because something looked surprising; first establish the expected behavior, impact, and duplicate status.

Follow Strawberry's active scoped permission for every account and action. Draft or ask when permission is insufficient. Stop when identity, environment, scope, impact, or sensitive-data handling changes, and verify any completed external action or cleanup.

After the team accepts the flow, evidence bar, environment, and report shape, preserve the method for later audits. A recurring audit still needs explicit safe test state, ownership, destination, and stop conditions.