Our QA checklist for every story

Most teams treat QA like a final checkpoint. You finish development, hand it off to testing, cross your fingers, and hope nothing major breaks.

That approach creates bottlenecks, last-minute scrambles, and the kind of bugs that make you wonder how they possibly made it through "testing."

The problem isn't that teams don't care about quality—it's that they approach it backwards.

Traditional QA treats testing as verification: "Does this work the way we built it?" But effective QA starts earlier, asking: "Are we building the right thing, and do we all understand what 'right' means?"

When QA begins after development, you're limited to finding implementation bugs. When it starts during planning, you catch requirement gaps, unclear expectations, and fundamental misunderstandings before they become expensive to fix.

After analyzing our QA process across dozens of feature releases, we've found something better: a systematic approach that embeds quality throughout development instead of tacking it on at the end.

Here's the exact checklist we use—one that any team can adapt, regardless of tools or team size.

Whether your team has a dedicated QA specialist, shares QA resources across multiple teams, or assigns quality ownership to developers or product managers, the principle remains the same: every story needs a single point of accountability for quality throughout its lifecycle.

In cases where QA work is shared between teams or when teams don't have dedicated QA resources, deciding story ownership is the first step and becomes even more critical for avoiding confusion and ensuring nothing falls through the cracks.

The first step in shifting from verification to collaboration is clear accountability. Every piece of work needs a single QA owner from start to finish.

Not because QA should be siloed, but because someone needs to drive the quality conversation. When everyone's responsible, no one's accountable.

Your QA owner handles:

• Requirements analysis before development starts

• Test planning and execution

• Bug communication and triage

• Stakeholder alignment on completion

This works whether your "QA owner" is a dedicated tester, a developer, or a product manager—though teams with dedicated QA should prioritize having QA professionals own this process when possible. The role matters more than the title.

Before anyone writes code, your QA owner should tear apart the requirements. This is where the shift from verification to collaboration happens in practice.

The test plan is created and iterated on after requirements analysis, often including developer consultations for implementation context, test data considerations, and technical feasibility. Test cases are then labeled for automation considerations and reviewed by QA peers for feedback.

Look for:

• Missing edge cases ("What happens if the user uploads a 50MB file?")

• Unclear expected behavior ("Should this sort alphabetically or by date?")

• Integration gaps ("How does this interact with the existing notification system?")

• Cross-platform considerations ("Does this need to work on mobile?")

Document these gaps immediately. Most "bugs" are actually requirement gaps that could have been caught before a single line of code was written.

Remember: Requirements analysis is iterative. As implementation details emerge during development, revisit and update both requirements understanding and test plans accordingly. Requirements can change during development. QA has to align all stakeholders on any differences between what was originally specced and what was completed, updating test plans and acceptance criteria as needed.

The best QA conversations happen in planning meetings, not after features are "done." We do this in design reviews and sizing sessions, where QA can surface questions while they're still cheap to answer.

Once requirements are clear and development is complete, systematic testing ensures everything works as the team agreed it should.

Coverage strategy:

• Test all acceptance criteria explicitly

• Cover the most likely edge cases

• Verify integration points

• Test across browsers/devices as needed

• Check different user permission levels

Document everything:

• Pass: Works as expected

• Fail: Doesn't meet requirements—file a bug

• Blocked: Can't test due to dependency

• Retest: Unclear result or related changes pending

For any failure, file bugs immediately with enough detail that someone else could reproduce the issue tomorrow.

It’s worth noting that requirements often shift during development. QA needs to track those changes in real time, updating test plans, aligning expectations, and flagging any divergence from the original scope. Analysis isn't a one-time task, it’s iterative.

When testing reveals issues, systematic triage ensures you're solving the right problems first.

Impact (1-5):

• 1: Negligible (cosmetic only)

• 2: Minor usability problems

• 3: Moderate functionality issues

• 4: Significant feature problems

• 5: Critical functionality broken

Probability (1-5):

• 1: Requires very specific conditions

• 2: Unlikely with normal use

• 3: Could happen regularly

• 4: Likely to occur often

• 5: Happens consistently

Risk = Impact × Probability

Block the story for:

• Risk rating of 20+

• Any unmet acceptance criteria

• Significant regressions in existing features

Communicate blocking issues immediately. Everything else gets prioritized based on risk.

For more on how we approach bug management at Atono, check out this article.

The final step connects back to the beginning—ensuring everyone agrees on what "done" means before shipping.

Include:

• Product management

• Design (if UI changes)

• Engineering lead

• Anyone who needs to document or communicate the feature

Cover:

• Acceptance criteria walkthrough

• Any edge cases worth noting

• Remaining bugs and their impact

• Changes made during development

• Updates to any acceptance criteria, if necessary

Confirm that any changes made during development are reflected in updated acceptance criteria. This is often the final opportunity for engineering and product teams to sync on what was built vs. what was originally defined.

Record the review. This creates institutional knowledge and helps anyone who wasn't there understand what shipped and why.

Use this for every feature to ensure consistent quality:

• QA owner assigned and announced

• Requirements analysis completed

• Gaps and questions documented and resolved

• Success criteria clear to entire team

• Test plan created and reviewed by a peer before code review

• Integration points identified and tested

• Edge cases documented and verified

• Cross-browser/device testing completed

• All bugs filed with reproduction steps and supporting attachments

• Risk assessment completed for each bug

• Blocking bugs communicated immediately

• Fixes verified before closing

• Stakeholder review completed and recorded

• All blocking bugs resolved

• Acceptance criteria verified and up to date

• Team aligned on any known limitations

This process scales up and down:

Small teams: Don’t have a dedicated QA yet? That’s okay, as long as someone takes clear ownership of the quality process. The systematic approach stays the same, but quality scales best when QA leads the way

Different tools: No matter which tools your team uses, the principles of early analysis, systematic testing, and stakeholder alignment stay the same. Maybe your team uses a CSV to track test cases, or maybe they’re using enterprise software to manage their projects—these principles apply universally.

Fast-moving environments: Focus on the risk framework to ensure you're solving the right problems first.

Remote teams: The documentation and recorded reviews become even more critical for maintaining alignment.

This process succeeds because it treats quality as a team conversation instead of an individual checkpoint. While QA owns the process, ensuring a high quality product involves everyone on the team.

Teams using this approach ship faster because they catch problems when they're cheap to fix. They ship with more confidence because stakeholders have seen features work before they hit production.

The goal isn't perfect software—it's shipping the right things with confidence. This checklist helps you do exactly that.