From the specification to user value
A specification describes what to build, while a product exists to solve a user problem. A feature can match the spec 100% and still not work for people: the button is there but nobody sees it; the form accepts data but the user does not know what to do next. A QA who thinks in product terms checks both levels: "was it built right?" and "was the right thing built?".
A user story captures a need: "As a role, I want an action, so that an outcome". Its quality is quickly assessed by INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable. If a story cannot be tested, it is not ready for development.
Acceptance criteria make a story verifiable. A handy format is Given / When / Then:
- Given — the initial state (the user is signed in, there is one item in the cart);
- When — the event or action under test (clicks "Checkout");
- Then — an observable result (sees a confirmation, an email arrives).
One scenario, one behaviour. A criterion like "works fast" is not enough: it needs a number and conditions ("search responds within 1 s for 95% of queries on a catalogue of 10,000 products").
Questions for the PM worth asking before development starts: what problem are we solving and for whom? How will we know it worked (a metric)? What is out of scope for this release? What should happen if a service is down or the data is empty? Are there constraints: platforms, countries, regulation, accessibility?
Bug or feature, risk by business impact, MVP
Bug or feature? The criterion is not "who wrote it" but the expected behaviour. If the behaviour contradicts the spec or a reasonable user expectation, it is a defect. If the expectation is described nowhere or it is a wish for a new capability ("add PDF export"), it is a change request, and the priority decision belongs to the product owner. Disputed cases are not settled by a war in the tracker: QA describes the impact on the user and the PM decides.
Risk by business impact. There is always less time than test ideas. For each change we ask: how bad would a failure be (money, data, reputation, legal consequences) and how likely is it (new complex logic, frequently changed code, integrations). Payment, sign-up, access rights and personal data go to the top of the list; the colour of a hint goes to the bottom. This lets you say honestly: "this is what we checked deeply and this is what we checked only on the surface".
Testing from the user journey. Individual screens can work while the journey does not. Walk the whole scenario: came from an ad → signed up → found a product → paid → got an email → returned for the status. Look at the seams: data handed between steps, the "back" behaviour, reloads, a weak connection, a mobile screen.
MVP and trade-offs. An MVP is the smallest release that tests a hypothesis about value. It is deliberately incomplete, and that is fine. QA role here is not to block but to make the trade-offs explicit: what is known and not fixed, the impact, how to contain it (a feature flag, part of the audience, a note in the release notes). The decision "we ship with this limitation" belongs to the product owner, but it is made knowing the risk.
Edge cases that matter. Not all edge cases are equally important. First those that touch real people: a long name or an apostrophe in a surname, Cyrillic and emoji, another time zone, an empty state ("you have no orders yet"), pressing the pay button twice, losing the connection in the middle of an action.