I had a some interesting discussions this week about testing metrics for my team. We are not doing anything out of the ordinary from other agile development shops, so like others, I have management asking me to provide metrics on the work my group is doing and how do I know testing is done.
We are using Jira to track stories, tasks and defects, and TestRail to track our test cases, sets and milestones. Not saying either one of those are better than any other tool, but they work for us. We completed a big bang redesign of our website late last year and these tools worked really well for us. Specifically, we were able to track our manual tests in TestRail through monthly milestones and provide our management with a daily pass/fail/block/na/no run status, which was really helpful in keeping them informed and not asking questions.
But now that the big-bang release is done, we are back to our scrums. We have 6 scrum teams with 1 QA resource for each team. We have the ability to do daily releases, so how are we going to track how many tests cases we write and then run, while still maintaining rapid releases?
So far, we have settled on using TestRail milestones, sets and test cases for new feature and functions. For bug fixes we will put in our test results on the Jira ticket and we will record a dummy test to record our automated results. We have the option to import our automated tests out of Jenkins to TestRail, but I'm not sure if that is needed.
We have had really good throughput on the fixes since the release but we have not had to report any work metrics, so I'm not sure if I can continue to not report anything. I'm going to try this approach for awhile and then revisit this after we get some releases under our belt. Once I do, I will figure out if this approach will work or if we need to do something different to show what we did.
Ping me @todddeaton if you have a good way of showing test results when you have disparate scrums.
No comments:
Post a Comment