From Fedora Project Wiki

No edit summary
(Save page-in-progress)
Line 1: Line 1:
= Revision history =
= Revision history =


Detail key dates with respect to this document.  Including it's creation date and significant updates since then.
First draft: [[User:Wwoods|WillWoods]] 19:46, 17 June 2009 (UTC)


= Introduction =
= Introduction =


Brief description of this document.
This test plan documents the process used to check the basic requirements for a Rawhide tree to be acceptable for further testing. It aims to check whether Rawhide is installable, usable as a package repo for updating, and whether critical packages are present and functional.
* The goals of this plan are to:
* ''Organize'' the test effort
* ''Communicate'' the strategy, scope and priorities of the planned tests to all relevant stake-holders for their input and approval
* Serve as a base for the test planning for future Fedora releases


In short, this is how we decide if Rawhide is broken or not.


= Test Strategy =
= Test Strategy =


Describe how the testing will be organized and executed. Is there any special order or sequence to perform actions.
There are three main components here: Repo sanity, Installability, and Basic Functionality. These three categories can be tested mostly independent of one another.


<!-- Not really sure what this section would be useful for, but feel free to fill it in
= Test Priority =
= Test Priority =
Often used to outline tiers of tests arranged from most important (tier#1) to infrequently used tests (tier#3).
TBD. No clear priorities exist yet.
-->


= Scope =
= Scope =
What will and won't be tested.
 
This plan seeks to answer three basic questions:
 
# Can current Rawhide users update their systems using this repo?
# Can this Rawhide tree be installed?
# Does the basic system (the [[Critical_Path_Packages_Proposal|"critical path"]]) work as expected for simple testing?
 
It is ''not'' intended to be an exhaustive test of any part of the system.


= Test Pass/Fail Criteria =
= Test Pass/Fail Criteria =


When do you consider testing completed or stopped?  How do you know when to stop?
Rawhide will be considered Good if all of the following conditions are met:
 
* Contains valid yum metadata (repodata)
* Contains key packages (kernel, glibc, coreutils)
* No unresolved dependencies in critical packages
* comps.xml exists and is valid
* installer images (kernel, initrd, install.img, and boot.iso) exist
* kernel boots on ''most'' machines of the primary architectures
* initrd is able to find stage2 (install.img) by at least one method (network, local CD)
* stage2 is able to detect the presence of disks attached to most common controllers
* Kernel/X is able to set up common display configurations for at least 2 out of 3 of the most common video drivers (intel, nouveau, radeon)
 
'''TODO FINISH BELOW HERE'''


= Test Deliverables =
= Test Deliverables =

Revision as of 19:46, 17 June 2009

Revision history

First draft: WillWoods 19:46, 17 June 2009 (UTC)

Introduction

This test plan documents the process used to check the basic requirements for a Rawhide tree to be acceptable for further testing. It aims to check whether Rawhide is installable, usable as a package repo for updating, and whether critical packages are present and functional.

In short, this is how we decide if Rawhide is broken or not.

Test Strategy

There are three main components here: Repo sanity, Installability, and Basic Functionality. These three categories can be tested mostly independent of one another.


Scope

This plan seeks to answer three basic questions:

  1. Can current Rawhide users update their systems using this repo?
  2. Can this Rawhide tree be installed?
  3. Does the basic system (the "critical path") work as expected for simple testing?

It is not intended to be an exhaustive test of any part of the system.

Test Pass/Fail Criteria

Rawhide will be considered Good if all of the following conditions are met:

  • Contains valid yum metadata (repodata)
  • Contains key packages (kernel, glibc, coreutils)
  • No unresolved dependencies in critical packages
  • comps.xml exists and is valid
  • installer images (kernel, initrd, install.img, and boot.iso) exist
  • kernel boots on most machines of the primary architectures
  • initrd is able to find stage2 (install.img) by at least one method (network, local CD)
  • stage2 is able to detect the presence of disks attached to most common controllers
  • Kernel/X is able to set up common display configurations for at least 2 out of 3 of the most common video drivers (intel, nouveau, radeon)

TODO FINISH BELOW HERE

Test Deliverables

Describe what the consumables will be from testing. Examples include:

  • This test plan
  • A test summary document for each major milestone
  • A list of defects filed
  • Any test scripts used for automation or verification

Test Cases

Using the level of detail required by this test plan, outline test areas and test cases to be exercised.

Test Environment

Describe the environment tests will be executed in

Responsibilities

High-level detail of who is accountable for different phases of testing.

Schedule

Outline the scheduled milestones.

Risks

Given the current scope and test priority, what are some potential risks. Are there any other contingencies should problems arrise? How will issues be dealt with when they surface.

Reviewers

References