AutoQA resultsdb use cases

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Task: [kparal + jskladan] - Define personas and write use cases
Example: No_frozen_rawhide_announce_plan#Use_Cases

Use cases for the AutoQA resultsdb

Some of these use cases are not specific to resultdb, they should be moved to AutoQA Use Cases.

Michael wants to push a new update for his package.
- Michael just submits his package update to Fedora Update System and it takes care of the rest. Michael is informed if there is some problem with the update.

Michael wants to know how the AutoQA tests are progressing on his update.
- Michael inspects the progress of AutoQA test in a web front-end. Michael can easily see if the tests are waiting for an available hardware, or they have already started, or they have already all finished. Michael sees the results of already completed tests continuously and may explore them even though all the tests have not finished yet.

Michael wants to know if there is something he could do to improve the quality of his package.
- Michael observes AutoQA results for recent updates of his package in a web front-end. He goes through the output of advisory tests and also through the ouput of other tests that is marked as "attention recommended".

Michael was warned that his package update failed automated QA testing and wants to see the cause.
- Michael inspects AutoQA results for the last update of his package in a web front-end. He goes through the mandatory and introspection tests output and reads the summary. If additional information are needed, he opens the full tests' logs.

Michael wants to waive errors related to his package update, because he's sure the errors are false.
- Michael logs with his Fedora account to a AutoQA web front-end to prove he has priviledges to waive errors on a particular package. He inspects the errors on his package update and waives them if they are false.

Michael wants to report a false error from one of AutoQA test cases and ask AutoQA maintainers for a fix.
- Michael follows instructions on AutoQA wiki page (or web front-end) and uses a mailing list or bug tracker to report his problem.

Caroline knows that some recent tests failed because of hardware problems with test clients. She wants to re-run the tests again.
- Caroline logs in into the AutoQA web front-end, selects desired tests and instructs AutoQA to run them again.

Caroline declares a war on LSB-incompliant initscripts. She wants to have all packages tested for this.
- Caroline uses CLI to query AutoQA Results DB for results of 'Initscripts check' test for all recently updated packages. If she is not satisfied, she will instruct AutoQA to run this test on all available packages. <<FIXME - how?>>

Nathan is curious about possible ways to make his program better.
- Nathan checks the web front-end of AutoQA and displays a list of tests that were performed on his program recently. He checks the tests' descriptions and chooses those tests which are related to the program itself, not to packaging. He inspects the results of these tests and looks for errors, warnings or other comments on program's (wrong) functionality. Some serious errors should have been probably already reported to Nathan by corresponding package maintainer, but there may be other less-serious issues that were not.

Kate is heavily interested in Rawhide composition. She wants to be every day notified if composing of Rawhide succeeded or failed, eventually why.
- Kate creates a script that remotely queries AutoQA Results DB and asks for current Rawhide compose testing status. She runs this script every day. In case Rawhide composition fails, the script notifies her and also presents her with a link leading to a AutoQA web front-end with more detailed results of the whole test.

Fedora Update System needs to know what the current status of AutoQA tests is for a particular NVR.
- Fedora Update Systems asks ResultsDB about a particular NVR and receives an answer whether the tests were already executed or not and eventually their result.

ResultsDB front-ends need to display not only results to individual packages, but also overview of results summaries ('Show me all failed tests for the last week').

Fedora Update System wants to have relevant people notified when the status of AutoQA tests changes for a particular update.
- Option 1 - Fedora Update System sends the notices: AutoQA must support registering a listener. Fedora Update System registers a listener for a particular update and AutoQA notifies it for every change on that update (this is particularly needed for subsequent changes, like UNTESTED → NEEDS_INSPECTION → WAIVED).
- Option 2 - AutoQA sends the notices: AutoQA has hardcoded in the tests whom to send noticies.
- Option 3 - AutoQA sends the notices: Fedora Update System supports querying for the recipients of the notices. AutoQA query Fedora Update System for the recipients and sends them a notice.
- Option 4 - Fedora Notification Bus: All update result changes are sent to the common Notification Bus and anybody can catch those notifications and do anything he wants with it. This is in a far future.