Question 1

Describe the QA role in an Agile team.

Accepted Answer

Structure the answer along the sprint timeline — it reads as organised immediately. Refinement: I question the stories, make sure the AC are verifiable, get error and edge cases added. Planning: I estimate test effort and propose an order so work doesn't pile onto the last day. Through the sprint: I test each story as it lands, log bugs immediately, work directly with the developer. Demo: I make sure the demo will hold up and flag known limitations in advance. Retro: I turn quality problems into process proposals. Finish with a positioning sentence: "I'm not a gate standing at the end of the sprint — I'm a team member providing information about quality throughout it."

Question 2

What do good acceptance criteria look like? Give an example.

Accepted Answer

The criterion is simple: each AC must yield a test case with an unambiguous pass/fail result. Good AC are concrete, carry numbers and boundaries, and describe the error case alongside the success case. Show it by comparison — that's the most effective device: "Weak AC: 'A discount is applied for loyal customers.' Strong AC: 'A customer with 3 uninterrupted years of policies and no open claims receives a 10% discount; the discount amount is shown on its own line above the total. If the customer isn't eligible, the discount line is not displayed.'" Close by noting that writing AC is the PO's job while making them verifiable is QA's — that sentence frames the role boundary correctly.

Question 3

Stories arrive for testing on the last day of the sprint. How do you solve this?

Accepted Answer

This is a classic, and your answer must be a solution, not a complaint. Short term: I test risk-based — critical flows first, the rest after; and I report in writing what wasn't tested. Long term — this is the real answer: (1) I raise it in retro with data: how many stories in the last 3 sprints arrived in the final two days and how many bugs slipped past the sprint; (2) I propose smaller stories and staged handover in planning; (3) I agree with developers on "give it to me as soon as it works" — a testable slice, not the whole story; (4) I propose adding "a story must be ready for testing before the sprint's last day" to the DoD. The emphasis: this is a team problem, not the QA's personal problem — and it must be presented that way.

Question 4

Your team has no Definition of Done. What would you do?

Accepted Answer

First I make the problem visible, because a missing DoD usually shows up in other forms: "done" stories coming back, the level of testing differing every time, surprises at release. In retro I bring up one of those symptoms as an example. Then I propose a seed, not a finished document: a 5-6 item list built with the team — code reviewed, unit tests passing, all AC verified, no open Critical/High bugs, docs/release notes updated. The key nuance: I don't write and present it alone — when it's written together, the team owns it. Then we apply it for a few sprints and revisit in retro. This answer shows initiative and the ability to work with the team at the same time.

Concept	What it means	The QA's part
Definition of Ready (DoR)	Conditions for a story to be pulled into a sprint (AC exist, design exists, dependencies clear, estimated)	Confirms the AC are verifiable; raises test data and environment readiness
Definition of Done (DoD)	Conditions for a story to count as finished (code reviewed, tests passed, documented, deployed)	Ensures "tested with no open Critical/High bugs" is part of the DoD
Backlog refinement	The meeting where upcoming stories are clarified and estimated	The QA's highest-value meeting: raises ambiguities, edge cases and error flows here
Sprint planning	Deciding what goes into the sprint	Estimates test effort; makes sure everything doesn't pile up on the last day
Daily standup	The daily 15-minute sync	Reports blockers immediately (no build, broken environment, missing data)
Sprint review / demo	Showing the completed work to stakeholders	Makes sure the demo will hold up; flags known limitations in advance
Retrospective	Discussing what did and didn't work in the process	Turns quality problems into process actions (e.g. "AC arrive too late")

Agile artifacts & the QA role

📚 Sources and documentation