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 https://jira.sakaiproject.org
Required - Join Sakai QA email group (email@example.com) or Sakai Dev group (firstname.lastname@example.org) to keep up to date with the latest announcements and ways to help withthe 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 email@example.com for more information.
Hints - Our primary tools are Jira, Google docs spreadsheets, and QA servers.
- Over time, learn to update Jira fields
Ways to Participate
- Verify bugs that have been fixed.
- Test new features.
- Regression test existing features. Regression testing is a detailed step-by-step test of a tool using a test script. Regression testing is more time consuming than verifying bugs, but is also one of the best ways of assuring the quality of the software.
- Creating Regression scripts. Regression scripts need updating when features (usually Sakai tools) are updated. When new features are added, new regression scripts need to be created. Often testers find it efficient and necessary to perform the regression test while creating or updating the test script, to ensure that the script is accurate. This serves double duty of testing the feature and creating the script.
- Release testing. When we create a major or minor release of Sakai we go through a process: merging in features for major releases and fixes for both major and minor releases. We test a pre-release version of this software on one or more QA servers . If we find problems that prevent the release from becoming generally available (GA or production) then we fix those issues and create another pre-release version, which goes onto QA servers for another round of testing. Release testing typically includes a combination of verifying bugs, testing new features, and performing Regression testing.
- Help maintain documentation in Confluence. Proof read. Make suggestions. Create short videos. Ask questions.
- Bi-weekly meetings. Attend the QA bi-weekly meetings 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.
See the latest 2.9 Test Fest
- Accessibility Testing
- Localization Testing (different languages)
- Security testing (requires special permission)