Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Quality assurance: Difference between revisions

From MoodleDocs
No edit summary
Line 16: Line 16:


A successful QA cycle assures that we have tested all major Moodle functionalities.
A successful QA cycle assures that we have tested all major Moodle functionalities.
= Setting a QA cycle =
== First time ==
Write test cases
== Every QA cycle ==
Update test cases for matching new features
= Running a QA cycle =
All participants choose the feature they want to test. If they found blocker/critical/major bug, they mark the test case as "failed" and link it to a bug issue. All "failed" test cases will be marked as "to retest" by the bug fixer. If the bug is minor and the feature is working, they mark the test case has passed.


= QA Results =
= QA Results =
The Test Case management system needs to display:
The Test Case management system needs to display:
* how many test cases are failed and how many are passed for a specific version/component. (test case issues)  
* how many test cases are "failed","passed","not run","to retest" for a specific version/component. (test case issues)  
* how many critical/major bugs for a specific version/component (bug issues)
* how many critical/major bugs for a specific version/component (bug issues)



Revision as of 05:30, 22 September 2008

What is QA

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

Participate to QA for your benefit

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.

Setting a QA cycle

First time

Write test cases

Every QA cycle

Update test cases for matching new features

Running a QA cycle

All participants choose the feature they want to test. If they found blocker/critical/major bug, they mark the test case as "failed" and link it to a bug issue. All "failed" test cases will be marked as "to retest" by the bug fixer. If the bug is minor and the feature is working, they mark the test case has passed.

QA Results

The Test Case management system needs to display:

  • how many test cases are "failed","passed","not run","to retest" for a specific version/component. (test case issues)
  • how many critical/major bugs for a specific version/component (bug issues)

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)
  • need to link Moodledocs QA documents with Moodle docs tracker documents, organize an easy to read Quality Engineering section into Moodledocs (include Code Testing as well).
  • we could create a testing program as Netbeans [3]

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.

QA for other projects

Netbeans [4]