For the last couple of weeks, Jordan Mantha been working behind the scenes on creating a community Ubuntu QA (quality assurance) team. For quite a while Canonical has largely driven QA efforts in Ubuntu. The community can and should step up in this area (see this wiki page for more background information).
In short, a new community-driven Ubuntu QA team is up and running! The IRC channel is #ubuntu-quality and the mailing list is ubuntu-qa.
From the team wiki page:
The Ubuntu QA team is focused on developing tools, policies, and practices for ensuring Ubuntu’s quality as a distribution as well as providing general advice, oversight, and leadership of QA activities within the Ubuntu project.
In general, QA in Ubuntu is broken down into the following areas:
- Defect Management (Bug Triage)
- Quality Control (Update, Application, and Pre-Release Testing)
- Quality Assurance (Verification of Changes, Policy Compliance Review)
- Product Improvement (Development)
Getting Involved
The main entry points for working on QA tasks are the BugSquad and Testing Team, however feel free to drop by #ubuntu-quality, if you are interested in Ubuntu QA.
Because Ubuntu QA is a coordination/development/working team the membership guidelines are:
- Individuals, not teams may be members.
- Memberships expire annually and can be renewed by members themselves.
- People from all areas of QA are encouraged to join.
Requirements to join the team:
- established record of contributing to QA in Ubuntu (such as BugSquad or Testing Team)
- be an Ubuntu Member or ready to become one (i.e. significant and sustained contribution to Ubuntu)
- an introductory email sent to the ubuntu-qa list introducing yourself, your previous QA work, and your plans for working in the team.
What kinds of things does Ubuntu QA do?
- Coordinate between the various QA-related teams
- Build communities around QA work and help them run smoothly
- Provide lead-from-the-front leadership to Ubuntu’s QA projects
- Assess and communicate Ubuntu’s QA needs
- Develop tools and services needed in Ubuntu QA work
- Work on creating consistent and efficient QA-related policies
- whatever else comes up or people want to contribute
Huge props go to Emmet Hikory, Steve Beattie, Henrik Omma, and the rest of the team for helping this get launched.
So stay tuned for more exciting QA developments, feel free to contribute, and rock on!
Daniel landed some highly demanded iTIP/iMIP features today, and we want to put email-based scheduling (iTIP/iMIP support) to the acid test on our testday, tomorrow, Thursday, July 17th.
The landed patch allows the user to select an Email Identity for a calendar, which in turn is useful for accepting invitations so that the application can determine which identity to use when sending a reply. Also, calendar providers were given more control of how invitations are handled.
Join us in the #calendar-qa IRC channel tomorrow. All the information on the testday is on our usual Test Day wiki page.
Hope to see you in #calendar-qa!
mschroeder
Calendar QA Team
Our next test day will be held on Thursday, July 17th, and we need your help to find regressions and bugs!
I want to give you a short description how a test day proceeds:
We usually try a mix of Litmus and ad-hoc testing. Ad-hoc testing is testing where we attempt to use the product like a 'normal user' to find any issues that crop up along the way. We also try to make the application break by doing unexpected things - mixing up events, mails, tasks, calendar types etc. This is also called 'destructive testing'. After you have discovered a bug, you should take a look at the Error Console in the Tools menu before submitting a bug report, since it usually contains valuable information that points to the cause of the bug.
We also verify fixed bugs. In this case, we just add a comment to the bug report stating our used product, version and operating system.
Please, join us in #calendar-qa on Thursday. You can find all information on the test day on our Test Day wiki page.
Happy Testing!
Andreas
Calendar QA Team