---
title: "acceptance criteria validation | Skills We Assign For | Azendo"
description: "Acceptance criteria validation — writing criteria that can be checked, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/acceptance-criteria-validation/"
---

[Skills](https://azendo.co/skills/) Testing practice 

# acceptance criteria validation.

Acceptance criteria validation is verifying that delivered work meets the conditions agreed before it was built. It depends on criteria being specific enough to check — which is where most of the actual work sits, well before any testing happens.

## Where acceptance criteria validation fits on a long engagement.

Criteria that cannot fail are the common problem. "The page should load quickly" and "the form should be user-friendly" cannot be validated, so validation becomes an opinion, and an opinion is what gets overruled when a deadline is close. Criteria stating a measurable condition remove that argument entirely.

The most valuable time to examine criteria is before implementation. Reviewing them at refinement surfaces the ambiguity while it costs a conversation, rather than after the work is built and the disagreement costs a rebuild. Testers involved at that point prevent more defects than they later find.

## What an assigned team does with acceptance criteria validation.

This is where the direction and delivery boundary is clearest. You set what "done" means; we verify against it and say plainly whether it has been met. That only works when the criteria are specific enough for the answer to be a fact rather than a negotiation.

Helping make them that specific is part of the work, not a precondition for it, and it is how assignments are run under [qa outsourcing](https://azendo.co/services/qa-engineering-and-test-automation/).

## What we use acceptance criteria validation for.

* Ambiguity caught at refinement Criteria reviewed before implementation, where a disagreement costs a conversation.
* Conditions that can actually fail Measurable statements, so acceptance is a check rather than an opinion.
* A shared definition of done One understanding across product, development and testing, agreed rather than assumed.

## How acceptance criteria validation capacity is assigned.

Acceptance validation sits with the assigned testing capacity, involved at refinement rather than only at the end of a sprint.

## Roles we assign acceptance criteria validation for

* [Manual QA Tester QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/manual-qa-tester/)

## Service lines it sits in

* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in testing practice

* [cross-device testing — skill we assign for](https://azendo.co/skills/cross-device-testing/)
* [exploratory testing — skill we assign for](https://azendo.co/skills/exploratory-testing/)
* [risk-based testing — skill we assign for](https://azendo.co/skills/risk-based-testing/)
* [Test strategy and planning — skill we assign for](https://azendo.co/skills/test-strategy-and-planning/)
* [bug reporting with reproduction steps — skill we assign for](https://azendo.co/skills/bug-reporting-with-reproduction-steps/)

## Tell us what your roadmap needs acceptance criteria validation for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)