(→Things we need on this page) |
Ionutgavaz (Talk | contribs) (→Team) |
||
| (42 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | + | 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 [[Quality|MeeGo quality WiKi page]]. The synchronization among QA members is ensured by weekly SDK QA meeting, IRC and mail. | |
| - | + | ||
| - | The MeeGo SDK QA Team is responsible of MeeGo platform SDK Quality. | + | |
== Team == | == Team == | ||
| - | * Jaya Uppalapati | + | * Jaya Uppalapati -- QA leader, focus on Nokia legacy components, ARM based platform and features |
| - | * | + | * Edmondas Girkantas -- QA owner, focus on Nokia legacy components, ARM based platform and features |
| - | * | + | * Ionut Gavaz -- QA owner, 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: Edmondas Girkantas(Nokia), Ionut Gavaz (Intel), Jackie Wu(Intel), Max Yu (Intel) | ||
| + | * Bug management team: Veli Kaksonen (Nokia), Bob Spencer(Intel), Kerry Jiang (Intel), Ionut Gavaz(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 @ [[SDKTestPlan|SDK Test Plan]] | ||
| + | |||
| + | == Test Report == | ||
| + | *[http://qa-reports.meego.com/ MeeGo SDK Test Reports] | ||
== Meeting == | == Meeting == | ||
| - | * When: Every Tuesday at | + | * When: Every Tuesday at 11:00~12:00 (UTC+2). |
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe | * Sharing point during the meeting: http://piratepad.net/MXIM107LUe | ||
| + | |||
=== Meeting Minutes === | === Meeting Minutes === | ||
| - | *[[ | + | *[[SDK/QA/MeetingMinutes/20110426|20110426 Meeting Minutes]] |
| + | *[[SDK/QA/MeetingMinutes/20110412|20110412 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20110329|20110329 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20110322|20110322 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20110315|20110315 Meeting Minutes]] | ||
| + | * 20110308 Meeting Cancelled due to vacations | ||
| + | *[[SDK/QA/MeetingMinutes/20110301|20110301 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20101109|20101109 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20101102|20101102 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20101026|20101026 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20101019|20101019 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20101012|20101012 Meeting Minutes]] | ||
| + | * 20101005 Meeting Cancelled due to vacations | ||
| + | *[[SDK/QA/MeetingMinutes/20100928|20100928 Meeting Minutes]] | ||
| + | *[[SDK/QA/MeetingMinutes/20100921|20100921 Meeting Minutes]] | ||
| + | |||
| + | [[Category:SDK]] | ||
| + | [[Category:QA]] | ||
| + | [[Category:SDK]] | ||
| + | [[Category:QA]] | ||
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.
Contents |
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 process:
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.
You can find uniform MeeGo SDK test plan @ SDK Test Plan