6.2Working with Product Managers

Understanding User Stories from a Testing Perspective

Product managers write user stories to describe what they want. QA engineers read user stories to find what is missing. This is not adversarial -- it is complementary.

What QA looks for in a user story:

Element	QA Question	Example
Acceptance criteria	Are they specific enough to test?	"Fast" is not testable. "Page loads in under 2 seconds" is.
Edge cases	What happens at the boundaries?	What if the user enters 0? 999,999? Negative numbers?
Error handling	What happens when things go wrong?	What if the API is down? What if the upload fails?
User roles	Does this work for all user types?	Admin, regular user, guest, API consumer?
Data states	What about empty, null, and maximum data?	First-time user with no data. Power user with 10,000 records.
Integration points	Where does this touch other systems?	Does this affect notifications? Analytics? Partner APIs?

How to Refine Stories Without Frustrating the PM

• Ask questions, do not critique. "What should happen when the user has no saved addresses?" is more productive than "This story is incomplete."
• Offer concrete additions, not abstract complaints. "Can we add an acceptance criterion for the empty cart case?" rather than "You need more acceptance criteria."
• Batch your questions. Come to refinement with a prepared list rather than interrupting story by story.
• Acknowledge their perspective. "I understand we want to ship this quickly. These two questions are the ones that affect testing most."

The QA-PM Handoff Checklist

Before a story enters development, QA and PM should agree on:

• Acceptance criteria are specific and testable
• Error states and edge cases are defined (or explicitly deferred)
• User roles and permissions are documented
• Dependent systems and integrations are identified
• Non-functional requirements (performance, accessibility) are stated
• Test data requirements are identified