luvv to help

Menu

Topic 5 of 7

Working With Product And QA

Learn Working With Product And QA for free with explanations, exercises, and a quick test (for Backend Engineer).

Published: January 20, 2026 | Updated: January 20, 2026

Table of Contents

Why this matters

Backend engineers ship the invisible things users rely on. Product sets outcomes, QA protects quality. Working well together means fewer rollbacks, faster releases, clearer scope, and happier users.

  • Turn vague requests into testable acceptance criteria.
  • Plan safe rollouts with feature flags, migrations, and monitoring.
  • Partner with QA on risks, test data, and edge cases.
  • Close the loop on bugs with clear steps to reproduce and fixes.

Concept explained simply

Product defines the problem and success. Engineering designs and implements. QA verifies that what we built actually solves the problem without breaking other things.

Mental model

  • Three circles: Product (outcomes), Engineering (implementation), QA (verification). Your job: create strong handshakes where circles overlap.
  • Handshakes are moments to agree on: scope, acceptance criteria, risks, rollout, and how we measure success.
What each role cares about
  • Product: user impact, business value, prioritization, measurable outcomes.
  • Engineering: architecture, performance, reliability, deadlines, maintainability.
  • QA: coverage, edge cases, reproducibility, traceability, pass/fail criteria.

Key handshakes with Product and QA

  1. Refinement: clarify the problem, define acceptance criteria, list risks and unknowns.
  2. Design: propose API/data changes, migrations, flags, and monitoring. Align on test approach with QA.
  3. Pre-merge: update docs/notes, test locally, provide test data and accounts.
  4. Pre-release: dry-run in staging, confirm metrics/alerts, agree on rollback plan.
  5. Post-release: monitor, communicate status, handle bug triage if needed.

Worked examples

Example 1 — From vague idea to criteria

Request: 'Let users resend verification email.'

  • Clarify: frequency, security, response times, audit trails.
  • Acceptance criteria (summary): rate limit per user/device, token TTL 15 min, email queued within 2s, error codes for unknown email vs disabled account, audit log entry.
  • QA plan: happy path, rate-limit edge, expired token, disabled account, log presence, email template variables.
Example conversation snippet

You: To prevent abuse, is 3 attempts/hour/user acceptable? PM: Yes. QA: Add a server-side cap per IP as well. You: Agreed; we will log when capped.

Example 2 — Bug triage with QA

Bug: Orders occasionally return 500 on PATCH /orders/{id} under load.

  1. Reproduce: run with 200 concurrent requests using a fixed sample order.
  2. Observe: 500 with DB deadlock error.
  3. Scope: impacts update endpoint under concurrency.
  4. Fix approach: add retry on deadlock and narrow transaction scope.
  5. QA verification: stress test, ensure retries capped, verify idempotency behavior.
Minimal reproducible note you send

Steps: PATCH same order id concurrently x200 with status=shipped. Expected 200; got ~7% 500 with SQL deadlock. Logs: trace_id 123..., query lock on orders.

Example 3 — Safe rollout with feature flags

Change: New pricing calculation.

  • Plan: behind 'pricing_v2' flag. Dual-run old and new for 10% traffic, compare results in logs.
  • QA: test both flag states, boundary conditions, and logging of diffs.
  • Release: ramp to 50% then 100% if no diff >1% for 24h. Rollback: flip flag.
Release note snippet for QA
  • Endpoints: POST /quotes, POST /orders
  • Flag: pricing_v2 (off by default)
  • Metrics: pricing_diff_rate, alert if >1%
  • Test data: user U123, product P456 (edge tax rules)

How to write good acceptance criteria

Use Given–When–Then. Cover success, errors, and observability.

  • Given: preconditions and data
  • When: action or request
  • Then: response, side effects, constraints, logs/metrics
Template you can reuse
  • Given [state/data]
  • When [endpoint/action]
  • Then [status/result] AND [persistence/event/log] AND [rate/limit/timeout]
  • And [error case 1]
  • And [error case 2]

Communication templates

Clarifying a vague request

What is the user problem? What outcome proves success? What is out of scope? Any regulatory or security constraints? What are the edge cases we must not break?

Pre-merge QA note
  • Scope: what changed and where
  • Endpoints/DB: touched resources
  • Flags/Migrations: names and default state
  • Test Data: IDs, seeded accounts, credentials if needed
  • Risks: known limits or deferred items
Bug report format
  • Summary: short title
  • Environment: prod/staging, version
  • Steps to Reproduce: numbered steps
  • Expected vs Actual: precise
  • Artifacts: request/response (safe), logs, trace ids

