When we are doing automation testing project (5000 Man days project), What are the metrics needs to capture in the agile scrum method other then
1. Number of user stories automation,
2. No of lines covered
3. Defects captured.
Here my tricky questions is When we need to start automation; Same user story in the same spirnt or in the next sprint? (After complete the development activity manual testing is part of the same sprint) One of my client want's to complete Automation scripts also needs to complete in the same sprint. Really its very challenging, How to handle this situation. Saving Changes...
Ideally, all test cases are automated such that the focus of your testing resources is on designing methods of maximizing quality vs doing manual testing.
I would focus more on code coverage and the percentage of acceptance criteria which were addressed through automation than defect counts as with the latter you will hit the law of unintended consequences.
As far as when automation should happen, if a story has good acceptance criteria, the test analyst should create the automation within the same sprint so that when it has been developed, it can be fully tested via automation.
Throw in cycle time for stories and defects. Capturing the number is great, but improving their cycle time is also important. Saving Changes...
Nguyen QuangProject Manager| INGENICOHanoi, Hn, Viet Nam
You actually need an Define Of Done (DOD) for automation tasks first. My metrics apply with automation test team like:
1. How many manual TC can automate?
2. How many manual TC cannot automate, and why?
3. How many manual TC is in Autoing (Auto script is developing)
It's super hard to manage a Automation test team with 5000 man days, it's too big in my view. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
It is hard to me to understand why you are asking for this metrics. The question is: why to automate testing? Something obvious but critical to take into account. And that is for all the type of approach you are taking. Is a cost vs benefit relation. In my personal experience, mainly today, is more closely to DevSecOps implementation than other type of things (today called in this way but nothing new below the sun). Saving Changes...
Latha Thamma reddiSr Product and Portfolio Management (Automation Innovation)| DXC TechnologyMckinney, Tx, United States
