Team, What is definition of done for automation testing? For example, do we consider execution time or test case coverage?
-
1You list scenarios you want to automate and you consider automation as done when you automated those scenarios. Which scenarios to automate is, of course, a completely different question.– dzieciouCommented Jun 6, 2016 at 20:05
-
DONE is whatever your team decide it is. There is NO replacement for proper communication, and no opinions from from intewebz will change opinions of your team-mates. Books were written about the subject.– Peter M. - stands for MonicaCommented Jun 6, 2016 at 20:11
4 Answers
Automated testing is done when all the current functionality is covered by the tests, i.e. test case coverage. When the automated testing is done I always recommend manual testing on top of this.
If you have specific performance and/or load tests they will have criteria as to whether they are passing or failing, i.e. completing within the time specified.
Prior to automating a test case/test pack the checkpoints must be agreed. If you are purely automating a functional test case which does not validate how long it takes between one step and the next, in that case as long as the agreed journey is automated and functional checkpoints are met, the test case/pack is considered to be completed from scripting perspective. But if you are automating a non functional requirement/test case then it is important to have the response time validation in place.
I consider and approve any test case to be automated when it gives the same test result as a manual test.
Hope that helps, best of luck.
automation testing
automation testing is simply another type of a software project, as such it should use the same DoD of software projects adjusted to the relevant context.
Some common examples-
Documentation
The code was reviewed and approved
Unit tests covering % of the code in some way or another (yes, automated tests usually need their own set of unit tests)
The code was tested and approved
Some common, but specific to your implementation, examples-
Functional requirements are covered
Non requirements (if exist and if applicable) are covered
Naturally, like for any other software project, requirements are almost never complete so the team will need to use some common sense when deciding when a done is done.
Some tasks are simple, operating in a simple environment and as such can be considered done-done easily, while some tasks are complicated operating in dynamic environments and as such can be considered done but with followup tasks.
To use your question as an example execution time could be important factor of projects with many tests where all tests must run for every test run while for some projects execution time is almost meaningless.
Test case coverage is obviously important, but it is as good as your test cases- if something is left open in your test procedures then you can't objectively consider it done.
Your question seems to suggest a misuse of the definition of done. The DoD is applied to every product increment. In Scrum, the intent is that each backlog item builds onto the product and is therefor subject to the definition of done for that product.
The team identifies items that should be in the definition of done for the product to meet an appropriate quality standard. This will include items such as "x% automated test coverage" and "all automated regression tests run and pass" and it will also include things like "code has been reviewed" and "any architectural changes are reflected in the documentation".
DoD is not applied to different tasks.