Collaboration checklists

Kickoff

  • Outcome defined and measurable
  • Acceptance criteria drafted
  • Risks and unknowns listed
  • Data/fixtures agreed for QA

Before merge

  • Unit and integration tests pass
  • Docs and changelog updated
  • Feature flags default safe
  • QA note posted

Pre-release

  • Staging verification done
  • Metrics and alerts configured
  • Rollback path confirmed
  • Owner on-call identified

Bug triage

  • Reproducible steps captured
  • Severity and scope assessed
  • Fix or rollback decision made
  • Status communicated to PM and QA

Exercises

Do these to practice. Compare with the suggested solution. Aim for clear, testable outcomes.

Exercise 1 — Turn a request into acceptance criteria

Scenario: 'Let users request a password reset. It must be secure and not abusable.'

  • Write 5–8 Given–When–Then criteria for POST /password-resets covering: success path, rate limiting per user and IP, token TTL (15 min), unknown email behavior, audit logging, and email delivery expectation.
Hints
  • Ask: what does success look like for the user and system?
  • Cover negative cases and observability.
  • Keep responses and error codes explicit.
Suggested solution

See the Exercises section solutions below in the page footer area or expand exercise details in the exercises list.

Exercise 2 — Draft a minimal QA test plan

Scenario: New PATCH /orders/{id}/status supports transitions: created -> paid -> shipped. Requires If-Match with ETag. Errors: 400 invalid transition, 409 version mismatch, 404 not found.

  • List concrete test cases: happy path, invalid transitions, missing/invalid ETag, concurrent updates, unauthorized request, and logging/metrics checks.
Hints
  • Include positive, negative, and concurrency tests.
  • Think about idempotency and side effects.
  • Note any test data/setup required.

Common mistakes and self-check

  • Vague criteria: If a tester cannot tell pass vs fail, rewrite with Given–When–Then.
  • No negative cases: Add at least two explicit error paths.
  • Late QA involvement: Invite QA at refinement; it saves time later.
  • Hidden breaking changes: Document and gate with flags or versioned APIs.
  • Missing rollback: Always define a fast, low-risk rollback.
Self-check
  • Can QA test this without asking you basic questions?
  • Can you monitor success/failure via metrics and logs?
  • Is there a one-click or instant rollback?

Practical projects

  • Instrumented Feature Rollout: Add a feature flag to an existing endpoint, log both old and new behavior for 10% traffic, and prepare a QA note.
  • Error Budget Review: With QA, pick one endpoint, define SLOs, add metrics and alerts, and document acceptance criteria for a small improvement.
  • Bug Bash Pack: Create seed data, test users, and a short guide so QA can run a focused 30-minute bug bash.

Learning path

  1. Master Given–When–Then for backend APIs.
  2. Practice writing pre-merge QA notes for each PR.
  3. Learn feature flags, canary releases, and rollbacks.
  4. Co-create a minimal test plan with QA on your next change.
  5. Automate: convert acceptance criteria into integration tests where possible.

Who this is for

Backend engineers, SREs, and platform developers who collaborate with Product Managers and QA to ship reliable features.

Prerequisites

  • Comfort with HTTP APIs and error handling
  • Basic testing knowledge (unit/integration)
  • Familiarity with feature flags and logging

Next steps

  • Pick a small feature and draft acceptance criteria today.
  • Share a pre-merge QA note on your next PR.
  • Schedule a 15-minute refinement with PM and QA for your next sprint item.

Mini challenge

Pick a recent incident or bug. Write a 5-line post-release note: what failed, how it was detected, user impact, quick fix or rollback, and what acceptance criterion would have prevented it.

Quick Test

Take the quick test below to check your understanding. Note: Anyone can take the test for free; sign in to save your progress and results.

Practice Exercises

2 exercises to complete

Instructions

Scenario: 'Let users request a password reset. It must be secure and not abusable.'

Write 5–8 Given–When–Then criteria for POST /password-resets covering:

  • Success path with token TTL 15 minutes
  • Rate limiting per user and per IP (e.g., 3/hour)
  • Unknown email behavior
  • Audit logging
  • Email delivery expectation (queued quickly)
Expected Output
A clear list of Given–When–Then statements including success and negative cases, with explicit status codes and limits.

Working With Product And QA — Quick Test

Test your knowledge with 8 questions. Pass with 70% or higher.

8 questions70% to pass
Maintainable Code StandardsEstimation And Planning

Have questions about Working With Product And QA?

AI Assistant

Ask questions about this tool