From Fedora Project Wiki

(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 '''package maintainers''', '''test developers''' and '''users'''.  This page follows a similar design to the [[Fedora_Talk_Admin_Cases]] and related pages.
= 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 ==


= AutoQA Administrator Use Cases =
* 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 =


== I'd like to write a test to be run every time a build my package ==
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

  1. See #Write_a_test perhaps?
  2. Where do they store the tests? In CVSDist?

Run the test(s) manually

Test for proper integration of the test(s)