Meego Wiki
From MeeGo wiki
< SDK
Revision as of 17:10, 21 March 2011 by Arcadie (Talk | contribs)
Jump to: navigation, search

Contents

MeeGo SDK QA Team

The MeeGo SDK QA Team is responsible of MeeGo platform SDK Quality. QA members focus on different components, host and target platforms, but we maintain all the test cases in the same testlink website, file bugs to MeeGo bugzilla SDK project, post testing report to MeeGo quality WiKi page. The synchronization among QA members is ensured by weekly SDK QA meeting, IRC and mail.

Team

  • Jaya Uppalapati -- QA leader, focus on Nokia legacy components, ARM based platform and features
  • Juha Peisanen -- QA owner, focus on Nokia legacy components, ARM based platform and features
  • Arcadie Prepelita -- QA owner, focus on X86 based platform and features
  • Daniel Mihai -- QA leader focus on X86 based platform and features

Process

Bug Triage

For bug triage process of MeeGo, please refer to Quality/Bugtriage. SDK team members should register bug triage mailing list: meego-bug-triage@linux.intel.com. Register @ http://linux.intel.com/mailman/listinfo/meego-bug-triage.

Teams for bug triage:

  • Bug triage team: Juha Peisanen (Nokia) Daniel Mihai (Intel), Fathi Boudra(Nokia), Jackie Wu(Intel), Max Yu (Intel)
  • Bug management team: Veli Kaksonen (Nokia), Bob Spencer(Intel), Kerry Jiang (Intel), Arcadie Prepelita(Intel)

Bug triage process:

  • Bug triage team review all the new bugs for the priority, severity, assignee and description every week.
  • After review, bug triage team send out the review request to "bug triage mailing list" every Monday and request management team provide feedback on bugs
  • Management team review the bugs in 1 business day and decide if accept these new bugs. Bug owners should accept the bugs for her/him in 1 business day. Anyone in triage mailing list can speak out with your opinion for any bug. If a bug is accepted, the bug status should be changed to "ASSIGNED" and right "target build" is set by bug owner.
  • If there are controversial bugs, Management Team should drive to go through them in next sync meeting and make decision in the meeting.

Bugzilla workflow

The default assignee of a newly introduced bug must set the bug to ASSIGNED in 1 business day if she/he is not on leave. In case he is not the one to solve the bug, he must pass the bug to another person leaving the status unchanged in 1 business day if she/he is not on leave.

Developer needs to set bug to ASSIGNED even if he won't start working at the bug right away. The ASSIGNED state is just an indication that the bug has reached the person/persons that should take care and fix it; bugs should have a short life in the NEW state. In case a bug remains in NEW state for longer than 1 week, QA must take action to search and notice the right persons; maybe the bug was misplaced? The recommended way of asking for describing anything that is related with the bug is by commenting in bugzilla rather than email or chat; this way other people can see all information related to the problem in one place

One unwanted situation is when bugs are in NEW and nobody has ever commented on it for a long time. Feedback is important to the QA, even for INVALID or DUPLICATE bugs in order to improve the QA process for the future and to help any other viewer that might run into the same bug later. Another situation to be avoided is when developer works on fixing bugs based on his own preferences, for instance avoid writing for bugs for documentation. This will contribute to an overall reduced quality process.

Once the release is about to take place the QA should release an acceptance document enlisting the last versions of the builds tested, overall status of the product (GREEN/YELLOW/RED) and some of the major bugs. RED should mean that the build is not ready for release from QA POV.

Test Plan

You can find uniform MeeGo SDK test plan @ SDK Test Plan

Test Report

Meeting

Meeting Minutes

Retrieved from "http://wiki.meego.com/SDK/QA"
Personal tools