I am trying to "develop a formula" which will give me a number which will serve as an indicator of whether the overall quality of all tested items on a certain sprint is good enough so that we can push this bundle to production. The way I was thinking to do it is to assemble a group of metrics and then give a grade to each per it's "importance" and in this way to eventually calculate the final grade. Our products are both web (Desktop and mobile)and also native mobile. I am looking for a recommendation regarding these metrics. I am perfectly aware that there is no "magic" list and this varies between products/companies but still, hearing some recommendations can be a great help.
-
11 - "Quality is value to someone (who matters)" Jerry Weinberg. And as Carl Menger already showed, value is subjective. I would be reluctant to present to stakeholders a number for quality (== value); I would suggest providing the numbers that matter to the people who matter and let them decide what is their evaluation; 2 - Building on the definition above, you question is too broad. Explaining better who are the people that matters for your context would be important for any evaluation of what metrics would be interesting.– João FariasCommented Sep 3, 2020 at 19:43
Add a comment
|
2 Answers
Your question is a bit broad. I like to automate everything. Test and code quality can be gated by a open source static code analysis tool like SonarQube. They also provide a best practise "Sonar Way" rule set:
The quality gate "Sonar way" is provided by SonarSource, activated by default and considered as built-in and so read-only. It represents our view of the best way to implement the Clean as You Code concept.
This uses some key metrics like test-coverage, code-maintanbility, but also security. It has a dashboard for reporting, but also automated alerts and an API.
answered Sep 3, 2020 at 12:29
While your question is indeed broad (without knowing your company's specific processes), what you're asking seems like how to provide relevant advice from a quality/testing perspective, typically used during a Go/NoGo meeting.
I'm not sure if it's a good idea to try and boil this down to a simple number, but you could (automatically) construct a report every sprint that takes into account, for example:
- the automated test coverage and pass/fail percentage
- the manual test coverage
- any open/known issues
If you add the severity/risk for each of those items, you can give informed advice to management.
