Note: You are currently viewing documentation for Moodle 2.0. Up-to-date documentation for the latest stable version is available here: Quality assurance.

Quality assurance: Difference between revisions

From MoodleDocs
Line 8: Line 8:


=QA for Moodle=
=QA for Moodle=
In a first time, we will use QA for major release in order to approved it.
Main objectif: Test the a major release is ok for release
 
A major release is ok when (TBD):
* critical bug number < 5%
* major bug number < 20%
* new functionalities has been implemented
 
=Need to be identify=
QA Cost (in persons/hours) for:
* writting test cases (first time, then updated)
* preparing the QA cycle (update test case, get a new QA system ready for testing, update test data)
* delivered a test data package?
* running test cases
 
When a QA cycle should be run
 
Who can write test cases
 
What Function specs/Use have we got
 
Who can run test cases


=Draft/Ideas/Opinion/Requirements/Notes=
=Draft/Ideas/Opinion/Requirements/Notes=

Revision as of 03:49, 22 September 2008

What is QA

Few documents related to QA/Testing on Wikipedia: [1], [2]

Introduction

The document will set up the Moodle QA lines. Any participation is welcome. Please use the tab "page comments" in order to participate to the writting of this page. A good Moodle QA will be a great benefit for Moodle but also for any company using Moodle.

QA for Moodle

Main objectif: Test the a major release is ok for release

A major release is ok when (TBD):

  • critical bug number < 5%
  • major bug number < 20%
  • new functionalities has been implemented

Need to be identify

QA Cost (in persons/hours) for:

  • writting test cases (first time, then updated)
  • preparing the QA cycle (update test case, get a new QA system ready for testing, update test data)
  • delivered a test data package?
  • running test cases

When a QA cycle should be run

Who can write test cases

What Function specs/Use have we got

Who can run test cases

Draft/Ideas/Opinion/Requirements/Notes

  • there is a big lack of Functional Specification and Use Case. Developers and experimented user will be able to write such document. Need to identify them.
  • Test case should usually not be written by developers neither people writting functional specs. Probably cannot follow this rule.
  • We need to make a clear statement of the Moodle docs in order to make a difference between: User Manuals, Function Specifications, Technical Specifications, Requirements, ... and many mixed document. (The moodle docs are a powerful resource of information, however at the current time Google is your best friend in order to find information.)
  • use JIRA tracking system: we will use Jira as Test Case Managment system. Jira as not been developed for Test Case Management system but can be use for manage simple QA environment. The main reason to use Jira is to use a software that the community is familiar with.
  • JIRA as a Test Case Management System: We'll create a main issue containing thousand of sub-tasks. These subtasks will be Test Case.