Added by vpelcak about 5 years ago. Updated almost 4 years ago.
0%
Description
ATM in openQA bugs are added to the comments and are treated so.
They do not have own database entries.
Therefore gathering any statistics about amount of reported bugs is non-trivial task.
Use case: How many bugs have we found using openQA in month X? How many in year Y? Which bugs are those?
(Picking the target version is my job).
There is a bugs table - fetched from bugzilla. And as bugs aren't reported on openqa, if they are labeled in openQA or not does not give you any useful statistic on 'how many bugs have we found'
@coolo already answered before I could submit my comment so my answer is a bit redundant:
There's actually a database table for bugs. However, it must be filled and updated via the API by an external script. So far this is done by the openQA bugfetcher script which tracks to my knowledge Bugzilla, GitHub, Progress and Jira. Since @coolo explicitly requested to implement this as an external script at the time I suppose supporting this directly in openQA is not going to happen.
If you have access to openQA's database you should be able to get the answers to your 'Use case'-questions. But as @coolo already pointed out the statistic wouldn't be very useful.
Hello.
Sorry, I didn't know if and what Target Version should I choose.
What better approach do you propose to be able to gather bugs statistics then?
We definitely need to be able to measure how do we contribute to the product quality.
Just don't set the target version at all.
What better approach do you propose to be able to gather bugs statistics then?
If the task is simply to find out "How many bugs have we found using openQA in month X?" the reviewers could maintain a table with all bugs they find using openQA. So if they find a bug they not only create a ticket in some bug-tracker but also add an entry to that table. That it would be a manual step is annoying of course. And bugs which turn out to be invalid or duplicates might be forgotten to be updated.
You could also try to flag bugs as 'found via openQA' in the bug-tracker systems we use and query their APIs directly to get the statistics. Those queries shouldn't be hard to implement. At least I remember that the mentioned openQA bugfetcher script wasn't that comprehensive.
Note that openQA is a test automation system but not a bug-tracker.
Relying on the aforementioned script, I proposed a PR to expose the time of a bug having been reported (ie. added via a comment and thus recorded in the database).
I don't see anything left to do here - please close
no response from ticket reporter. I agree that there should be nothing left to do. cdywan added last steps.