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
No edit summary
Line 2: Line 2:


=What is QA=
=What is QA=
Few documents related to QA/Testing on Wikipedia: [http://en.wikipedia.org/wiki/Software_quality_assurance], [http://en.wikipedia.org/wiki/Software_testing]
Here few documents related to QA/Testing on Wikipedia: [http://en.wikipedia.org/wiki/Software_quality_assurance], [http://en.wikipedia.org/wiki/Software_testing]


=Introduction=
=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 project but also for any company using Moodle.
The document described the Moodle QA. Any participation is welcome. Please use the tab "page comments" in order to participate. A good Moodle QA will be a great benefit for Moodle project but also for any company using Moodle.


=QA Objective=
=QA Objective=
Main objective: is a major release ok for release?
Main objective: is a major version ok for release?


A major release is ok when (TBD):
A major version is ok when (TBD):
* critical bug number < 5%
* critical bug number < 5%
* major bug number < 20%
* major bug number < 20%
Line 18: Line 18:


=Need to be identified=
=Need to be identified=
QA Cost (in persons/hours) for:
QA Cost (in persons-hours) for:
* writting test cases (first time, then updated)
* writting test cases (the first time)
* preparing the QA cycle (update test case, get a new QA system ready for testing, update test data)
* preparing the QA cycle (update test case, get a new QA system ready for testing, update test data)
* delivered a test data package?
* create a test data package for people testing on local?
* running test cases
* running all test cases


When a QA cycle should be run
When should a QA cycle be run?<br>
 
What function specs/Use Cases have we got?<br>
Who can write test cases
Who can write test cases?<br>
 
Who can run test cases?<br>
What Function specs/Use have we got
 
Who can run test cases


=Draft/Ideas/Opinion/Requirements/Notes=
=Draft/Ideas/Opinion/Requirements/Notes=
* There is a lack of Functional Specification and Use Case. Only Developers and experimented user would be able to write such document.
* Test case should usually not be written by developers neither people writting functional specs.  Probably cannot follow this rule. The main is reason is that test case writer usually uses Use Case (and functional specs) in order to write test case. I don't think that such document are going to be written. So Developers and experimented user will have to write the test cases.
* 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.)
* 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.
* There is a lack of detailed functional specifications and Use Cases => at this moment only developers and experimented user would be able to write functionality with missing use cases. (not so good)
* JIRA as a Test Case Management System: We'll create a main issue containing thousand of sub-tasks. These subtasks will be Test Case.
* use JIRA tracking system: we will use Jira as Test Case Managment system. Jira as not been developed for Test Case Management system but it can be used in order to manage a simple QA environment. The main reason to use Jira is to use a software that the community is familiar with.
* study Quality Assurance into open source world, how does the other project manage their QA department?
* I need to study Quality Assurance into open source world: how does the other projects manage their QA department?
* Moodle doesn't have deadline. It is released when it will be ready. But avoid no-end QA phase.
* Moodle doesn't have deadline. It is released when it will be ready. But avoid no-end QA phase.
* experimented user can test Moodle.
* there are many experimented users that can test Moodle.
* some people/company using Moodle probably have already written test plans, test cases, maybe use case.
* some people/company using Moodle probably have already written test plans, test cases, maybe even use cases.
* need documentation on how to write a test case
* need documentation on how to write a test cases and how to run test case. Need also document for QA administrator (setting a QA cycle, read the result, managing the QA cycle)


=Jira=
=Jira=
The search tool of Jira will provide the QA results. Need to identify exatcly how.
* The search tool of Jira will provide the QA results. Need to identify exatcly how.
* JIRA as a Test Case Management System: We'll create a main issue containing thousand of sub-tasks. These subtasks will be Test Case.

Revision as of 04:29, 22 September 2008

What is QA

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

Introduction

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

QA Objective

Main objective: is a major version ok for release?

A major version is ok when (TBD):

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

A successful QA cycle assures that we have tested all major Moodle functionalities.

Need to be identified

QA Cost (in persons-hours) for:

  • writting test cases (the first time)
  • preparing the QA cycle (update test case, get a new QA system ready for testing, update test data)
  • create a test data package for people testing on local?
  • running all test cases

When should a QA cycle be run?
What function specs/Use Cases have we got?
Who can write test cases?
Who can run test cases?

Draft/Ideas/Opinion/Requirements/Notes

  • 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.)
  • There is a lack of detailed functional specifications and Use Cases => at this moment only developers and experimented user would be able to write functionality with missing use cases. (not so good)
  • use JIRA tracking system: we will use Jira as Test Case Managment system. Jira as not been developed for Test Case Management system but it can be used in order to manage a simple QA environment. The main reason to use Jira is to use a software that the community is familiar with.
  • I need to study Quality Assurance into open source world: how does the other projects manage their QA department?
  • Moodle doesn't have deadline. It is released when it will be ready. But avoid no-end QA phase.
  • there are many experimented users that can test Moodle.
  • some people/company using Moodle probably have already written test plans, test cases, maybe even use cases.
  • need documentation on how to write a test cases and how to run test case. Need also document for QA administrator (setting a QA cycle, read the result, managing the QA cycle)

Jira

  • The search tool of Jira will provide the QA results. Need to identify exatcly how.
  • JIRA as a Test Case Management System: We'll create a main issue containing thousand of sub-tasks. These subtasks will be Test Case.