Who Defines “Done”? A QA Lead’s Perspective on the Definition of Done for a Sprint Ticket

In many Agile teams, we hear the phrase:

“The developer has completed the ticket. QA just needs to test it.”

This mindset creates one of the biggest gaps in software quality.

As a QA Lead, I believe a tester should be involved in defining what “Done” means for a sprint ticket before development starts, not simply checking whether something works after development is completed.

A tester shouldn't be the person who owns the Definition of Done alone. The team owns it. But QA should play a key role in making sure that the definition of “Done” includes the quality expectations that need to be met before a ticket can genuinely be considered complete.

“Done” is more than “the code works”

A ticket being marked as Done should mean more than:

• Code has been written

• The developer's local test passed

• The pull request was merged

For a software tester, the real question is:

“What evidence do we need to have confidence that this change is ready to move forward?”

That changes the conversation from activity-based completion to quality-based completion.

For example, imagine a sprint ticket:

“Allow customers to update their bank account details.”

A developer may consider the ticket complete when the API successfully updates the bank account.

But from a QA perspective, we need to ask much more.

What does “Done” mean for this ticket?

Perhaps:

• Valid account details can be saved.

• Invalid account details are rejected.

• Existing account details can be replaced.

• The correct validation messages are displayed.

• The API returns the expected status codes.

• The database contains the correct information.

• Relevant audit information is recorded.

• Existing payment functionality is not affected.

• Appropriate authorization is enforced.

• Automated regression tests are added.

• API tests are included.

• Critical negative scenarios are covered.

• The change passes CI/CD quality gates.

• No critical or high-severity defects remain open.

Now we have something much more meaningful than “QA tested it.”

We have a measurable definition of completion.

QA should ask the questions before development starts

One of the most valuable contributions a tester can make during backlog refinement is to challenge the ticket with questions.

For example:

Functional questions

• What exactly should happen when the user performs this action?

• What are the valid and invalid scenarios?

• What happens if the user performs the action twice?

• What happens if required information is missing?

Integration questions

• Which APIs or services are involved?

• Are there downstream systems affected?

• Could this change affect existing functionality?

Data questions

• What data should be stored?

• What happens to existing data?

• Are there database or migration implications?

Security questions

• Who is allowed to perform this action?

• What happens if an unauthorized user attempts it?

• Are sensitive fields exposed in logs or responses?

Performance questions

• Does this introduce a new performance risk?

• Are there expected response-time requirements?

• Could this operation create additional load?

Automation questions

• Which scenarios should be automated?

• Should API-level tests be added?

• Should the UI flow be covered by end-to-end automation?

These questions don't make QA a blocker.

They make QA a quality partner during development rather than a gatekeeper at the end.

A tester should help turn acceptance criteria into testable outcomes

Acceptance criteria often describe what the business wants.

The tester's job is to help translate that into observable and testable behaviour.

For example:

Acceptance Criteria:

Customer can update their payment method.

A QA Lead may challenge the team to make this more explicit:

Possible quality expectations:

• Customer can update a valid payment method.

• Invalid payment information is rejected.

• Customer receives an appropriate error message.

• Existing payment information remains unchanged when the update fails.

• Only authorized customers can perform the update.

• The new payment method is persisted correctly.

• Relevant payment services receive the expected event.

• Existing payment flows continue to work.

• Automated tests cover the critical scenarios.

This is where QA adds significant value.

We're not simply asking:

“Can I test this?”

We're asking:

“Can the entire team clearly understand what successful completion looks like?”

Definition of Done should be risk-based

Not every sprint ticket requires the same level of testing.

A small UI text change and a payment-processing change should not have identical quality expectations.

This is where I believe QA Leads need to bring risk-based thinking into the Definition of Done.

For a low-risk change, the definition might include:

• Functional verification

• Regression check

• Code review

• Automated test where appropriate

For a high-risk change, we may additionally require:

• API testing

• Negative testing

• Integration testing

• Security validation

• Performance testing

• Extended regression testing

• Monitoring/logging validation

• Automated regression coverage

The important point is that “Done” should reflect the risk of the change.

QA shouldn't create a checklist after development

One anti-pattern I see is QA receiving a completed ticket and creating a testing checklist after the development work has already been completed.

This often leads to questions such as:

“Why wasn't this requirement considered?”

“Why wasn't this API behaviour documented?”

“Why do we need additional development now?”

“Why didn't anyone tell us this affected another service?”

These aren't necessarily testing problems.

They are definition-of-done problems.

If quality expectations are discussed during refinement, the team can identify these issues before development begins.

That means fewer surprises during the sprint.

Definition of Done is a team agreement

This is an important distinction.

QA should not own the Definition of Done.

The Definition of Done should be agreed upon by the team, including:

• Product

• Developers

• QA

• DevOps

• Business stakeholders where appropriate

Each role brings a different perspective.

Product helps define the business outcome.

Developers define technical implementation considerations.

QA identifies quality risks and testability concerns.

DevOps considers deployment, monitoring, infrastructure and operational readiness.

Together, the team creates a much stronger definition of completion.

A practical Definition of Done for a sprint ticket

For many teams, a baseline could look something like this:

Functional

☑ Acceptance criteria are implemented.

☑ Positive and negative scenarios have been considered.

☑ Expected error handling is implemented.

Code Quality

☑ Code review is completed.

☑ Coding standards are followed.

☑ No known critical technical issues remain.

Testing

☑ Unit tests are completed where applicable.

☑ API/service tests are completed where applicable.

☑ Functional testing is completed.

☑ Regression impact has been assessed.

☑ Appropriate automation has been added or updated.

Integration

☑ Relevant integrations have been tested.

☑ Data persistence has been verified.

☑ Downstream impacts have been considered.

Defects

☑ No open Critical/Blocker defects exist.

☑ Any accepted lower-severity defects are documented.

CI/CD

☑ Automated quality checks pass.

☑ Required pipelines complete successfully.

Business Readiness

☑ Acceptance criteria are satisfied.

☑ Evidence of testing is available.

☑ The Product Owner accepts the functionality.

This doesn't need to be copied blindly into every team.

The important thing is to establish a common quality contract.

The QA Lead's role

As a QA Lead, I don't see my role as asking:

“Have you finished development?”

I see it as asking:

“Do we have enough evidence to confidently say this ticket is complete?”

That subtle difference changes how a team approaches quality.

A mature QA function doesn't wait until the end of the sprint to discover what needs to be tested.

It participates in defining:

What are we building?

What could go wrong?

How will we know it works?

What evidence do we need?

What level of risk are we willing to accept?

And ultimately:

What does “Done” actually mean for this ticket?

My view as a QA Lead

The Definition of Done shouldn't be a checkbox that QA completes at the end of a sprint.

It should be a shared quality agreement established before development begins.

QA brings an important perspective because testers naturally think about boundaries, failures, unexpected behaviour, integrations, data, regression and risk.

But quality isn't something QA adds to a ticket after development.

Quality should be built into the ticket from the beginning.

That is the difference between:

“QA tested the ticket.”

and

“The team has delivered a quality outcome.”

And for me, that is what Done should mean.