How Should Automation Fit the Definition of Done?

TL;DR

Automation should be included in the Definition of Done when the team agrees it is required for completing a user story. If functional testing is complete but automation remains unfinished, the team should make a documented decision based on its established criteria, application stability, technical limitations, sprint capacity, and regression priorities.

Transcript

okay so hey guys this is slovenia welcome back to ravine automation labs so today we have one really good candidate his name is akshay and akshay is having some really amazing experience i can see one page of resume and looks very nice and a lot of skills with five uh years of experience guy a lot of technical skills in terms of java different tool... Read More

Key Insights

• The candidate has five and a half years of experience as an automation test analyst, with most of that experience in the banking domain and exposure to Selenium with Java, Maven, Git, Cucumber, TestNG, desktop applications, manual testing, and automated regression testing.
• The current project uses three-week sprints, and functional testers write test cases from acceptance criteria before uploading them to Azure DevOps. Functional testing and automation are organized separately, with automation work opened later as a technical story focused on regression coverage.
• Automation coverage is selected according to regression needs and technical feasibility. When some scenarios cannot be automated because of desktop-application limitations, the team can automate the feasible cases and retain manual execution for the remaining scenarios during regression testing.
• Incomplete automation caused by limited time differs from permanently non-automatable coverage. If scenarios can be automated but are unfinished, the work may move into a later sprint according to capacity, while technical limitations can justify maintaining selected scenarios as manual tests.
• The Definition of Done is the appropriate place to state whether automation is mandatory for completing a user story. Explicit criteria prevent the automation requirement from being debated repeatedly during every sprint and give the entire team a shared basis for closure decisions.
• A production decision is a team call when functional and regression testing are complete but automation remains pending. The automation tester should communicate the missing coverage and associated regression concerns, while product managers, test managers, and testers collectively decide whether the story can proceed.
• Application stability influences when automation should become part of the Definition of Done. The candidate suggests emphasizing functional testing during an unstable early phase, then adding automation criteria as features become stable enough to support reliable automated testing.
• The automation tester is the only automation resource in the candidate's current team, so regression automation is a significant personal responsibility. The role also includes helping functional testers during regression and deployment periods, writing test cases, and executing both manual and automated tests.

Questions & Answers

Q: How should automation be included in the Definition of Done?

Automation should appear as an explicit Definition of Done criterion when the team expects automated coverage before a user story is complete. The interview recommends documenting this requirement instead of explaining its importance during every sprint. If automation is one of the agreed completion points and remains unfinished, the story does not satisfy the full Definition of Done until the team changes its decision or completes the work.

Q: Can a user story be marked done if automation is incomplete?

A user story can be marked done only according to the completion rules agreed by the team. If automation is part of the Definition of Done, unfinished automation means a required criterion is missing. If functional and regression testing are complete and the product manager still wants production release, the automation tester should explain the missing coverage, and the final outcome should be a team decision rather than an individual decision.

Q: What should happen when some test cases cannot be automated?

When technical limitations make some cases unsuitable for automation, the feasible cases should be automated and the remaining cases should stay in the manual regression set. The candidate gives an example in which eight out of ten cases might be automated while two continue through functional testing. Under that approach, the story can be completed because the team has acknowledged the application limitations and preserved coverage manually.

Q: What should happen when automation is delayed by limited sprint capacity?

When scenarios are technically automatable but cannot be completed because of time, complexity, leave, or sprint capacity, the unfinished work should remain visible and be planned for a later sprint. The candidate describes reopening or continuing the automation work in the next sprint according to capacity. The team should distinguish this temporary delay from cases that cannot be automated because of permanent desktop-application limitations.

Q: Who decides whether a tested feature can move to production?

The product manager, test manager, automation tester, and other testers should make the decision collectively when functional testing is complete but automation remains pending. The automation tester is responsible for identifying the uncovered regression scenarios and explaining possible conflicts with existing code or application behavior. After that communication, release approval is a team call, and responsibility for the accepted risk belongs to the team.

Q: When should automation become part of a project's completion criteria?

Automation can be added to the completion criteria after features and functions become stable enough to automate effectively. The candidate argues that early development may focus primarily on functional testing while the application is still changing. As the application stabilizes, the team can revise its Definition of Done to include automation testing, ensuring that mature features receive repeatable regression coverage before completion.

Q: How does the candidate's team manage functional and automation work?

The team follows three-week sprints and uses Azure DevOps for daily test-management activities. Functional testers write cases from the acceptance criteria, upload them, execute the tests, and close the functional user story. The automation tester then creates a separate technical story, reviews the regression suite, selects suitable cases for automation, and implements them according to project priorities and available capacity.

Q: What responsibilities does an experienced automation test analyst handle?

The candidate's responsibilities include automating desktop-application scenarios from user stories and acceptance criteria, identifying regression cases for automation, writing and executing tests, and maintaining manual coverage where needed. As the team's only automation resource, he also supports functional testers during regression and deployment activities. His described tool experience includes Selenium with Java, Maven, Git, Cucumber, and TestNG.

Summary & Key Takeaways

• Akshay describes five and a half years of automation testing experience, primarily in banking projects serving clients such as Barclays and HSBC. His technical background includes Selenium with Java, Maven, Git, Cucumber, and TestNG. In his current project, he automates a desktop application while also supporting functional testing, test execution, and regression activities.

• The current team follows three-week sprints and manages testing through Azure DevOps. Functional testers create and execute cases based on user-story acceptance criteria, then close the functional story. Automation work is handled through a separate technical story after the team identifies regression scenarios that are suitable and valuable for automated coverage.

• The interview focuses on whether incomplete automation should prevent a user story from being marked done. The discussion concludes that teams need an explicit Definition of Done. Automation may initially remain separate while an application is unstable, but the criteria can be revised as features mature and reliable automation becomes practical.