(Draft outline) |
(More initial content) |
||
Line 1: | Line 1: | ||
This page is intended to be a comprehensive list of all the ways people will interact with AutoQA. This page will detail activities for ''' | = Introduction = | ||
This page is intended to be a comprehensive list of all the ways people will interact with AutoQA. 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 works today, there should be a link to a wiki page explaining how to do it | ||
Line 5: | Line 7: | ||
= Test Developer Use Cases = | = Test Developer Use Cases = | ||
The following use cases are aimed at Roger | |||
== Write a test == | == Write a test == | ||
* What guidelines can we offer for a test? | |||
* Is there a hello world example? | |||
== Fix an existing test == | == Fix an existing test == | ||
* Where is the code? | |||
* How are patches submitted | |||
* Where are patches discussed | |||
== Integrate a test into AutoQA == | == Integrate a test into AutoQA == | ||
= | * How do you know it works when running inside AutoQA? | ||
= 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 == | == Create a AutoQA system from scratch == | ||
Line 21: | Line 36: | ||
== Remove a test system == | == Remove a test system == | ||
== Update puppet configuration == | |||
= Release Engineer Use Cases = | |||
== Prevent breaking ''updates'' repo dependencies == | |||
= Package Maintainer Use Cases = | = 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. | |||
== 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) == |
Revision as of 15:26, 13 November 2009
Introduction
This page is intended to be a comprehensive list of all the ways people will interact with AutoQA. 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
Write a test
- What guidelines can we offer for a test?
- Is there a hello world example?
Fix an existing test
- Where is the code?
- How are patches submitted
- Where are patches discussed
Integrate a test into AutoQA
- How do you know it works when running inside AutoQA?
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
Add a new test system to AutoQA
Recover a failed test system
Remove a test system
Update puppet configuration
Release Engineer Use Cases
Prevent breaking updates repo dependencies
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.
Write a test
- See #Write_a_test perhaps?
- Where do they store the tests? In CVSDist?