- 1 Introduction
- 2 Test Developer Use Cases
- 3 Administrator Use Cases
- 4 Package Maintainer Use Cases
This page is intended to be a comprehensive list of all the ways people will interact with AutoQA. All items will be focused on outlining the steps required to accomplish a specific task. This page will detail activities for test developers, administrators, release engineers and package maintainers. This page follows a similar design to the Fedora_Talk_Admin_Cases and related pages.
- If the use case works today, there should be a link to a wiki page explaining how to do it
- If the use case does not exist yet, there should be a link to an AutoQA Ticket.
Test Developer Use Cases
The following use cases are aimed at Roger. Roger is active in the QA community and would like to help QA team to catch as many problems as possible before they reach Fedora users. He decided to write a new test and integrate it into AutoQA framework to increase the test coverage.
Decide what to test
- Roger examines the list of available tests to see which tests are already executed. For each test he looks into the control file to read a short description of that test.
- Roger examines the list of available hooks to see which events are monitored. For each hook he reads the README file to read a short description of the hook and the testlist file to see which tests are executed when corresponding event happens.
- Roger finds a problem area that is not currently covered by tests and he would like to cover it. Roger takes into consideration if the new test would be triggered by an existing hook (easier) or a new hook would have to be written (harder). He also considers if the new test would utilize existing standalone tools and scripts (like rpmlint, repoclosure, etc.) or new tools would have to be written to achieve the goal.
- Roger now has a clear idea what he wants to test.
Collect prerequisites for the test
- Roger needs a tool that would get the required work done (eg. traverse the repository, validate the packages, etc).
- The tool is either already existing (eg. repoclosure, rpmlint, etc) or must be yet written.
- If the tool doesn't already exist Roger creates one. It is a standalone tool written in arbitrary programming language and using arbitrary libraries. The only important things is that it makes reasonable use of standard input, standard output and command-line arguments and therefore it can be easily run in an automated fashion.
- Roger now has all the standalone tools needed for his task to be done.
Determine when the test should run
- Roger examines the list of available hooks to see which events are monitored. For each hook he reads the README file to read a short description of the hook.
- Roger examines the autoqa.cron file to see how often there is a check for new events for different hooks by default.
- If Roger needs more detailed information he examines the watchers (watch-*.py files in hooks' directories) to see the current implementation. By seeing the source code he can find out some important details.
- Roger now knows which hook (which event type) is most suitable to trigger his new test.
- If no existing hook suits Roger's requirements, a new hook has to be created. Roger creates one according to Writing AutoQA Hooks. Because that is not an easy task to do, he consults the AutoQA team on autoqa-devel mailing list and receives important advices or even help with doing that.
Integrate the test into AutoQA
- Roger reads through AutoQA architecture to have a basic overview how AutoQA works.
- Roger installs autotest and AutoQA - FIXME. Roger chooses to install autotest-client+autoqa if his test can be run locally on his own machine and he doesn't want to spend time configuring autotest-server. Roger chooses to install autotest-server+autoqa if his test is more sophisticated or he is willing to configure autotest-server and its clients.
- Roger creates control file and test object according to Writing AutoQA Tests.
Verify the test works
- Roger has created a new AutoQA test. He is sure that the standalone tools he's using inside the test are working well, but he wonders if he has written all the AutoQA control files correctly and if the test as a whole will function properly. He needs to verify that.
- Roger verifies his new test according to FIXME, meaning:
- Roger runs the corresponding watcher with --dry-run option to see the list of commands that would be run normally.
- Roger picks one suitable commands and runs it with --test <his_test_name> option to run just his new test for the chosen event. He also appends --local if he has not autoqa-server installed and wants to execute the test on local computer.
- Roger reviews the output on the screen and in the test's result dir. He modifies the test until he is satisfied with the output.
- Roger has now verified that his new test is working properly in the AutoQA environment.
Contribute the test
- Roger has a new test, which seems to be working well. He wants to publish it in the AutoQA project upstream.
- Roger creates a new ticket in AutoQA Trac and provides a patch or a link to his git branch there.
- Roger can also start a discussion in autoqa-devel mailing list about his work.
- Roger waits until his new work is accepted.
Administrator Use Cases
These use cases are aimed at Nancy. Nancy is a member of the Fedora Infrastructure team and has been asked to help the AutoQA project with sysadmin tasks that require access to infrastructure systems and tools.
Create a AutoQA system from scratch
- Her first task is to prepare a new Fedora system
- Once the system is prepared, Nancy reads and follows the instructions for how to Install_and_configure_autotest
- Now, Nancy must install AutoQA packages - 
Add a new test system to AutoQA
- Nancy first started by setting up an AutoQA system from scratch (see #Create a AutoQA system from scratch)
- Next, Nancy wants to add one or more systems that Autotest will use as test systems. She does so by following the instructions at How_to_add_autotest_clients
Recover a failed test system
Remove a test system
Update puppet configuration
Package Maintainer Use Cases
Ned is the maintainer of several packages in Fedora. After having dealt with a several reoccurring bugs in the last round of updates to his packages, Ned would like to write some tests to help capture the failures before they happen.
View existing test coverage
Write a test
- See #Write_a_test perhaps?
- Where do they store the tests? In CVSDist?
Run the test(s) manually
Test for proper integration of the test(s)
Subscribe for notifications to a selected test (or test/package combination)
Received notification of test failure ... need more details?