Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »


QA stands for Quality Assurance. In this context the QA mission is primarily to uncover and report software bugs, to verify software bugs that have been fixed, and to test new features for regressions (new bugs inadvertently introduced when adding a new feature) for the Sakai CLE software.

Pre-requisites for participating

Required - a Jira account is required. Sign up at

RequiredJoin Sakai QA email group ( or Sakai Dev group ( to keep up to date with the latest announcements and ways to help with the testing effort.

Optional - Jira QA group - special permissions - You do not need special permissions to test fixes and to comment on Jira issues. There is a "Tested" button that indicates successful testing of a Jira issue. This button is only available if you are a member of the Jira QA group. This permission is granted to experienced testers. Contact for more information.

Hints - Our primary tools are Jira, Google docs spreadsheets, and QA servers. Learning how to use Jira and what the fields represent is well worth the time.

Ways to Participate

  • Verify bugs that have been fixed.
  • Test new features.
  • Regression test existing features. 
  • Create Regression scripts (i.e. step-by-step instructions for performing regression tests.)
  • Release testing - testing alpha, beta, and release candidate versions before software is made generally available (GA aka production). 
  • Help maintain QA documentation in Confluence. Proof read. Make suggestions. Create short videos. 
  • Ask and answer questions on the email groups. 
  • QA team meetings. Attend the QA to bring up issues that need attention, to help plan for testing for releases, and more.

Verifying bugs and testing new features

We sometimes call this kind of testing Jira testing, because bugs and features are reported in Jira, and we can easily track the status of a Jira to know when it is ready for testing and to understand if it is targeted to be included in an upcoming release. 

Bugs and features are first tested on the Trunk server. The Trunk server is the most up-to-date code contributions from the community. Therefore, not everything in Trunk is intended for the current released software, some is intended for a future version of Sakai CLE. 

The merge flag indicates if a feature or bug fix should be included in an existing supported release of Sakai CLE. For example, "2.9.x status" is the merge flag for Sakai CLE 2.9. If it is set to the value of "Merge", then the fix or feature is intended for the next maintenance release of 2.9 (e.g. Sakai CLE 2.9.2). The Jira guidelines is documented. Once merged, the flag will be set to "Resolved". This means that it is now in the 2.9.x "branch".

Just like the Trunk is the latest release of the contributed software code base for Sakai CLE, the 2.9.x branch is the latest release of software which will make its way into CLE 2.9. Therefore, like Trunk, 2.9.x is constantly changing, though not as fast as Trunk. This is important. We have a branch manager for the 2.9.x release so that we can ask him/her to merge those fixes, but also so he can stop adding changes when we are ready to make a release. Test-Fix-"Merge-fixes-back-to-branch"-Test until we are happy with the quality of the software. Then it gets "tagged", which is a way of gluing all the bits of software that make up the release, so even as more changes are made to the "branch", the tag will never change, because it is a snapshot of the ever-changing-branch at a point in time. The tagged software gets bundled up and shipped (made available) to the community. 

Regression Testing

Regression Testing with Scripts

Release Testing

See the latest 2.9 Test Fest 

Special Needs

  • Accessibility Testing
  • Localization Testing (different languages)
  • Security testing (requires special permission)


  • No labels