QA Fundamentals: Start With the Questions
Quality assurance starts before anyone clicks through a finished feature. It begins with a shared understanding of what the product should do, who needs it, and which failures would matter most.
Testing supplies evidence about that product. QA also includes the habits that make reliable delivery easier: reviewing requirements, discussing risks, agreeing on acceptance criteria, and learning from defects.
Start with an outcome
“Test the reservation page” is an assignment, but it is not yet a useful testing goal. A more useful goal is: “Establish whether a customer can reserve the available tickets without being overcharged or overselling the event.”
That goal suggests questions about quantities, available stock, totals, failed requests, and duplicate submissions. Each question leads to an observable result.
Roles support the work
A team might have QA analysts, engineers, testers, leads, or managers. A smaller team may share those responsibilities. Job titles do not remove the need for clear ownership: someone must clarify ambiguous behavior, prepare data, investigate failures, and communicate remaining risk.
Developers contribute checks at the code level. Product colleagues clarify intended behavior and business priorities. Testers examine assumptions and provide evidence from the product. Quality depends on that collaboration.
Decide what good evidence looks like
Before testing, write down the build, environment, test data, expected behavior, and result. A useful failure report lets another person reproduce the problem without reconstructing your session from memory.
A passing check has a narrower meaning than “the product is perfect.” It means a specific behavior worked under the conditions you recorded. Untested environments and unresolved questions should stay visible.
Make an informed release decision
Testing effort depends on the change, its risks, the system's history, and available evidence. A fixed percentage of development time is not a substitute for examining those factors.
A release may proceed with known minor defects, or stop because one serious issue remains. Report what passed, what failed, what was not tested, and the likely impact. The responsible team can then make an explicit decision.
For a first exercise, choose one small feature and write three questions: what must work, what must be rejected, and what should happen when a dependency fails.