A product audit should show what happened in the experience, not merely generate a test plan. The useful record connects the expected behavior, environment, steps, screenshots, browser evidence, passes, regressions, and uncertainty.

Strawberry's companion can navigate the real product in a visible browser workspace while a teammate observes or takes over. It can inspect console and network evidence when relevant, follow accepted specifications and issue context, and carry a confirmed finding into a grounded bug report without losing the original evidence.

Set a useful audit boundary

Clarify the product or URL, environment, user and account state, critical flow, expected result, changed area or release context, test data, important platforms or viewports, deadline, and reviewer. Prioritize the smallest set of paths and variations that can answer the question.

Want to try it?

Ask your Strawberry companion: “Audit this product flow in the approved environment and give me a reviewable record of passes, regressions, browser evidence, scope, and uncertainty.”

Skill

Audit a product flow

Navigate and test a critical product flow in the approved environment, then return an inspectable audit record.

Choose the safe environment and state

Flow type	Preferred test boundary
Public, read-only path	The live site can be appropriate when the audit cannot create or change state.
Authenticated or stateful path	Prefer staging, a preview environment, or a dedicated test account.
Transactional, destructive, or permission-changing path	Use an explicitly approved safe environment, account, data set, action, and cleanup plan.
Production-only path	Keep the audit read-only unless active permission covers the exact state change and conditions.

Confirm the account role, data, credentials, side effects, and cleanup. Use synthetic or approved test data, and keep secrets or private user content out of screenshots, logs, URLs, and reports.

Navigate the real flow

Record the environment, build or version, account role, feature flags, and starting state.
Run the critical path end to end and compare the expected and observed behavior.
Check the few high-risk variations: validation, recovery, permissions, empty and error states, responsive behavior, and the changed area.
Capture screenshots, relevant console or network evidence, URLs or product locations, blocked paths, exclusions, and cleanup state as the work happens.

Adapt to the product and release risk instead of running a generic checklist. The audit complements the team's test strategy; it does not pretend one browser pass proves the whole system.

Classify before escalating

Finding	What the audit should say
Confirmed regression or failure	The reproducible evidence, impact, scope, and conditions.
Unexpected behavior with unclear requirement	What happened and which product decision or source is missing.
Usability observation	The observed friction without labeling it a defect.
Blocked or untested path	Why it could not be checked and what would unblock it.
Pass	The exact path and conditions that passed within scope.

Repeat an important failure when safe and check a nearby control path when it could isolate the condition. Do not claim a root cause from browser symptoms alone.

Turn confirmed bugs into useful issues

Deliver the scope, environment, flow, evidence, passes, regressions, blocked paths, exclusions, cleanup, and uncertainty. Lead with findings that could change a release or product decision.

Testing a product does not approve creating a ticket, changing code, merging, deploying, changing production data, or notifying customers. Move a real bug into the reporting workflow and follow the permission for each later action.

Skill

Research and report a bug

Connect the audit evidence to team, repository, and ticket context, search for duplicates, and prepare or file a grounded issue.

Official Strawberry skill

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.

How to audit a product flow with AI