MeeGo wiki - User contributions [en]

SDK/QA

2011-08-23T07:43:51Z

Ionutgavaz: /* 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 [[Quality|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
* 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 ==
* When: Every Tuesday at 11:00~12:00 (UTC+2).
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe

=== 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]]

SDK/QA

2011-08-23T07:42:54Z

Ionutgavaz: /* Bug Triage */

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.

== 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
* Ionut Gavaz -- 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: 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 ==
* When: Every Tuesday at 11:00~12:00 (UTC+2).
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe

=== 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]]

Quality/Bugtriage

2011-08-23T07:41:21Z

Ionutgavaz: /* MeeGo Bug Triage Meetings */

== Bug Triage Definition ==
* Bug Triage is a process to:
** Ensure bug report completeness
** Analyze and move bug to proper component if needed
** Set Assignee of bug report (via "Assigned to" field) to proper bug owner
** Assign bug to packages listed in "MeeGo Distribution Packages" product whenever possible (apply for new incoming bug reports for version 1.3 ONLY at this moment)
** Set appropriate bug priority
** Adjust bug severity properly (initially set by bug reporter)
** Resolve obvious invalid, duplication, won’t fix bugs etc.
** Forward bugs in upstream components to [[Quality/UpstreamBugTrackers | upstream bugtrackers]] and adding the upstream URL to the URL field of the report, if applicable

* Bug Triage Team
** A small team works on bug triage, could be experienced developer, distro engineer or QA
** Triage team members are expected to contribute significant time to bug triage

Please share your triaging knowledge by adding/editing [[Quality/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]].

== Bug Triage Process ==
* Triage new incoming bug reports timely by each triage team (from twice a week to daily triage).
* Triage team members in each triage team could have different focus, such as IA arch bugs, ARM bugs or specific applications etc.
* Each triage team meet on IRC weekly to discuss controversial bug reports and any open reports
* Bug assignees accept bug reports by setting target milestones for triaged bug reports
* [http://meego.com/about/governance/program-office Program Managers] host bug report scrub meetings to discuss bug reports which do not have a target milestone set

Triage Process Flow as follows:

[[File:bug_triage_2.PNG]]

== MeeGo Bug Triage Guide ==
Check the [[Quality/Bugtriage_Guide|Triage Guide]] that explains good practices when triaging bug reports.

== MeeGo Bug Triage Team ==
{|cellspacing="0" border="1"
!|MeeGo Bug Triage Team
!|Member
|-
| MeeGo Core OS Triage || [http://meego.com/users/shuangeeer Yanshuang Zheng], [http://meego.com/users/ares2012 Jason Zhou], [http://meego.com/users/jarnoteivas Jarno Teivas], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Handset UX Triage || [http://meego.com/users/fan Fan Zhao], Cathy Li, [http://meego.com/users/srikanthyarlagadda Srikanth Yarlagadda], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Netbook UX Triage || Daniel Tao,[http://meego.com/users/rossburton Ross Burton]
|-
| MeeGo Tablet UX Triage || Daniel Tao, [http://meego.com/users/yanglei Lei Yang], Cathy Li
|-
| MeeGo IVI Triage || [http://meego.com/users/shuangeeer Yanshuang Zheng]
|-
| MeeGo Translation Triage || [http://meego.com/users/margie Margie Foster], [http://meego.com/users/pmccarty Patrick McCarty]
|-
| MeeGo SDK Triage || [http://meego.com/users/ionutgavaz Ionut Gavaz], Jackie Wu, [http://meego.com/users/edmondas Edmondas Girkantas], Azadeh Karimian, Max Yu, Juha Peisanen
|-
| MCTS (MeeGo Core System Testing) Triage || Jeff Zheng,[http://meego.com/users/iekku Iekku Huttunen]
|}

=== MeeGo Bug Triage Meetings ===

* MeeGo Core Bug Triage
** Time: Every Monday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Handset Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Netbook Bug Triage
** Time: Every Tuesday at 13:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo IVI Bug Triage
** Time: TBD
* MeeGo Translation Bug Triage
** Time: TBD
* MeeGo SDK Bug Triage
** Time: On demand on Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MCTS Bug Triage
** Time: Every Wednesday at 08:00 [http://www.timeanddate.com/worldclock/converter.html UTC]

Those meetings take place in the IRC channel'''#meego-meeting''' on [http://freenode.net irc.freenode.net].

* MeeGo Tablet Bug Triage
** Time: Every Thursday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
** IRC channel '''#meego-meeting2''' on [http://freenode.net irc.freenode.net]

To discuss MeeGo bug triaging at any time feel free to visit the IRC channel '''#meego-bugs''' on [http://freenode.net irc.freenode.net].

* [[CoreBugTriageMinutesArchive|MeeGo Core Bug Triage Meeting Minutes Archive]]
* [[HandsetBugTriageMinutesArchive|MeeGo Handset Bug Triage Meeting Minutes Archive]]
* [[NetbookBugTriageMinutesArchive|MeeGo Netbook Bug Triage Meeting Minutes Archive]]
* [[SDKBugTriageMinutesArchive|MeeGo SDK Bug Triage Meeting Minutes Archive]]

=== Getting involved ===

Anyone can sign up for the triage team and start helping (see the [[Quality/Bugtriage_Guide|Triage Guide]] for information and steps). Just send an email to the [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list] to get involved in. Thanks for your contribution to MeeGo!

== Other references ==
*[[Quality/How_To_Report_Bugs|How to report MeeGo bugs?]]
*[[Quality/Triageteam_Assignee|How to deal with bugs assigned to triageteam@meego.bugs]]
*[[Category:QA]]

MeeGo-Meeting IRC Schedule

2011-08-23T07:39:20Z

Ionutgavaz: /* Regular Meetings */

To avoid meeting conflicts in [http://meego.com/community/irc-channel #meego-meeting], please add your meeting here with date and UTC time until we have a more robust solution. You might also want to review our [[IRC guidelines]] for the MeeGo project.

We have two meeting rooms:

[http://meego.com/community/irc-channel #meego-meeting], also called Meeting Room 1

[http://meego.com/community/irc-channel #meego-meeting2], also called Meeting Room 2

== Regular Meetings ==

'''Monday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0px 1px 0"| Channel
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 7:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings|MeeGo Core Bug Triage Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0px 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 8:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[ARM/N900/Performance#Team_meeting_minutes|MeeGo CE UX & Performance team meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0px 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 0px 0"| 15:00
|style="border-style: solid; border-width: 0 1px 0px 0"| [[Local_MeeGo_Networks/MeeGo_Network_Finland#Online_Community_Meetings | MeeGo Network Finland Community Meetings]]
|style="border-style: solid; border-width: 0 1px 0px 0"| Monthly meeting every 1st Monday
|style="border-style: solid; border-width: 0 0px 0px 0"| #meego-meeting
|}

'''Tuesday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0 1px 0"| Channel
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Meetings| QA Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 08:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/QA-tools/Meetings| QA-Tools Meeting]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting2
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 08:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[SDK/Meetings/Release| SDK Meeting (Release)]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 11:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[ARM/N900/DeveloperEdition/Meetings| Community Edition Team Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 13:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MeeGo Netbook Bug Triage Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 14:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Community_Office/Meetings| Community Office Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Bi-Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 15:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Project/Dialer/Meetings| Dialer Project Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 17:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Events/Meetings|Events Meeting]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Bi-Weekly *
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 0 0"| 19:00
|style="border-style: solid; border-width: 0 1px 0 0"| [[Local_MeeGo_Networks/MeeGo_Network_France/Meetings|Meego Network France Community Meeting]]
|style="border-style: solid; border-width: 0 1px 0 0"| Monthly meeting every 1st Tuesday
|style="border-style: solid; border-width: 0"| #meego-meeting
|}

<nowiki>*</nowiki> Every other week.

'''Wednesday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0 1px 0"| Channel
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 05:30
|style="border-style: solid; border-width: 0 1px 1px 0"| [[SDK/Meetings| SDK Meeting]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MeeGo Handset Bug Triage Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MeeGo SDK Bug Triage Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| On demand
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting2
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 08:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MCTS Bug Triage Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 15:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[LocalizationMeetings| Localization / L10n Meetings]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Monthly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|}

'''Thursday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0 1px 0"| Channel
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 06:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Technical_Steering_Group_meetings| Technical Steering Group Meeting]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Bi-Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MeeGo Tablet 1.2 Critical bug tracking]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting2
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[Quality/Bugtriage#MeeGo_Bug_Triage_Meetings| MeeGo N900 CE 1.2 Critical bug tracking]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting
|-
|style="border-style: solid; border-width: 0 1px 0 0"| 08:00
|style="border-style: solid; border-width: 0 1px 0 0"| [[ARM/N900/Meetings| Community Edition Adaptation Meetings]]
|style="border-style: solid; border-width: 0 1px 0 0"| Weekly
|style="border-style: solid; border-width: 0"| #meego-meeting
|}

'''Friday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0 1px 0"| Channel
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 07:00
|style="border-style: solid; border-width: 0 1px 1px 0"| Scrub meeting for bugs assigned to triageteam@meego.bugs
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0 0 1px 0"| #meego-meeting2
|-
|style="border-style: solid; border-width: 0 1px 1px 0"| 14:00
|style="border-style: solid; border-width: 0 1px 1px 0"| [[MeeGo_Apps | MeeGo Apps meeting ]]
|style="border-style: solid; border-width: 0 1px 1px 0"| Weekly
|style="border-style: solid; border-width: 0"| #meego-meeting
|}

'''Sunday'''
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0"
|-
!style="border-style: solid; border-width: 0 1px 1px 0"| Time (UTC)
!style="border-style: solid; border-width: 0 1px 1px 0"| Meeting
!style="border-style: solid; border-width: 0 1px 1px 0"| Interval
!style="border-style: solid; border-width: 0 0 1px 0"| Channel
|-}

== Ad Hoc Meetings ==

Scheduling a one-time meeting? Add it to this section.

* [[MeeGo Apps|MeeGo Apps]] meeting: Friday, 17th of June 2011 at 14:00 UTC

=== Guidelines ===

Please refer to the [[IRC guidelines]] for more details about how to run a MeeGo IRC meeting and using #meego-meeting.

You might also be interested in these [[IRC Presentation Tips]].

SDKBugTriageMinutesArchive

2011-07-20T07:56:43Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-07-20-05.55.html MeeGo SDK Bug Triage 20110720]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-07-06-05.57.html MeeGo SDK Bug Triage 20110706]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-29-06.00.html MeeGo SDK Bug Triage 20110629]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-22-05.57.html MeeGo SDK Bug Triage 20110622]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-15-05.58.html MeeGo SDK Bug Triage 20110615]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-08-05.57.html MeeGo SDK Bug Triage 20110608]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-25-05.58.html MeeGo SDK Bug Triage 20110525]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-18-05.58.html MeeGo SDK Bug Triage 20110518]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-11-05.58.html MeeGo SDK Bug Triage 20110511]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

SDKBugTriageMinutesArchive

2011-07-06T06:49:26Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-07-06-05.57.html MeeGo SDK Bug Triage 20110706]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-29-06.00.html MeeGo SDK Bug Triage 20110629]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-22-05.57.html MeeGo SDK Bug Triage 20110622]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-15-05.58.html MeeGo SDK Bug Triage 20110615]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-06-08-05.57.html MeeGo SDK Bug Triage 20110608]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-25-05.58.html MeeGo SDK Bug Triage 20110525]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-18-05.58.html MeeGo SDK Bug Triage 20110518]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-11-05.58.html MeeGo SDK Bug Triage 20110511]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

Quality/Meetings/QA leads update 1.2

2011-07-04T14:26:19Z

Ionutgavaz: /* SDK Update */

=== Core Update ===
28.06.2011
* Link to latest daily testing results: http://qa-reports.meego.com/1.2/Core/Acceptance/
* For Ecs S10Ot3, the latest run rate is 78%, pass rate of total is 73%, pass rate of executed is 93%.
**''improvement:''
**System default volume is normal, fixed bug 19274
**Recorded video playback successfully, fixed bug 19279
**No noise sounds heard when playing, fixed bug 17852
** ''Key Issues:''
**17932 - Call Trace Found:possible recursive locking detected
**18815 - show_acceleration test hangs there
21.06.2011
* Link to latest daily testing results: http://qa-reports.meego.com/1.2/Core/Acceptance/
* For Ecs S10Ot3, the latest run rate is 87%, pass rate of total is 63%, pass rate of executed is 72%.
** ''Key Issues:''
**15948 - Fail to run ut_qtcontacts_trackerplugin
**17852 - noisy sound heard with music when playing
**17932 - Call Trace Found:possible recursive locking detected
**System is default to mute on ECS S10OT3(19274)
**Recorded video playback failed(19279)
**show_acceleration test hangs there(18815)
7.06.2011
* Link to latest daily testing results: http://qa-reports.meego.com/1.2/Core/Acceptance/
* For Ecs S10ot3, the latest run rate is 87%, pass rate of total is 65%, pass rate of executed is 75%.
** ''Key Issues:''
**15948 - Fail to run ut_qtcontacts_trackerplugin
**17852 - noisy sound heard with music when playing
**17932 - Call Trace Found:possible recursive locking detected
* QA conduct 1.3 daily validation on Netbook, the latest run rate is 78%, pass rate of total is 65%, pass rate of executed is 84%.
** ''Key Issues:''
**17838 - [Trunk:Testing][REG] No help information print out when execute powertop -h o powertop --help
**13537 - A black screen displayed when running OpenGL-Blit case
**17835 - [Trunk:Testing][REG]Fail to run ut_qtcontacts_trackerplugin
**18161 - [Trunk:Testing]Fail to scan WIFI AP list on Networks panel

31.05.2011
* Link to latest daily testing results: http://qa-reports.meego.com/1.2/Core/Acceptance/
* QA kicked off 1.3 daily validation on Netbook, the latest run rate is 78%, pass rate of total is 65%, pass rate of executed is 84%.
* MeeGo 1.2.80 image can be installed and live boot, bug(17737) has been fixed
** ''Key Issues:''
**17838 - [Trunk:Testing][REG] No help information print out when execute powertop -h o powertop --help
**13537 - A black screen displayed when running OpenGL-Blit case
**17835 - [Trunk:Testing][REG]Fail to run ut_qtcontacts_trackerplugin

10.05.2011
* Link to latest daily testing results: http://qa-reports.meego.com/1.2/Core/Acceptance/
Latest Acceptance iCDK:RR 95% PR:75; Netbook:RR:78% PR:68;IVI testing blocked by #17001
*Some regression issues were found in this week.
**17001 - [IVI][REG] missing meego-ux-ivi packages in ivi images（fixed in T:T）
**17065 - [REG]Error initializing garage client services library
**17248 - [IVI][REG][1.2:Testing] tear screen showed when unlocked the screen

27.06.2011
*1.3 Status:
** 1.3 testing discontinued wk24 onwards by the guidance of top management.
* 1.2 Status:
** 1.2.1 testing continues with minimal support.
** Acceptance results: http://qa-reports.meego.com/1.2/Core/Acceptance/N900/2992
** Sanity results: http://qa-reports.meego.com/1.2/Core/Sanity/N900/3005
* Biggest issues:
**12423- [n900] A partially Image displays when execute "qt_painting_basic" case. (FIXED)

*CE testing(DE is nowadays CE as community edition):
** CE Summer release wk25 tested: http://qa-reports.meego.com/1.2/Core/Key%20Feature/N900ce/2995
** RR 90%, PR 66%
* Biggest issues
**Package manager broken (architecture issues).
**Sensor test broken
**bluetooth has problems
**mobility messaging doesn't work
* CE summer release fix build will be expected wk26.

=== Handset Update ===
27.06.2011
* Meego 1.3 testing discontinued from wk24 onwards.
* Minimum support to 1.2.1. Mainly acceptance and sanity.
* Latest results: http://qa-reports.meego.com/1.2/Handset
* CE Status:
**Dataflow results for summer release: http://qa-reports.meego.com/1.2/Handset/Dataflow/N900ce/3011
**RR 100%, PR 85%
**Key issues:
***19815- [CE]Call UI is not launched while making outgoing call from Device (NEW)
***17751- [CE] Unable to make conference call (ASSIGNED)
***18298- [CE] Battery indicator doesn't show battery state accurately. (FIXED)
***16458- [CE] Settings application crashes at wallpaper first launch. (REOPENED)
***19492- [CE] Cannot turn bluetooth off after enabling it. (REOPENED)
***16834- [CE] Settings crash when rotating Wallpaper (ASSIGNED)
** Fix release expected during wk26.

=== Tablet Update ===
2011.06.28
* Weekly
** QA complete key feature testing for Pinetrail and Oaktrail platform
** Oaktrail:
*** Pass rate is 80%;
*** Improvement
**** meego-ux-panels: fixed three bugs,BMC#16503 - Friends panel: Fail to get Friends updates after toggle on/off button, BMC#18465 - Friends panel: Recent IM updates fail to show on friends panel and BMC#18452 - Photos panel: Album with photos shows empty thumbnail on photos panel
**** Email:fixed a bug BMC#16538 - email ~ message saved in draft folder is not editable/resumable.
**** Music App:fixed 2 bugs, BMC#15337 - First time use Playlists should show dummy text instructions and BMC#17674 - [REG]Currently-viewed selection isn't highlighted, need developer update bugs status.
**** IM:fixed a bug BMC#19260 - [Reg]Unable search by Contact name via IM app
**** Camera: fixed a bug BMC#19257 - [REG]Camera fails to record video
*** Lowlight
**** Exit running applications from task switcher needs more time than before
**** IM: BMC#18412 - [REG]No call request message popped up when receiving a call request
**** Settings-contacts: BMC#19805 - UI overlapping in "all settings"->"application"->"contacts"
**** Alarm: BMC#15235 - Alarm does not activate in Alarms
**** Contacts: BMC#19721 - it fails to Edit/View contacts including phone number by context menu
**** Input method: BMC#19736 - VKB hard to get focus in "note" and "all settings"
**** Input method: Gesture no response or not smoothly sometimes.
** Pinetrail:
*** Pass rate is 78%;
*** Improvement
**** Music: Currently-viewed selection is highlighted, BMC#17674 is fixed
**** Music: First time use Playlists can show dummy text instructions, BMC#15337 is fixed
**** meego-ux-panels: meego-ux-panel can work , three bugs has be fixed.( BMC#16503 - friends panel updates fine after toggle on/off button , BMC#18465 - recent IM updates shows fine on friends panel and BMC# 18452 - album with photos shows thumbnail.)
**** meego-ux-deamon: closing music app from task switcher works fine ,BMC#18763 is fixed
**** Email: email ~ message saved in draft folder is editable/resumable, BMC#16538 is fixed
**** IM: search by Contact name via IM app can work , BMC#19260 is fixed
*** Lowlight
**** Setting: file a BMC#19805 - UI overlapping in "all settings"->"application"->"contacts"
**** Sync: file a BMC# 19434 - [Trunk: Testing 1.2]Google contacts sync is missing in Sync.
**** IM Settings: BMC#20068 - Unable to delete IM account due to UI incorrect position, BMC#19848 - clear history button fail to work on web panel
**** Gesture no response or not smoothly sometimes
**** VKB difficult to input/dismiss
**** IM: BMC#18412 - [REG]No call request message popped up when receiving a call request, BMC#19628 - Visiting contact will cause application crash, BMC#19640 - Favorite contact filter does not function
**** Browser: Forward button is invalid when click it and It could not go back to the webpage after entering Bookmarks/Downloads. Sometimes it will crash suddenly.

=== Netbook Update ===
2011.06.28
* MeeGo 1.0 SW Update: QA Complete one round of system functional testing for 1.0 SW Update 9. Test pass ratio: 92.39%, whole image quality is a little downgraded (93.66% ->92.39%) compared with Update Release 8. Bug 13735 has been fixed. One regression issue is found: Fail to login MSN by IM client (19734)
* MeeGo 1.1 SW Update: QA Complete one round of sanity testing for 1.1 SW Update 6, pass ratio is 96%. Compared with 0513's update, pass ratio keeps stable, In latest repo, no new regression issue was found by QA.
* MeeGo 1.2.0 SW Update: No update available now;
* MeeGo 1.3:
** Daily testing: in 0624 image, UX sanity pass rate is 82%, Core sanity pass rate is 68%;
** Weekly system functional testing: in 0621 image, system functional pass rate is 86.59%;
** Key issue:
*** Flash plug-in is missed(17834);
*** Fail to login MSN by IM client(18445);
*** [REG]Language setting is missing in settings(18536);
*** The UI of Set Time & Date is missing(18397);
*** Blank gnome-control-center panel opened when click “login me in ” button of Facebook(18482);

=== IVI Update ===
21.06.2011
* For IVI, update for 1.2.0 will branch from 1.2.1, with limited bug fixing, but not all changes in 1.2.1.
* QA will focus on 1.2.0 update till end of Jun, and defer QA effort on 1.3 images before 1.2.0.1 update
* For 1.2.0 Update, QA's test strategy:
** When there is bug fixed today, do sanity test on all 3 target platforms(by day)
** When there is bug fixed this week, do full functional tests against changes on CrossvilleOKI(by week)
* All Update Blockers have been cloned to version 1.2.0.
* with #18918([IVI] EMGD-bin: meego-ux-daemon crashes QT at various times (lock screen, task switcher, when idle)) fixed, there are 3 regression brought in:
** 19386 - [IVI][REG] Lock screen not rendered on top of IVI desktop with emgd-bin-2001-4
** 19377 - [IVI][REG] App switcher show black frame for launched app icons with emgd-2001
** 19087 - [IVI] X init failed if emgd update to 2001-4
* ''Top issues''
*** [major] 17467 - IVI/Crossville-OKI: touchscreen NOT function
*** [major] 17502 - [IVI] boot time is too long ~35 second
*** [major] 16929 - IVI/Russellville: hang when switch from command line to X
*** [major] 17177 - [IVI]tear/black screen showed sometimes on LVDS'13
*** [major] 18707 - IVI: meego-ux-daemon crashes QT when screen is locked with EMGD
*** [major] 16760 - Russellville: /dev/radio0 not found
*** [major] 17135 - CrossvilleOKI: ioh_video_in initialize failed
*** [major] 16876 - [IVI] RV: GUI Installer takes a long time to launch

=== SDK Update ===

05.06.2011

IA-target:
These are the activities we were involved last week:
* Bug verification
* Finished the MeeGo API testing harness
* Tried TestKit on Fedora 14 - there are still a few glitches with the tool on which we are working
* VMM test cases for Mac and Windows OS were finished and sent for internal review

10.05.2011

ARM -target:
* Test results for SDK : http://qa-reports.meego.com/1.2/SDK
* Latest results from week 18 using armv7hl handset sysroot [[http://repo.meego.com/MeeGo/builds/1.1.99/1.1.99.5.20110503.6/images/meego-handset-armv7hl-madde-sysroot/ 1.1.99.6.20110503.6]] and N900DE image.
** 17201 - libcloog package is missing
** 12853 - libattica is not installed with QtCreator
** 13171 - Qt-creator OBS plugin gives network error
** 14910 - Application launch on device is success but screen is distorded

=== QA-tools Update ===

2011.06.13
* OTS version 0.8.6 released
** http://lists.meego.com/pipermail/meego-qa/2011-June/001839.html
* Testplanner version 0.4.2 released
** http://lists.meego.com/pipermail/meego-qa/2011-June/001847.html
* Testrunner-ui version 0.4.7 released
** http://lists.meego.com/pipermail/meego-qa/2011-June/001848.html
* Some other minor updates to tools as meego-ai-flasher, etc.

2011.06.07
* testrunner-lite 1.7.0 released (closes 11 bugs)
* corelysis (the core processing backend) packaged and available from Tools:Testing
* [https://gitorious.org/meego-developer-edition-for-n900/mg-package-manager package manager] for the n900 DE released
2011.05.30
* OTS version 0.8.5 released
* corelysis open sourced
** Core dump processing component
* Core processing plugin for OTS
** Included in OTS 0.8.5 release
* Min test framework version 2011w20 released
* test-definition version 1.3.2 released
* Development focusing on improving test automation tool chain (OTS, testrunner-lite, etc.) and enabling automated core dump processing with OTS test runs.

Quality/Plans/VMM test plan

2011-06-16T11:49:17Z

Ionutgavaz: /* Coverage */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

Basic functionality testing will be conducted in parallel on Mac OS and Windows XP, 60% of time allocated to Mac OS and 40% to Windows XP. The allocation is dependent on the presence of any blocking issue on one of the operating systems.
The same logic will apply for performance, stress and load testing - the Mac OS tests take precedence over the Windows ones.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing
#random testing&exploratory testing

=== Configurations ===

VMM will tested in a number of standard Intel computer configurations that include Mac OS(64bit),Windows XP(32 bit) and Windows 7(64bit).

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite, AppTimer. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:48:34Z

Ionutgavaz: /* Introduction */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

Basic functionality testing will be conducted in parallel on Mac OS and Windows XP, 60% of time allocated to Mac OS and 40% to Windows XP. The allocation is dependent on the presence of any blocking issue on one of the operating systems.
The same logic will apply for performance, stress and load testing - the Mac OS tests take precedence over the Windows ones.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of standard Intel computer configurations that include Mac OS(64bit),Windows XP(32 bit) and Windows 7(64bit).

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite, AppTimer. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:26:32Z

Ionutgavaz: /* Test Tools */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

Basic functionality testing will be conducted in parallel on Mac OS and Windows XP, 60% of time allocated to Mac OS and 40% to Windows XP. The allocation is dependent on the presence of any blocking issue on one of the operating systems.
The same logic will apply for performance, stress and load testing - the Mac OS tests take precedence over the Windows ones.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of standard Intel computer configurations that include Mac OS(64bit),Windows XP(32 bit) and Windows 7(64bit).

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite, AppTimer. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:22:33Z

Ionutgavaz: /* Configurations */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

Basic functionality testing will be conducted in parallel on Mac OS and Windows XP, 60% of time allocated to Mac OS and 40% to Windows XP. The allocation is dependent on the presence of any blocking issue on one of the operating systems.
The same logic will apply for performance, stress and load testing - the Mac OS tests take precedence over the Windows ones.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of standard Intel computer configurations that include Mac OS(64bit),Windows XP(32 bit) and Windows 7(64bit).

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:17:27Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

Basic functionality testing will be conducted in parallel on Mac OS and Windows XP, 60% of time allocated to Mac OS and 40% to Windows XP. The allocation is dependent on the presence of any blocking issue on one of the operating systems.
The same logic will apply for performance, stress and load testing - the Mac OS tests take precedence over the Windows ones.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:11:21Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

In the first stage of testing we will cover basic functionality scenarios. Once we make sure the VMM module is stable we'll shift the focus on performance testing/benchmarking.
Long hour/load and stress testing will be executed after the performance testing.
The negative scenarios will the last ones executed.

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:08:22Z

Ionutgavaz: /* Coverage */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hour tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:08:05Z

Ionutgavaz: /* Coverage */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

=== Coverage ===

#functionality testing
#stress testing
#long duration/load testing (24 to 72 hours tests)
#performance testing
#negative testing

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:05:01Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus on functionality and performance
*P2: Nice to have for coming release
*TBD: not covered in coming release

=== Coverage ===

At this stage we are aiming towards feature and functionality coverage.

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:03:51Z

Ionutgavaz: /* Test Host & Target */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release

=== Coverage ===

At this stage we are aiming towards feature and functionality coverage.

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T11:03:11Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|VMM
|-
|Mac OS || P1
|-
|Windows XP || P2
|-
|Windows 7 || TBD
|-
|}

*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release

=== Coverage ===

At this stage we are aiming towards feature and functionality coverage.

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T10:57:35Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

1.coverage on Mac host
2.coverage on Windows XP
3.coverage on Windows 7

=== Coverage ===

At this stage we are aiming towards feature and functionality coverage.

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

Quality/Plans/VMM test plan

2011-06-16T10:56:50Z

Ionutgavaz: /* Priorization */

Proposal - please contribute by editing this page or posting your comments on [[Talk:TestPlanTemplate|discussion area]] for this page.

Note that this is template giving the frame from actual test plan.
The intent is to list areas/things which one need to consider when planning needed QA activities for certain MeeGo Release (e.g. 1.2, 1.3).

== Introduction ==

=== Purpose ===

The purpose of the Test Plan is to define a strategy, scope and testing activities done or supported by SDK QA team for MeeGo 1.3 release involving the HW-accelerated MeeGo Emulator for Mac & Windows host, that is developed and maintained by Intel.
This plan describes the QA approach of testing the VMM module.

=== Objectives ===

Objectives in VMM QA test plan is to validate the functionality and stability of VMM module running on diffrent host OS'es. The OS'es that we are focusing on are Mac OS and Windows. The target is to ensure that:

* We perform the basic tests on QEMU from testlink to ensure that the image running is stable and is not affected by the new module.
* VMM module is stable under the host OS
** Stress testing will be done (eg. running more applications in parallel) in QEMU and also in the Host to observe the stability of the VMM module during the test.
** Perform load testing and observe the CPU/memory usage of the VMM in various conditions and after a long period of time (eg. run a movie in QEMU and see how the module is behaving)
** Negative testing (eg. Restart the VMM service when QEMU is running).
** For every test the VMM module will be monitored for it's CPU load, memory usage in diffrent cases (when QEMU is idle, started or stopped)
* Performance testing will be done to compare the performance of MeeGo images between various hosts. This will be done by using benchmark tools.

=== Goal ===

The goal is to deliver a product with no open bugs with a severity level of critical and a minimal number of open bugs with severity level major.

=== Document Overview ===

==== Test Cases ====

During the the release phase aiming to final release, test cases will be executed. Test cases should be run from Test link and they should cover the main Objectives described above. Each test case also contains test specific criteria which decide upon test case success or failure.

==== Test Case Result ====

Verdict shall be assigned for a test case after execution according [[Quality/Glossary#Test_case_verdict|test case verdict instructions]].

==== Traceability of Features ====

For each feature listed in bugs.meego.com, in principle, one or more test cases should exist. This information should be defined in the test case according instructions given in [[Quality/Test_case_template|Test Case Template]]

==== Test Case Documentation ====

Each test case described in the detailed test plan contains the fields according [[Quality/Test_case_template|Test Case Template]] and [http://meego.gitorious.org/meego-quality-assurance/test-definition test-definition]

== Overall test strategy ==

=== Introduction ===

The overall objective of VMM QA is to ensure the stability and performance of the VMM module that will be used in Windows and Mac OS hosts. For example the image under QEMU is not affected by the VMM module, the Host is stable when VMM service is running and so on. Different test types will be done, including:

* Stress testing
* Load testing
* Negative testing
* Random testing

Tests will be ran on QEMU to ensure that it's components were not affected by the VMM. The tests performed will be the basic tests that are performed on a QEMU weekly image. They should cover the overall behavior of the QEMU.
After ensuring that basic tests are passed, the VMM module will be tested and monitored by checking it's stability under various conditions (eg. VMM does not crash/ restart if the Host is under stress) or check the amount of memory it's using when idle or when playing a movie.

=== Priorization ===

The priorities are as follows:

1.coverage on Mac host
2.coverage on Windows XP
3.coverage on Windows 7

=== Coverage ===

At this stage we are aiming towards feature and functionality coverage.

=== Configurations ===

VMM will tested in a number of computer configurations that include Mac and Windows.

=== Test Execution ===

The tests will be executed manually, until some of the testing process will be automated. The automation tests will vary according to the Host OS that they will be run.

=== Test Reporting ===

Reporting for individual test sessions is done in [http://qa-reports.meego.com/ qa-reports]. Verticals might have additional reporting practices defined.

=== Test Tools ===

QA will focus to automate tests as much as possible.
On benchmarks, various tools will be used including OpenArena, Sunspider, Phoronix Test Suite. They will give data helping us to compare the performance of the emulator when VMM is used.

=== Testing Quality Characteristics ===

Check out the [[Quality/Test_areas_and_types|Test areas and types]].

==== Functionality ====

The basic functionality checklist can be categorized as below:
* Installation and un-installation
* Startup and exiting
* Screen Layout and Navigation in QEMU
* Connectivity between Host and QEU
* Help and documentation
* UI Controls
[[Quality/Test_areas_and_types#Functionality_quality_characteristics|Test areas and types for functionality]] has more details/ideas.

==== Performance ====

The performance target is to produce a quality product with a performance that is competitive in the market. This is going to be achieved by first looking at the different areas that affect the performance of the emulator and then trying to measure these values to find out where performance needs to be improved.
The focus areas might be:

* Application Startup times
* Startup times
* Memory usage
* Benchmark results

Our goal to have a fast, responsive and stable emulator using VMM on Mac and Windows.

==== Reliability ====

Our goal is to have a reliable(stable) VMM module in the following targets:
* Mac OS
* Windows

== General Environment Setup ==

The VMM should be available on any machine that runs Windows or Mac OS.

SDKTestPlan 1.3Release

2011-06-15T16:38:55Z

Ionutgavaz: /* Test Host & Target */

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || TBD
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|Tablet
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKTestPlan 1.3Release

2011-06-15T16:28:34Z

Ionutgavaz: /* Tools to set up develop environment */

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || TBD
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|CDK
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKTestPlan 1.3Release

2011-06-15T16:24:44Z

Ionutgavaz: Created page with "= MeeGo SDK Test Plan = == Scope of this Document == This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test sco..."

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || P1
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|CDK
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKTestPlan

2011-06-15T16:21:33Z

Ionutgavaz: /* Tools to set up develop environment */

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || P1
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|CDK
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKTestPlan

2011-06-15T15:56:11Z

Ionutgavaz: /* Tools to set up develop environment */

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || TBD
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|CDK
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKTestPlan

2011-06-15T15:55:41Z

Ionutgavaz: /* Tools to set up develop environment */

= MeeGo SDK Test Plan =

== Scope of this Document ==
This is overall test plan for MeeGo SDK(Software Development Kit) of '''MeeGo open source project''', which defines test scope, test strategy, test configurations as well as test execution cycle for MeeGo SDK. It will give readers an overview of validation activities for MeeGo SDK of MeeGo open source releases. A series of component test plans will also be linked in this overall test plan to cover the detailed test approaches and test design for ingredients of MeeGo SDK.

== Features to Be Tested ==
Overall the MeeGo Core Testing will cover below host, target and testpoints:
*P1: Test focus with main functionality, make sure common case work
*P2: Nice to have for coming release
*TBD: not covered in coming release
=== Tools to set up develop environment ===
{|cellspacing="0" border="1"
!|Tools
!|Priority
|-
| Emulator: Qemu || P1
|-
| Simulator: Xephyr + chroot || TBD
|-
| VirtualBox || TBD
|}

=== Test Host & Target ===
{|cellspacing="0" border="1"
!|Host\Target
!|Netbook
!|Handset
!|CDK
!|ARM based platform
|-
|Fedora13 || P1 || P1 || TBD || *
|-
|Fedora12 || P2 || P2 || TBD || *
|-
|Ubuntu10.04 || P1 || P1 || TBD || *
|-
|Ubuntu9.10 || P2 || P2 || TBD || *
|-
|OpenSuse 11.2 || TBD || TBD || TBD || *
|-
|OpenSuse 11.3 || TBD || TBD || TBD || *
|-
|WindowsXP || P1 || P1 || TBD || *
|-
|Win 7 || TBD || TBD || TBD || *
|-
|Meego Netbook || TBD || TBD || TBD || *
|-
|Mac OS || TBD ||TBD ||TBD || *
|}

* means to be filled

=== Check Pointer ===
{|cellspacing="0" border="1"
|colspan="2"|
'''Check Point'''
|'''Priority'''
|-
|colspan="2"|SDK installer works|| P1
|-
|colspan="2"|SDK un-installer works|| P1
|-
|colspan="2"|OBS remote build works|| TBD
|-
|colspan="2"|OBS local build works|| TBD
|-
|colspan="2"|SDK images compliance with Meego images || P1
|-
|colspan="2"|Boot SDK images with Qemu [http://wiki.meego.com/Quality/Plans/VMM_test_plan VMM Test Plan]|| P1
|-
|colspan="2"|Boot SDK images with Xephyr || P2
|-
|Basic function check for SDK image ||
*check basic services: network, telephond, dbus, etc.
|P1
|-
|Qt Creator ||
*Compiling plugins: OBS plugin, MADDE plugin
*Run plugins: Run on Device plugin, Qemu plugin, Xephyr/chroot plugin
*Debug plugins:GDB plugin, oprofile plugin, valgrind plugin
|P1
|-
|colspan="2"|MADDE || P1
|-
|colspan="2"|sysroots || P1
|-
|colspan="2"|toolchains || P1
|-
|App development
* program, build, debug inside simulator or emulator
* deploy to target and remote debug on target
||
* CLI QT
* GUI QT
* MTF QT (handset only)
* WRT
||
* P1
* P1
* P1
* TBD
|-
|colspan="2"|Documents & Toturials || P1
|-
|colspan="2"|Additional tools || TBD
|-
|colspan="2"|Memory/performance/power check || TBD
|}

== What will not Be Tested ==
Following feature category won't be covered in MeeGo SDK testing.
* Only lightly test for SDK image, not check all of the functionalities or applications inside it, but only major deamon and service of it.
* Not test for SDK package or image building, only check the built out package or images.
* Not cover Meego compliance test, but only check key package versions which should align with Meego release.
* 64bit support is in plan, will be 2nd priority for testing.
* VirtualBox support is still under investiagtion, will be taken into consideration for next step.

== Test Strategy and Approach ==
The overall objective of MeeGo SDK testing is to ensure MeeGo SDK provide stable environment for developers to program on host machine within simulator or emulator, conduct build and debugging inside it, deploy the application to target and remote debug on target.
The test cycle, bug lifecycle defined below may not apply to SDK testing because of not clear about if distribution will be involved for short term, but it can be refered and modified after we get synchronized on these opens.

=== Test Cycle ===
MeeGo SDK will be tested from the following different test execution levels according to detail development, release status.

==== Weekly Testing ====
Weekly Testing is a test cycle against the weekly images released from distribution team. Usually the test frequency is twice a week, which aligns with distribution's weekly image release cadence.

It's an incremental testing and includes two parts in general: test the basic distribution health to report out regression, test new features when they are ready for testing. We will also do bug verification and regression test which is set of tests to verify that changes from the last build (code enhancements, bug fixes) don't introduce new issues to the previous working code. The purpose of weekly testing is to early test the new features, to track critical/major issues got fixed in timely fashion, and to report out the overall quality status of the whole image so that people could understand where we are.

==== Milestone Testing ====
In the formal test cycle for milestone test, after a new build passed the BAT test, test team will start the full validation testing for it.

==== Regression Testing ====
This is a set of tests to verify that changes from the last build (code enhancements, bug fixes) don’t introduce new issues to the previous working code as well as new features work as expected. This cycle include the tests for previous major bug fixes and areas of the code that will be affected by new implementation.

The regression test will be taken in following test cycle:
* In the test cycle for milestone release, before the release criteria is satisfied, it is possible that there are several release candidates which includes bug fixes for previous release candidates. These bug-fixes need be tested
* In the intermediate regular release, only the modified features need to be heavily tested.
* Bug verification on weekly basis to make sure the bug fixes be verified within one week after bug fixing

=== Bug life cycle ===
*Bug life cycle follow Meego general definition, refer to [http://moblin.intel.com/wiki/MeeGo_Bugzilla_and_Bug_Triage MeeGo bugzilla guide]
*SDK has customized bugzilla to meet project characters, refer to [http://wiki.meego.com/SDK/Bugzilla_Components SDK Bugzilla Components]

=== Test Report ===
* Send Test report to mailing list
** Weekly MeeGo SDK Test Report (Bug verification, new feature exploration...)
** Distribution Milestone Full Pass Test report
* Archive reports at [http://wiki.meego.com/Quality/SDKTestReports MeeGo SDK Quality] wiki

== Environmental Needs ==
=== Hardware Platforms ===
#Host machine
#* Fedora 13
#* Fedora 12
#* Ubuntu9.10
#* Ubuntu10.04
#* OpenSuse 11.2
#* OpenSuse 11.3
#* windows XP
#* Win7
#Target machine
#* Netbook -- AspireOne NAV50
#* Handset -- Aava
#* ARM based Devices-- N900

=== Peripherals required ===
{|cellspacing="0" border="1"
!| Category || Peripherals
|-
| USB devices || keyboard, mouse, USB storage device , ...
|-
|}

=== Network Environment ===
The networking arrangements needed to conduct the testing:
*WLAN
*LAN
*USB

== References ==
* Meego SDK Development Guide: http://wiki.meego.com/MeeGo_SDK_Development_Guide
* Meego1.1 Application SDK Project Plan: http://wiki.meego.com/SDK/MeeGo_1.1_Application_SDK_Project_Plan
* Meego SDK requirement document [[File:MeeGo_SDK_Requirements.xls|Meego SDK requirements]]
* MeeGo Architecture: http://meego.com/developers/meego-architecture
* MeeGo bugzilla: http://bugs.meego.com

SDKBugTriageMinutesArchive

2011-05-25T07:34:45Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-25-05.58.html MeeGo SDK Bug Triage 20110525]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-18-05.58.html MeeGo SDK Bug Triage 20110518]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-11-05.58.html MeeGo SDK Bug Triage 20110511]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

SDKBugTriageMinutesArchive

2011-05-18T07:34:13Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-18-05.58.html MeeGo SDK Bug Triage 20110518]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-11-05.58.html MeeGo SDK Bug Triage 20110511]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

SDKBugTriageMinutesArchive

2011-05-11T07:21:55Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-11-05.58.html MeeGo SDK Bug Triage 20110511]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

SDK/Docs/Simulator

2011-05-10T14:58:47Z

Ionutgavaz: /* Build, Run and Deploy Qt Application to Simulator */

== How to use Qt Simulator in MeeGo SDK ==
This page is a guideline of how to use Qt Simualtor in MeeGo SDK. It describes how to create a simple Qt GUI application, build it against Simulator Qt libraries and deploy it to Qt Simulator with MeeGo device modules. You can refer to the official Qt Simulator page for more details: [http://doc.qt.nokia.com/qtsimulator-1.1/index.html Qt Simulator Manual ]

=== Create a new Qt project in Qt Creator ===
*You should open Qt Creator to begin designing a Qt application. Please create a simple Qt GUI project from the menu of Qt Creator, "File -> New File or Project -> Qt GUI Application"

[[File:Qt simulator new.png]]

*Name the application as "HelloQtSimulator" and choose directory to store this Qt project files.

[[File:Qt simulator new2.png|800px]]

*Choose the Qt Version as "MeeGo SDK Simulator" which provide a Qt library and will be used to build with the Qt application.

[[File:Qt simulator new3.png|800px]]

=== Build, Run and Deploy Qt Application to Simulator ===
*Please click the "Projects" label on the left panel of Qt Creator and then confirm the Build & Run setting in Projects label has set to "Qt Simulator". You can change the "Edit build configuration" option to "Debug", if you want to debug this application in Qt Simulator.

[[File:Qt simulator build run.png|800px]]

*Click the green Run button to build the application and automatically deploy the application to Qt Simulator. Qt Simulator with a control panel and application window will be invoke and boot up automatically. There are three kinds of predefined MeeGo device modules with different skins and resolutions: 864x480, 960x540, 1280x800. You can choose these devices in Qt Simulator's control panel: View-> Device.

[[File:Qtsimualtor choose model.png]]

If the application is deployed successfully and you have chosen the model for MeeGo device, the application will be displayed in the Simulator.

[[File:Qtsimulator deploy.png|800px]]

=== Define your own device module in Qt Simulator ===
Qt Simulator support user defined device module, you can refer to this article: [http://doc.qt.nokia.com/qtsimulator-1.1/simulator-adding-models.html Adding New Device Models for Qt Simulator] to add a new device module.

SDK/Docs/Simulator

2011-05-10T14:57:44Z

Ionutgavaz: /* Build, Run and Deploy Qt Application to Simulator */

== How to use Qt Simulator in MeeGo SDK ==
This page is a guideline of how to use Qt Simualtor in MeeGo SDK. It describes how to create a simple Qt GUI application, build it against Simulator Qt libraries and deploy it to Qt Simulator with MeeGo device modules. You can refer to the official Qt Simulator page for more details: [http://doc.qt.nokia.com/qtsimulator-1.1/index.html Qt Simulator Manual ]

=== Create a new Qt project in Qt Creator ===
*You should open Qt Creator to begin designing a Qt application. Please create a simple Qt GUI project from the menu of Qt Creator, "File -> New File or Project -> Qt GUI Application"

[[File:Qt simulator new.png]]

*Name the application as "HelloQtSimulator" and choose directory to store this Qt project files.

[[File:Qt simulator new2.png|800px]]

*Choose the Qt Version as "MeeGo SDK Simulator" which provide a Qt library and will be used to build with the Qt application.

[[File:Qt simulator new3.png|800px]]

=== Build, Run and Deploy Qt Application to Simulator ===
*Please click the "Projects" label on the left panel of Qt Creator and then confirm the Build & Run setting in Projects label has set to "Qt Simulator". You can change the "Edit build configuration" option to "Debug", if you want to debug this application in Qt Simulator.

[[File:Qt simulator build run.png|800px]]

*Click the green Run button to build the application and automatically deploy the application to Qt Simulator. Qt Simulator with a control panel and application window will be invoke and boot up automatically. There are three kinds of predefined MeeGo device modules with different skins and resolutions: 864x480, 960x540, 1280x800. You can choose these devices in Qt Simulator's control panel: View-> Device

[[File:Qtsimualtor choose model.png]]

If the application is deployed successfully and you have chosen the model for MeeGo device, the application will be displayed in the Simulator.

[[File:Qtsimulator deploy.png|800px]]

=== Define your own device module in Qt Simulator ===
Qt Simulator support user defined device module, you can refer to this article: [http://doc.qt.nokia.com/qtsimulator-1.1/simulator-adding-models.html Adding New Device Models for Qt Simulator] to add a new device module.

SDKBugTriageMinutesArchive

2011-05-04T11:30:06Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

SDKBugTriageMinutesArchive

2011-05-04T11:29:43Z

Ionutgavaz:

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]
*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-05-04-05.59.html MeeGo SDK Bug Triage 20110504]

SDKBugTriageMinutesArchive

2011-05-02T13:24:13Z

Ionutgavaz: Created page with "*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]"

*[http://irclogs.meego.com/meetbot/meego-meeting2/2011/meego-meeting2.2011-04-27-05.59.html MeeGo SDK Bug Triage 20110427]

Quality/Bugtriage

2011-05-02T13:17:45Z

Ionutgavaz: /* MeeGo Bug Triage Meetings */

== Bug Triage Definition ==
* Bug Triage is a process to:
** Ensure bug report completeness
** Analyze and assign bug to proper component
** Assign bug to proper bug owner
** Set appropriate bug priority
** Adjust bug severity properly (initially set by bug reporter)
** Resolve obvious invalid, duplication, won’t fix bugs etc.
** Forward bugs in upstream components to [[Quality/UpstreamBugTrackers | upstream bugtrackers]] and adding the upstream URL to the URL field of the report, if applicable

* Bug Triage Team
** A small team works on bug triage, could be experienced developer, distro engineer or QA
** Triage team members are expected to contribute significant time to bug triage

Please share your triaging knowledge by adding/editing [[Quality/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]].

== Bug Triage Process ==
* Triage new incoming bug reports timely by each triage team (from twice a week to daily triage).
* Triage team members in each triage team could have different focus, such as IA arch bugs, ARM bugs or specific applications etc.
* Each triage team meet on IRC weekly to discuss controversial bug reports and any open reports
* Bug assignees accept bug reports by setting target milestones for triaged bug reports
* [http://meego.com/about/governance/program-office Program Managers] host bug report scrub meetings to discuss bug reports which do not have a target milestone set

Triage Process Flow as follows:
[[File:bug_triage_process.jpg]]

== MeeGo Bug Triage Guide ==
Check the [[Quality/Bugtriage_Guide|Triage Guide]] that explains good practices when triaging bug reports.

== MeeGo Bug Triage Team ==
{|cellspacing="0" border="1"
!|MeeGo Bug Triage Team
!|Member
|-
| MeeGo Core OS Triage || [http://meego.com/users/jerry Jerry Yu], Peter Zhu, [http://meego.com/users/shuangeeer Yanshuang Zheng], [http://meego.com/users/ttoropainen Tommi Toropainen], [http://meego.com/users/juhanitaipale Juhani Taipale], [http://meego.com/users/jarnoteivas Jarno Teivas], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Handset UX Triage || Fan Zhao, Cathy Li, [http://meego.com/users/srikanthyarlagadda Srikanth Yarlagadda],[http://meego.com/users/mikikone Mika Ikonen], [http://meego.com/users/jylha Petri Jylha], [http://meego.com/users/pekoski Petri Koski], [http://meego.com/users/ceferron Chris Ferron], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Netbook UX Triage || [http://meego.com/users/lingyu Ling Yu], Daniel Tao, [http://meego.com/users/yanglei Lei Yang], [http://meego.com/users/rossburton Ross Burton]
|-
| MeeGo IVI Triage || [http://meego.com/users/shuangeeer Yanshuang Zheng]
|-
| MeeGo Translation Triage || [http://meego.com/users/margie Margie Foster], [http://meego.com/users/pmccarty Patrick McCarty]
|-
| MeeGo SDK Triage || Juha Peisanen, Ionut Gavaz, Fathi Boudra, Jackie Wu, Max Yu
|}

=== MeeGo Bug Triage Meetings ===

* MeeGo Core Bug Triage
** Time: Every Monday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Handset Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Netbook Bug Triage
** Time: Every Tuesday at 13:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo IVI Bug Triage
** Time: TBD
* MeeGo Translation Bug Triage
** Time: TBD
* MeeGo SDK Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MCTS Bug Triage
** Time: Every Wednesday at 08:00 [http://www.timeanddate.com/worldclock/converter.html UTC]

Those meetings take place in the IRC channel'''#meego-meeting''' on [http://freenode.net irc.freenode.net].

To discuss MeeGo bug triaging at any time feel free to visit the IRC channel '''#meego-bugs''' on [http://freenode.net irc.freenode.net].

* [[CoreBugTriageMinutesArchive|MeeGo Core Bug Triage Meeting Minutes Archive]]
* [[HandsetBugTriageMinutesArchive|MeeGo Handset Bug Triage Meeting Minutes Archive]]
* [[NetbookBugTriageMinutesArchive|MeeGo Netbook Bug Triage Meeting Minutes Archive]]
* [[SDKBugTriageMinutesArchive|MeeGo SDK Bug Triage Meeting Minutes Archive]]

=== Getting involved ===

Anyone can sign up for the triage team and start helping (see the [[Quality/Bugtriage_Guide|Triage Guide]] for information and steps). Just send an email to the [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list] to get involved in. Thanks for your contribution to MeeGo!

== Other references ==
[[Quality/How_To_Report_Bugs|How to report MeeGo bugs?]]

[[Category:QA]]

Quality/Bugtriage

2011-05-02T13:06:07Z

Ionutgavaz: /* MeeGo Bug Triage Team */

== Bug Triage Definition ==
* Bug Triage is a process to:
** Ensure bug report completeness
** Analyze and assign bug to proper component
** Assign bug to proper bug owner
** Set appropriate bug priority
** Adjust bug severity properly (initially set by bug reporter)
** Resolve obvious invalid, duplication, won’t fix bugs etc.
** Forward bugs in upstream components to [[Quality/UpstreamBugTrackers | upstream bugtrackers]] and adding the upstream URL to the URL field of the report, if applicable

* Bug Triage Team
** A small team works on bug triage, could be experienced developer, distro engineer or QA
** Triage team members are expected to contribute significant time to bug triage

Please share your triaging knowledge by adding/editing [[Quality/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]].

== Bug Triage Process ==
* Triage new incoming bug reports timely by each triage team (from twice a week to daily triage).
* Triage team members in each triage team could have different focus, such as IA arch bugs, ARM bugs or specific applications etc.
* Each triage team meet on IRC weekly to discuss controversial bug reports and any open reports
* Bug assignees accept bug reports by setting target milestones for triaged bug reports
* [http://meego.com/about/governance/program-office Program Managers] host bug report scrub meetings to discuss bug reports which do not have a target milestone set

Triage Process Flow as follows:
[[File:bug_triage_process.jpg]]

== MeeGo Bug Triage Guide ==
Check the [[Quality/Bugtriage_Guide|Triage Guide]] that explains good practices when triaging bug reports.

== MeeGo Bug Triage Team ==
{|cellspacing="0" border="1"
!|MeeGo Bug Triage Team
!|Member
|-
| MeeGo Core OS Triage || [http://meego.com/users/jerry Jerry Yu], Peter Zhu, [http://meego.com/users/shuangeeer Yanshuang Zheng], [http://meego.com/users/ttoropainen Tommi Toropainen], [http://meego.com/users/juhanitaipale Juhani Taipale], [http://meego.com/users/jarnoteivas Jarno Teivas], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Handset UX Triage || Fan Zhao, Cathy Li, [http://meego.com/users/srikanthyarlagadda Srikanth Yarlagadda],[http://meego.com/users/mikikone Mika Ikonen], [http://meego.com/users/jylha Petri Jylha], [http://meego.com/users/pekoski Petri Koski], [http://meego.com/users/ceferron Chris Ferron], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Netbook UX Triage || [http://meego.com/users/lingyu Ling Yu], Daniel Tao, [http://meego.com/users/yanglei Lei Yang], [http://meego.com/users/rossburton Ross Burton]
|-
| MeeGo IVI Triage || [http://meego.com/users/shuangeeer Yanshuang Zheng]
|-
| MeeGo Translation Triage || [http://meego.com/users/margie Margie Foster], [http://meego.com/users/pmccarty Patrick McCarty]
|-
| MeeGo SDK Triage || Juha Peisanen, Ionut Gavaz, Fathi Boudra, Jackie Wu, Max Yu
|}

=== MeeGo Bug Triage Meetings ===

* MeeGo Core Bug Triage
** Time: Every Monday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Handset Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Netbook Bug Triage
** Time: Every Tuesday at 13:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo IVI Bug Triage
** Time: TBD
* MeeGo Translation Bug Triage
** Time: TBD
* MeeGo SDK Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MCTS Bug Triage
** Time: Every Wednesday at 08:00 [http://www.timeanddate.com/worldclock/converter.html UTC]

Those meetings take place in the IRC channel'''#meego-meeting''' on [http://freenode.net irc.freenode.net].

To discuss MeeGo bug triaging at any time feel free to visit the IRC channel '''#meego-bugs''' on [http://freenode.net irc.freenode.net].

* [[CoreBugTriageMinutesArchive|MeeGo Core Bug Triage Meeting Minutes Archive]]
* [[HandsetBugTriageMinutesArchive|MeeGo Handset Bug Triage Meeting Minutes Archive]]
* [[NetbookBugTriageMinutesArchive|MeeGo Netbook Bug Triage Meeting Minutes Archive]]

=== Getting involved ===

Anyone can sign up for the triage team and start helping (see the [[Quality/Bugtriage_Guide|Triage Guide]] for information and steps). Just send an email to the [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list] to get involved in. Thanks for your contribution to MeeGo!

== Other references ==
[[Quality/How_To_Report_Bugs|How to report MeeGo bugs?]]

[[Category:QA]]

SDK/QA/MeetingMinutes/20110426

2011-04-26T09:41:33Z

Ionutgavaz: Created page with "==2011-4-26== *Attendees: Ionut,Juha **AR Andreea: Review the MCTS API test cases **Usability tests to be included - Ionut to follow up on it **Juha to schedule the TP cross-revi..."

==2011-4-26==
*Attendees: Ionut,Juha
**AR Andreea: Review the MCTS API test cases
**Usability tests to be included - Ionut to follow up on it
**Juha to schedule the TP cross-review meeting
**Juha to propose bugs for triage from his side

SDK/QA

2011-04-26T09:40:32Z

Ionutgavaz: /* Meeting Minutes */

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.

== 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
* Ionut Gavaz -- 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 @ [[SDKTestPlan|SDK Test Plan]]

== Test Report ==
*[http://qa-reports.meego.com/ MeeGo SDK Test Reports]

== Meeting ==
* When: Every Tuesday at 11:00~12:00 (UTC+2).
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe

=== 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]]

Quality/Bugtriage

2011-04-22T12:32:34Z

Ionutgavaz: /* MeeGo Bug Triage Meetings */

== Bug Triage Definition ==
* Bug Triage is a process to:
** Ensure bug report completeness
** Analyze and assign bug to proper component
** Assign bug to proper bug owner
** Set appropriate bug priority
** Adjust bug severity properly (initially set by bug reporter)
** Resolve obvious invalid, duplication, won’t fix bugs etc.
** Forward bugs in upstream components to [[Quality/UpstreamBugTrackers | upstream bugtrackers]] and adding the upstream URL to the URL field of the report, if applicable

* Bug Triage Team
** A small team works on bug triage, could be experienced developer, distro engineer or QA
** Triage team members are expected to contribute significant time to bug triage

Please share your triaging knowledge by adding/editing [[Quality/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]].

== Bug Triage Process ==
* Triage new incoming bug reports timely by each triage team (from twice a week to daily triage).
* Triage team members in each triage team could have different focus, such as IA arch bugs, ARM bugs or specific applications etc.
* Each triage team meet on IRC weekly to discuss controversial bug reports and any open reports
* Bug assignees accept bug reports by setting target milestones for triaged bug reports
* [http://meego.com/about/governance/program-office Program Managers] host bug report scrub meetings to discuss bug reports which do not have a target milestone set

Triage Process Flow as follows:
[[File:bug_triage_process.jpg]]

== MeeGo Bug Triage Guide ==
Check the [[Quality/Bugtriage_Guide|Triage Guide]] that explains good practices when triaging bug reports.

== MeeGo Bug Triage Team ==
{|cellspacing="0" border="1"
!|MeeGo Bug Triage Team
!|Member
|-
| MeeGo Core OS Triage || [http://meego.com/users/jerry Jerry Yu], Peter Zhu, [http://meego.com/users/shuangeeer Yanshuang Zheng], [http://meego.com/users/ttoropainen Tommi Toropainen], [http://meego.com/users/juhanitaipale Juhani Taipale], [http://meego.com/users/jarnoteivas Jarno Teivas], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Handset UX Triage || Fan Zhao, Cathy Li, [http://meego.com/users/srikanthyarlagadda Srikanth Yarlagadda],[http://meego.com/users/mikikone Mika Ikonen], [http://meego.com/users/jylha Petri Jylha], [http://meego.com/users/pekoski Petri Koski], [http://meego.com/users/ceferron Chris Ferron], [http://meego.com/users/iekku Iekku Huttunen]
|-
| MeeGo Netbook UX Triage || [http://meego.com/users/lingyu Ling Yu], Daniel Tao, [http://meego.com/users/yanglei Lei Yang], [http://meego.com/users/rossburton Ross Burton]
|-
| MeeGo IVI Triage || [http://meego.com/users/shuangeeer Yanshuang Zheng]
|-
| MeeGo Translation Triage || [http://meego.com/users/margie Margie Foster], [http://meego.com/users/pmccarty Patrick McCarty]
|-
| MeeGo SDK Triage || Juha Peisanen, Daniel Mihai, Fathi Boudra, Jackie Wu, Max Yu
|}

=== MeeGo Bug Triage Meetings ===

* MeeGo Core Bug Triage
** Time: Every Monday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Handset Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo Netbook Bug Triage
** Time: Every Tuesday at 13:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MeeGo IVI Bug Triage
** Time: TBD
* MeeGo Translation Bug Triage
** Time: TBD
* MeeGo SDK Bug Triage
** Time: Every Wednesday at 07:00 [http://www.timeanddate.com/worldclock/converter.html UTC]
* MCTS Bug Triage
** Time: Every Wednesday at 08:00 [http://www.timeanddate.com/worldclock/converter.html UTC]

Those meetings take place in the IRC channel'''#meego-meeting''' on [http://freenode.net irc.freenode.net].

To discuss MeeGo bug triaging at any time feel free to visit the IRC channel '''#meego-bugs''' on [http://freenode.net irc.freenode.net].

* [[CoreBugTriageMinutesArchive|MeeGo Core Bug Triage Meeting Minutes Archive]]
* [[HandsetBugTriageMinutesArchive|MeeGo Handset Bug Triage Meeting Minutes Archive]]
* [[NetbookBugTriageMinutesArchive|MeeGo Netbook Bug Triage Meeting Minutes Archive]]

=== Getting involved ===

Anyone can sign up for the triage team and start helping (see the [[Quality/Bugtriage_Guide|Triage Guide]] for information and steps). Just send an email to the [http://lists.meego.com/listinfo/meego-qa meego-qa mailing list] to get involved in. Thanks for your contribution to MeeGo!

== Other references ==
[[Quality/How_To_Report_Bugs|How to report MeeGo bugs?]]

[[Category:QA]]

MeeGo-Meeting IRC Schedule

2011-04-22T12:30:57Z

Ionutgavaz: /* Regular Meetings */

SDK/Meetings/20110406 Weekly

2011-04-14T13:46:54Z

Ionutgavaz: /* QA (Juha) */

= MeeGo SDK Weekly Meeting 20110406 =

This document contains status update of 20110406.

== Conventions of this document ==

* AP: = Action point agreed on this meeting
* yyyymmdd AP: = Action point agreed on previous meeting
* yyyymmdd AP yyymmdd: = Action point agreed on previous meeting with a deadline
* yyyymmdd AP DONE: = Action point done
* yyyymmdd AP CANCELLED: = Action point cancelled
* AGREE: = Item that has been agreed by the team
* POSTPONED: = Agenda item postponed from last meeting
* OLD: = Info from previous meeting (delete during the meeting)

== Status ==

=== SDK Program (Veli) ===

* Nokia changes...

==== Features (Ville) ====

=== Architecture (Bob) ===

(Meetings held weekly, as needed)

* http://wiki.meego.com/SDK/Architecture

Topics for future meetings:
* How to speed up MeeGo SDK
** Install (reduce size, target/sysroot management)
** Deploy/debug (QEMU acceleration, deploy w/o packaging, etc)
* rsync: Using QEMU files for sysroot
** http://wiki.meego.com/SDK/Sysroot_extension
* Release process (discussion started)
* Windows builds (server - http://bugs.meego.com/show_bug.cgi?id=11762, process)
* How to identify the installed MeeGo SDK version (registry key, file, gconf)

* March 30th Meeting
** Maurice: Qt Creator 2.2 review
** Fathi: sysroot "sliming" scheduled. Fathi sent an email status.
** Edmondas: QEMU use for sysroot

Covered in past weeks (Resolutions here: http://piratepad.net/qqICWdiYLl )
* Thurs 20th Meeting
** Package group - list of devel packages in sysroot
*** Study on http://wiki.meego.com/SDK/Packages_group
** Qt Creator rc1 promotion and QA

* Thurs 13th Meeting
** Accomodate 3rd party libraries in addition to sysroot on Windows and Linux
** Feature 10949 - [FEA] Make the installation of MeeGo SDK for Linux easier http://bugs.meego.com/show_bug.cgi?id=10949

** AP: Add minutes to: http://wiki.meego.com/SDK/Meetings (Bob) DONE.

=== Releasing (Fathi) ===

* feature freeze - bug fix only
** exceptions: Toolchains and Qt simulator
* hardfp toolchain into MeeGo Trunk
** SDK toolchain to update/promote
** AP: ks files to update - new images (Fathi)
** AP: update madde configuration for ARM toolchain (Fathi)
* Full toolchain upgrade to 1.2 is on the way for all architectures IA32/ARM softfp and hardfp
** Pending windows toolchain integrated - Windows SDK is using 1.1 toolchains - Use 1.2 now (Max)
* AP: Qt Simulator to review and promote (Fathi)

=== Windows port (Max) ===

* Preview 7 has been released
* AP: ARM hardfp toolchain should be provided by Al
* AP: Al to create a wiki page about the windows build server

=== Mac OS X port (David) ===

* David was not present

=== Toolchains (JuhaK) ===

* Proposing to properly configure the sdk toolchain to use cloog library, which it currently doesn't. Using cloog will enable the graphite loop optimizer in gcc.
* Proposing updates to the MeeGo 1.3 devel:toolchain build dependency packages (mpfr, gmp, cloog) and to configure the arm toolchain to use cloog too. This has been disabled because of some failures a long time ago.
* arm glibc (>= 2.12) build problems solved last week

=== Documentation (Taru) ===

* Taru Laine will be on holiday from 15 to 25 April.
* The agenda for this week's documentation status meeting is here: http://wiki.meego.com/SDK/Documentation/MeetingMinutes/20110407#Agenda
** This week the aim of the meeting is to go through the status of each content area in the http://wiki.meego.com/Documentation_Backlog_for_MeeGo_1.2 and see if there are any blocks or open issues that prevent progress on a specific task.
* Work on Linux setup instructions will start next week. Fathi Boudra has an action point of assigning a member of his team to create draft instructions based on MeeGo 1.1 SDK documentation. After that, Taru will go through the instructions during week 17.
* New MeeGo 1.2 SDK features in Bugzilla needed for creating instructions for developing with MeeGo chroot and Xephyr. Bob Spencer has an action point on this.
* Draft content for MeeGo API reference documentation and Glossary is available.
* Open issues:
** Which performance testing tools are supported by MeeGo 1.2 SDK?
** Installation/packaging instructions for OBS - are these included in the developer library?
** Sample applications: can the feature be reassigned?

=== QA (Juha) ===

* All QA reports at http://qa-reports.meego.com/
* Feature status :
** Released :
*** total 1
*** test case exists 0
** Resolved :
*** total 13
*** test case exists 7
** Accepted :
*** 76 for 1.2 (total 107)
*** test case exists 13 for 1.2
* Testing
** Testing done last week for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.99.0.20110329.5]] on Ubuntu 10.10 32bit and Fedora13 32bit.
*** Results updated to http://qa-reports.meego.com/1.2/Sdk/Basic%20Feature%20Testing/N900 .
*** Valid bugs on both distros : #12335 MTF app build, #13831 MTF app widgets, #14910 app launch on device, #14914 qemu launch
*** Valid bugs on Ubuntu : #12853 libattica, #13171 OBS plugin, #14912 wlan debug
*** Valid bugs on Fedora : #12561 uninstallation, #12820 install libattica, #12821 plugin errors on qtcreator start
** Testing not started for http://repo.meego.com/MeeGo/builds/trunk/1.1.99.1.20110405.3/ because no tar of sysroot available.
** Testlink (tl.meego.com) is not available, but it's been informed to Intel.

* Test transition is still in progress.
* Review test cases on tl (BMC#12536)
* Formalize bug handling workflow

SDK/QA/MeetingMinutes/20110412

2011-04-12T09:00:49Z

Ionutgavaz: Created page with "==2011-4-12== *Attendees: Andreea,Ionut,Juha **AR Andreea: Review the MCTS API test cases **Usability tests to be included - Ionut to follow up on it **Juha to schedule the TP cr..."

==2011-4-12==
*Attendees: Andreea,Ionut,Juha
**AR Andreea: Review the MCTS API test cases
**Usability tests to be included - Ionut to follow up on it
**Juha to schedule the TP cross-review meeting

SDK/QA

2011-04-12T09:00:32Z

Ionutgavaz: /* Meeting Minutes */

= 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
* Ionut Gavaz -- 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 @ [[SDKTestPlan|SDK Test Plan]]

== Test Report ==
*[http://qa-reports.meego.com/ MeeGo SDK Test Reports]

== Meeting ==
* When: Every Tuesday at 11:00~12:00 (UTC+2).
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe

=== 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]]

SDK/Team Proposal

2011-04-08T11:33:28Z

Ionutgavaz: /* SDK Team Proposal */

= SDK Team Proposal =

* Program Manager - Veli Kaksonen (official), Bob Spencer (Backup)
* Architect - Bob Spencer (official), Veli Kaksonen (Backup)
* Product Manager - Ville Lavonius
* Release Manager - Fathi Boudra (official), Jackie Wu (Backup)
* QA Lead - Jaya Uppalapati (official), Ionut Gavaz (backup)
* Documentation Lead - Bob, Elliot, Ronan, Titta... ??
* Toolchain Lead - Jarmo Kant

== Package Maintainers ==

* MADDE - Fathi Boudra
* Qt Creator + plugins - Fathi Boudra
* QEMU - Fathi Boudra
* Virtual Box - Haitao Feng
* Chroot & Xephyr - Haitao Feng
* Toolchains ARM - Al Nikolov
* Toolchains IA32 - Jackie Wu

== Subsystem Maintainers (official, backup) ==

[development. These guys know the components inside out]:

* Installer - (we need to first figure out what installer we use)
* Qt Creator - Maurice Kalinowski, John Chen
* Qt Creator plugin for MADDE - Nishant Tandon
* Qt Creator plugin for OBS - Max Yu
* Qt Creator plugins ... - ...
* MADDE -
* OBS - (is this ours or not?)
* QEMU - Riku Voipio, Zhiyan Lv
* Virtual Box run environment - Haitao Feng
* Chroot & Xephyr run environment - Haitao Feng
* Toolchains (this needs to be opened to gcc, glibc...)- (Risto Lankinen)

== Notes / discussion ==

From Kerry:

* Few more comments on task breakdown, to see if there is something important/big item missing here:
** What about integration of tools like PowerTOP, Oprofile, Valgrind? including integration into OBS as RPMs and with Qt Creator as plugins
** What about integration with Qt WRT SDK? Qt WRT not in the scope of 1.1?
*** Fathi: Qt WRT is available for MeeGo 1.1. It's a bit late for integration into 1.1. I'm in favor of postponing to 1.2.
** Is the UI/Qt Designer considered by Qt Creator efforts, AFAIK, it is also standalone tool and important to developers? Is it good enough to support all Toolkits/APIs?
*** Fathi: definitely, yes. Qt Creator team planned to improve this area. What do you mean by "all" Toolkits/APIs?
** Device simulation (skin, platform specific devices) already covered by QEMU? Should we separate the efforts on QEMU to bootup and run MeeGo images with good performance from the efforts on simulating devices specific to platforms for multiple OSs(Win,Linux, Mac). Both are big task task items.
*** Fathi: true. actually, the same team is handling QEMU related tasks.

SDK/Bugzilla Components

2011-04-08T11:11:44Z

Ionutgavaz: /* Structure */

== Bugzilla products and components for MeeGo SDK ==

This page explains the structure we have in the bugzilla.

=== Notes ===

* Note1: We need to use Architecture field and Hardware field.
* Note2: in the future, Qt Creator plugins component could be splitted per plugin and merged with Qt Creator component; It is planned to use pristine/vanilla Qt Creator.
* Note3: See [[SDK/Bugzilla_Template]] for the template we use.
* Note4: We need to use OS field to tell Windows, Mac or Linux SDK.
* '''Note5''': Any requirements about bugzilla configuration should go to https://bugs.meego.com/, Meego Community Infrastructure -> bugs.meego.com -> Meego Bugzilla.

=== Structure ===

* MeeGo Application SDK
** Generic (catch all component)
** Qt (bugs related to Qt package on the host supported distribution) ( as a developer I only care about Qt Creator working well or not, suggest removing this.) ([Bob]: Qt Creator is just the IDE. It doesn't hurt to have Qt here IMO, at least let's keep it initially. If not here, where in bugzilla would they file Qt bugs?)
** Qt Creator (bugs related to Qt Creator package on the host supported distribution)
** Qt Creator plugins (bugs related to Qt Creator plugins package on the host supported distribution)
** MADDE (bugs related to MADDE package on the host supported distribution)
** MADDE sysroot (bugs related to sysroot for MADDE)
** QEMU(bugs related to QEMU package specific to Atom-based targets on the host supported distribution)
** QEMU image (bugs related to image for QEMU)
** Simulator (bugs related to the simulator)
** Installer (bugs related to installer)

* MeeGo Platform SDK ( Suggest removing this item, as Platform development tools are covered by Development Tools already)
** Generic (catch all component)
** Toolchain (bugs related to ARM toolchain)
** Is the OBS there already? Testing tools?

* Documentation (catch all the issues found in public documentations)

SDK/Meetings/20110330 Weekly

2011-03-30T12:46:18Z

Ionutgavaz: /* QA (Juha) */

= MeeGo SDK Weekly Meeting 20110330 =

This document contains agenda and minutes (added after the meeting) of SDK weekly telco meeting on 20110330 14:00 GMT.

== Conventions of this document ==

* AP: = Action point agreed on this meeting
* yyyymmdd AP: = Action point agreed on previous meeting
* yyyymmdd AP yyymmdd: = Action point agreed on previous meeting with a deadline
* yyyymmdd AP DONE: = Action point done
* yyyymmdd AP CANCELLED: = Action point cancelled
* AGREE: = Item that has been agreed by the team
* POSTPONED: = Agenda item postponed from last meeting
* OLD: = Info from previous meeting (delete during the meeting)

== Attendees ==

*

== Agenda ==

=== SDK Program (Veli) ===

* Nokia changes...

==== Features (Ville) ====

=== Architecture (Bob) ===

(Meetings held weekly, as needed)

* http://wiki.meego.com/SDK/Architecture

Topics for future meetings:
* How to speed up MeeGo SDK
** Install (reduce size, target/sysroot management)
** Deploy/debug (QEMU acceleration, deploy w/o packaging, etc)
* rsync: Using QEMU files for sysroot
** http://wiki.meego.com/SDK/Sysroot_extension
* Release process (discussion started)
* Windows builds (server - http://bugs.meego.com/show_bug.cgi?id=11762, process)
* How to identify the installed MeeGo SDK version (registry key, file, gconf)

Covered in past weeks (Resolutions here: http://piratepad.net/qqICWdiYLl )
* Thurs 20th Meeting
** Package group - list of devel packages in sysroot
*** Study on http://wiki.meego.com/SDK/Packages_group
** Qt Creator rc1 promotion and QA

* Thurs 13th Meeting
** Accomodate 3rd party libraries in addition to sysroot on Windows and Linux
** Feature 10949 - [FEA] Make the installation of MeeGo SDK for Linux easier http://bugs.meego.com/show_bug.cgi?id=10949

** AP: Add minutes to: http://wiki.meego.com/SDK/Meetings (Bob) DONE.

=== Releasing (Fathi) ===

* hardfp toolchain into MeeGo Trunk
** SDK toolchain to update/promote
** AP: ks files to update - new images (Fathi)
** AP: update madde configuration for ARM toolchain (Fathi)
* Full toolchain upgrade to 1.2 is on the way for all architectures IA32/ARM softfp and hardfp
** Pending windows toolchain integrated - Windows SDK is using 1.1 toolchains
* AP: Qt Simulator to review and promote (Fathi)

=== Windows port (Max) ===

* Still using 1.1 toolchains
* AP: Upgrade to 1.2 toolchains Wenchao and Max on that. - 1.2 toolchain will be released with Preview 6 next Monday
** AP: ARM hardfp toolchain should be provided by Al
* AP: Update to latest Qt/Qt Creator - Qt Creator 2.1 will be released with Preview 6 next Monday
* AP: Al to create a wiki page about the windows build server

=== Mac OS X port (David) ===

* David was not present

=== Toolchains (JuhaK) ===

* Toolchain meetings biweekly (http://wiki.meego.com/SDK/Toolchains/Meetings#MeeGo_Toolchain_Project_Meetings)
* AP: set up a wiki page in meego.com for following the performance/regression testing of toolchain
** This AP is pending because I haven't had time to do it. Target: next week
* glibc 2.12 or newer cannot be built with arm and this needs to be solved - I'm testing a patch right now, but building gcc for i586 seems to have failed this time. I hope to get a solution this week.

=== Documentation (Taru) ===

* Taru Laine is the doc team lead.
* Weekly documentation telco meetings were restarted on March 3. This week's agenda is here: http://wiki.meego.com/SDK/Documentation/MeetingMinutes/20110330#Agenda
* Documentation backlog for MeeGo 1.2 SDK can be found here: http://wiki.meego.com/Documentation_Backlog_for_MeeGo_1.2
** Bob Spencer is clarifying the resources available for tasks that do not have owners at the moment.
* Open questions regarding DMC publishing site (will be discussed at the doc team meeting of week 13):
** What type of documentation should be published through DMC and updated according to release lifecycle?
** What type of documentation should be kept in Wiki for continuous updates?
** Who will take up the main role of developing the site and coordinating the process of content creation/transfer on DMC site?
* SDK feature status and its impacts on documentation (e.g. devices supported by MeeGo 1.2 SDK)
** Any news on this?

=== QA (Juha) ===

* All QA reports at http://qa-reports.meego.com/
* Feature status :
** Released :
*** total 1
*** test case exists 0
** Resolved :
*** total 13
*** test case exists 7
** Accepted :
*** 76 for 1.2 (total 107)
*** test case exists 12 for 1.2
* Testing
** Testing done last week for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.90.8.20110322.2/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.90.8.20110322.2]] on Ubuntu 10.10 32bit and Fedora13 32bit.
*** Results updated to http://qa-reports.meego.com/1.2/Sdk/Basic%20Feature%20Testing/N900 .
*** Valid bugs on both distros : #12335 MTF app build, #12561 uninstallation, #13831 MTF app widgets, #14910 app launch on device, #14912 wlan debug, #14914 qemu launch
*** Valid bugs on Ubuntu : #12853 libattica, #13171 OBS plugin
*** Valid bugs on Fedora : #12820 install libattica, #12821 plugin errors on qtcreator start
** Testing started for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.99.0.20110329.5]] on Ubuntu 10.10 32bit and Fedora13 32bit.

* Mobility API quality
** Accounts -50p/4f
** QFeedBack -14p/6f
** Multimedia -294p/5f
** Gallery -130p/0f
** Location -191p/20f
** Message -187p/62f
** publish&subscribe -23p/9f
** Contacts -369p/2f
** Versit&organizer -111p/2f
** signon -85p/14f
** QMsystem -143p/21f
** qsparql -141p/5f
** systeminfo -83p/6f
** resourcepolicy -96p/0f
** service framework -87p/3f
** sensors -(compilation problem)

* Basic Feature Testing(build 1.1.90.8.20110322.2)
** Ubuntu 10.10
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
** Fedora 13
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
*** Netbook image -11p/0f
*** Handset qemu -13p/2f(failed on [https://bugs.meego.com/show_bug.cgi?id=14874 #14874])
*** Handset Sysroot -27p/0f
**Critical bugs pending: [[https://bugs.meego.com/show_bug.cgi?id=12865 #12865], [https://bugs.meego.com/show_bug.cgi?id=14529 #14529], [https://bugs.meego.com/show_bug.cgi?id=14897 #14897], [https://bugs.meego.com/show_bug.cgi?id=14893 #14893], [https://bugs.meego.com/show_bug.cgi?id=13007 #13007], [https://bugs.meego.com/show_bug.cgi?id=13832 #13832], [https://bugs.meego.com/show_bug.cgi?id=11607 #11607], [https://bugs.meego.com/show_bug.cgi?id=12073 #12073], [https://bugs.meego.com/show_bug.cgi?id=12085 #12085], [https://bugs.meego.com/show_bug.cgi?id=13943 #13943], [https://bugs.meego.com/show_bug.cgi?id=9790 #9790]]

* Total Bug Count(368)
** Critical - New:5 ,NeedInfo:1 ,Assigned:4 ,Waiting for upstream:0 ,Reopened:1 , Resolved:11 ,Released:0 ,Verified:19 ,Closed:0
** Major - New:10 ,NeedInfo:1 ,Assigned:3 ,Waiting for upstream:0 ,Reopened:1 , Resolved:11 ,Released:0 ,Verified:30 ,Closed:1
** Normal - New:101 ,NeedInfo:3 ,Assigned:29 ,Waiting for upstream:1 ,Reopened:6 , Resolved:49 ,Released:16 ,Verified:44 ,Closed:4
** Trivial - New:3 ,NeedInfo:0 ,Assigned:0 ,Waiting for upstream:0 ,Reopened:0 , Resolved:1 ,Released:1 ,Verified:3 ,Closed:0
** Enhancement - New:5 ,NeedInfo:0 ,Assigned:0 ,Waiting for upstream:0 ,Reopened:0 , Resolved:1 ,Released:1 ,Verified:3 ,Closed:0

* Test transition is still in progress.
* Review test cases on tl (BMC#12536)
* Formalize bug handling workflow

SDK/Meetings/20110330 Weekly

2011-03-30T12:44:56Z

Ionutgavaz: /* QA (Juha) */

= MeeGo SDK Weekly Meeting 20110330 =

This document contains agenda and minutes (added after the meeting) of SDK weekly telco meeting on 20110330 14:00 GMT.

== Conventions of this document ==

* AP: = Action point agreed on this meeting
* yyyymmdd AP: = Action point agreed on previous meeting
* yyyymmdd AP yyymmdd: = Action point agreed on previous meeting with a deadline
* yyyymmdd AP DONE: = Action point done
* yyyymmdd AP CANCELLED: = Action point cancelled
* AGREE: = Item that has been agreed by the team
* POSTPONED: = Agenda item postponed from last meeting
* OLD: = Info from previous meeting (delete during the meeting)

== Attendees ==

*

== Agenda ==

=== SDK Program (Veli) ===

* Nokia changes...

==== Features (Ville) ====

=== Architecture (Bob) ===

(Meetings held weekly, as needed)

* http://wiki.meego.com/SDK/Architecture

Topics for future meetings:
* How to speed up MeeGo SDK
** Install (reduce size, target/sysroot management)
** Deploy/debug (QEMU acceleration, deploy w/o packaging, etc)
* rsync: Using QEMU files for sysroot
** http://wiki.meego.com/SDK/Sysroot_extension
* Release process (discussion started)
* Windows builds (server - http://bugs.meego.com/show_bug.cgi?id=11762, process)
* How to identify the installed MeeGo SDK version (registry key, file, gconf)

Covered in past weeks (Resolutions here: http://piratepad.net/qqICWdiYLl )
* Thurs 20th Meeting
** Package group - list of devel packages in sysroot
*** Study on http://wiki.meego.com/SDK/Packages_group
** Qt Creator rc1 promotion and QA

* Thurs 13th Meeting
** Accomodate 3rd party libraries in addition to sysroot on Windows and Linux
** Feature 10949 - [FEA] Make the installation of MeeGo SDK for Linux easier http://bugs.meego.com/show_bug.cgi?id=10949

** AP: Add minutes to: http://wiki.meego.com/SDK/Meetings (Bob) DONE.

=== Releasing (Fathi) ===

* hardfp toolchain into MeeGo Trunk
** SDK toolchain to update/promote
** AP: ks files to update - new images (Fathi)
** AP: update madde configuration for ARM toolchain (Fathi)
* Full toolchain upgrade to 1.2 is on the way for all architectures IA32/ARM softfp and hardfp
** Pending windows toolchain integrated - Windows SDK is using 1.1 toolchains
* AP: Qt Simulator to review and promote (Fathi)

=== Windows port (Max) ===

* Still using 1.1 toolchains
* AP: Upgrade to 1.2 toolchains Wenchao and Max on that. - 1.2 toolchain will be released with Preview 6 next Monday
** AP: ARM hardfp toolchain should be provided by Al
* AP: Update to latest Qt/Qt Creator - Qt Creator 2.1 will be released with Preview 6 next Monday
* AP: Al to create a wiki page about the windows build server

=== Mac OS X port (David) ===

* David was not present

=== Toolchains (JuhaK) ===

* Toolchain meetings biweekly (http://wiki.meego.com/SDK/Toolchains/Meetings#MeeGo_Toolchain_Project_Meetings)
* AP: set up a wiki page in meego.com for following the performance/regression testing of toolchain
** This AP is pending because I haven't had time to do it. Target: next week
* glibc 2.12 or newer cannot be built with arm and this needs to be solved - I'm testing a patch right now, but building gcc for i586 seems to have failed this time. I hope to get a solution this week.

=== Documentation (Taru) ===

* Taru Laine is the doc team lead.
* Weekly documentation telco meetings were restarted on March 3. This week's agenda is here: http://wiki.meego.com/SDK/Documentation/MeetingMinutes/20110330#Agenda
* Documentation backlog for MeeGo 1.2 SDK can be found here: http://wiki.meego.com/Documentation_Backlog_for_MeeGo_1.2
** Bob Spencer is clarifying the resources available for tasks that do not have owners at the moment.
* Open questions regarding DMC publishing site (will be discussed at the doc team meeting of week 13):
** What type of documentation should be published through DMC and updated according to release lifecycle?
** What type of documentation should be kept in Wiki for continuous updates?
** Who will take up the main role of developing the site and coordinating the process of content creation/transfer on DMC site?
* SDK feature status and its impacts on documentation (e.g. devices supported by MeeGo 1.2 SDK)
** Any news on this?

=== QA (Juha) ===

* All QA reports at http://qa-reports.meego.com/
* Feature status :
** Released :
*** total 1
*** test case exists 0
** Resolved :
*** total 13
*** test case exists 7
** Accepted :
*** 76 for 1.2 (total 107)
*** test case exists 12 for 1.2
* Testing
** Testing done last week for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.90.8.20110322.2/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.90.8.20110322.2]] on Ubuntu 10.10 32bit and Fedora13 32bit.
*** Results updated to http://qa-reports.meego.com/1.2/Sdk/Basic%20Feature%20Testing/N900 .
*** Valid bugs on both distros : #12335 MTF app build, #12561 uninstallation, #13831 MTF app widgets, #14910 app launch on device, #14912 wlan debug, #14914 qemu launch
*** Valid bugs on Ubuntu : #12853 libattica, #13171 OBS plugin
*** Valid bugs on Fedora : #12820 install libattica, #12821 plugin errors on qtcreator start
** Testing started for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.99.0.20110329.5]] on Ubuntu 10.10 32bit and Fedora13 32bit.

* Mobility API quality
** Accounts -50p/4f
** QFeedBack -14p/6f
** Multimedia -294p/5f
** Gallery -130p/0f
** Location -191p/20f
** Message -187p/62f
** publish&subscribe -23p/9f
** Contacts -369p/2f
** Versit&organizer -111p/2f
** signon -85p/14f
** QMsystem -143p/21f
** qsparql -141p/5f
** systeminfo -83p/6f
** resourcepolicy -96p/0f
** service framework -87p/3f
** sensors -(compilation problem)

* Basic Feature Testing(build 1.1.90.8.20110322.2)
** Ubuntu 10.10
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
** Fedora 13
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
*** Netbook image -11p/0f
*** Handset qemu -13p/2f(failed on [https://bugs.meego.com/show_bug.cgi?id=14874 #14874])
*** Handset Sysroot -27p/0f
**Critical bugs pending: [[https://bugs.meego.com/show_bug.cgi?id=12865 #12865], [https://bugs.meego.com/show_bug.cgi?id=14529 #14529], [https://bugs.meego.com/show_bug.cgi?id=14897 #14897], [https://bugs.meego.com/show_bug.cgi?id=14893 #14893], [https://bugs.meego.com/show_bug.cgi?id=13007 #13007], [https://bugs.meego.com/show_bug.cgi?id=13832 #13832], [https://bugs.meego.com/show_bug.cgi?id=11607 #11607], [https://bugs.meego.com/show_bug.cgi?id=12073 #12073], [https://bugs.meego.com/show_bug.cgi?id=12085 #12085], [https://bugs.meego.com/show_bug.cgi?id=13943 #13943], [https://bugs.meego.com/show_bug.cgi?id=9790 #9790]]

* Total Bug Count(368)
** Critical - New:5 ,NeedInfo:1 ,Assigned:4 ,Waiting for upstream:0 ,Reopened:1 , Resolved:11 ,Released:0 ,Verified:19 ,Closed:0
** Major - New:10 ,NeedInfo:1 ,Assigned:3 ,Waiting for upstream:0 ,Reopened:1 , Resolved:11 ,Released:0 ,Verified:19 ,Closed:0
** Normal - New:101 ,NeedInfo:3 ,Assigned:29 ,Waiting for upstream:1 ,Reopened:6 , Resolved:49 ,Released:16 ,Verified:44 ,Closed:4
** Trivial - New:3 ,NeedInfo:0 ,Assigned:0 ,Waiting for upstream:0 ,Reopened:0 , Resolved:1 ,Released:1 ,Verified:3 ,Closed:0
** Enhancement - New:5 ,NeedInfo:0 ,Assigned:0 ,Waiting for upstream:0 ,Reopened:0 , Resolved:1 ,Released:1 ,Verified:3 ,Closed:0

* Test transition is still in progress.
* Review test cases on tl (BMC#12536)
* Formalize bug handling workflow

SDK/Meetings/20110330 Weekly

2011-03-30T12:07:36Z

Ionutgavaz: /* QA (Juha) */

= MeeGo SDK Weekly Meeting 20110330 =

This document contains agenda and minutes (added after the meeting) of SDK weekly telco meeting on 20110330 14:00 GMT.

== Conventions of this document ==

* AP: = Action point agreed on this meeting
* yyyymmdd AP: = Action point agreed on previous meeting
* yyyymmdd AP yyymmdd: = Action point agreed on previous meeting with a deadline
* yyyymmdd AP DONE: = Action point done
* yyyymmdd AP CANCELLED: = Action point cancelled
* AGREE: = Item that has been agreed by the team
* POSTPONED: = Agenda item postponed from last meeting
* OLD: = Info from previous meeting (delete during the meeting)

== Attendees ==

*

== Agenda ==

=== SDK Program (Veli) ===

* Nokia changes...

==== Features (Ville) ====

=== Architecture (Bob) ===

(Meetings held weekly, as needed)

* http://wiki.meego.com/SDK/Architecture

Topics for future meetings:
* How to speed up MeeGo SDK
** Install (reduce size, target/sysroot management)
** Deploy/debug (QEMU acceleration, deploy w/o packaging, etc)
* rsync: Using QEMU files for sysroot
** http://wiki.meego.com/SDK/Sysroot_extension
* Release process (discussion started)
* Windows builds (server - http://bugs.meego.com/show_bug.cgi?id=11762, process)
* How to identify the installed MeeGo SDK version (registry key, file, gconf)

Covered in past weeks (Resolutions here: http://piratepad.net/qqICWdiYLl )
* Thurs 20th Meeting
** Package group - list of devel packages in sysroot
*** Study on http://wiki.meego.com/SDK/Packages_group
** Qt Creator rc1 promotion and QA

* Thurs 13th Meeting
** Accomodate 3rd party libraries in addition to sysroot on Windows and Linux
** Feature 10949 - [FEA] Make the installation of MeeGo SDK for Linux easier http://bugs.meego.com/show_bug.cgi?id=10949

** AP: Add minutes to: http://wiki.meego.com/SDK/Meetings (Bob) DONE.

=== Releasing (Fathi) ===

* hardfp toolchain into MeeGo Trunk
** SDK toolchain to update/promote
** AP: ks files to update - new images (Fathi)
** AP: update madde configuration for ARM toolchain (Fathi)
* Full toolchain upgrade to 1.2 is on the way for all architectures IA32/ARM softfp and hardfp
** Pending windows toolchain integrated - Windows SDK is using 1.1 toolchains
* AP: Qt Simulator to review and promote (Fathi)

=== Windows port (Max) ===

* Still using 1.1 toolchains
* AP: Upgrade to 1.2 toolchains Wenchao and Max on that. - 1.2 toolchain will be released with Preview 6 next Monday
** AP: ARM hardfp toolchain should be provided by Al
* AP: Update to latest Qt/Qt Creator - Qt Creator 2.1 will be released with Preview 6 next Monday
* AP: Al to create a wiki page about the windows build server

=== Mac OS X port (David) ===

* David was not present

=== Toolchains (JuhaK) ===

* Toolchain meetings biweekly (http://wiki.meego.com/SDK/Toolchains/Meetings#MeeGo_Toolchain_Project_Meetings)
* AP: set up a wiki page in meego.com for following the performance/regression testing of toolchain
** This AP is pending because I haven't had time to do it. Target: next week
* glibc 2.12 or newer cannot be built with arm and this needs to be solved - I'm testing a patch right now, but building gcc for i586 seems to have failed this time. I hope to get a solution this week.

=== Documentation (Taru) ===

* Taru Laine is the doc team lead.
* Weekly documentation telco meetings were restarted on March 3. This week's agenda is here: http://wiki.meego.com/SDK/Documentation/MeetingMinutes/20110324#Agenda
* Documentation backlog for MeeGo 1.2 SDK can be found here: http://wiki.meego.com/Documentation_Backlog_for_MeeGo_1.2
** Bob Spencer is clarifying the resources available for tasks that do not have owners at the moment.
* Open questions regarding DMC publishing site:
** What type of documentation should be published through DMC and updated according to release lifecycle?
** What type of documentation should be kept in Wiki for continuous updates?
** Who will take up the main role of developing the site and coordinating the process of content creation/transfer on DMC site?
* SDK feature status and its impacts on documentation (e.g. devices supported by MeeGo 1.2 SDK)

=== QA (Juha) ===

* All QA reports at http://qa-reports.meego.com/
* Feature status :
** Released :
*** total 1
*** test case exists 0
** Resolved :
*** total 13
*** test case exists 7
** Accepted :
*** 76 for 1.2 (total 107)
*** test case exists 12 for 1.2
* Testing
** Testing done last week for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.90.8.20110322.2/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.90.8.20110322.2]] on Ubuntu 10.10 32bit and Fedora13 32bit.
*** Results updated to http://qa-reports.meego.com/1.2/Sdk/Basic%20Feature%20Testing/N900 .
*** Still valid bugs on both distros : [[https://bugs.meego.com/show_bug.cgi?id=12335 #12335]], [[https://bugs.meego.com/show_bug.cgi?id=12561 #12561]], [[https://bugs.meego.com/show_bug.cgi?id=12820 #12820]], [[https://bugs.meego.com/show_bug.cgi?id=12853 #12853]], [[https://bugs.meego.com/show_bug.cgi?id=13399 #13399]], [[https://bugs.meego.com/show_bug.cgi?id=13831 #13831]], [[https://bugs.meego.com/show_bug.cgi?id=14171 #14171]]
** Testing started for [[http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110329.5/images/meego-core-armv7l-madde-sysroot/ meego-core-armv7l-madde-sysroot-1.1.99.0.20110329.5]] on Ubuntu 10.10 32bit and Fedora13 32bit.

* Mobility API quality
** Accounts -50p/4f
** QFeedBack -14p/6f
** Multimedia -294p/5f
** Gallery -130p/0f
** Location -191p/20f
** Message -187p/62f
** publish&subscribe -23p/9f
** Contacts -369p/2f
** Versit&organizer -111p/2f
** signon -85p/14f
** QMsystem -143p/21f
** qsparql -141p/5f
** systeminfo -83p/6f
** resourcepolicy -96p/0f
** service framework -87p/3f
** sensors -(compilation problem)

* Basic Feature Testing(build 1.1.90.8.20110322.2)
** Ubuntu 10.10
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
** Fedora 13
*** Netbook qemu -11p/0f
*** Netbook sysroot -25p/0f
*** Netbook image -11p/0f
*** Handset qemu -13p/2f(failed on [https://bugs.meego.com/show_bug.cgi?id=14874 #14874])
*** Handset Sysroot -27p/0f
**Critical bugs pending: [[https://bugs.meego.com/show_bug.cgi?id=12865 #12865], [https://bugs.meego.com/show_bug.cgi?id=14529 #14529], [https://bugs.meego.com/show_bug.cgi?id=14897 #14897], [https://bugs.meego.com/show_bug.cgi?id=14893 #14893], [https://bugs.meego.com/show_bug.cgi?id=13007 #13007], [https://bugs.meego.com/show_bug.cgi?id=13832 #13832], [https://bugs.meego.com/show_bug.cgi?id=11607 #11607], [https://bugs.meego.com/show_bug.cgi?id=12073 #12073], [https://bugs.meego.com/show_bug.cgi?id=12085 #12085], [https://bugs.meego.com/show_bug.cgi?id=13943 #13943], [https://bugs.meego.com/show_bug.cgi?id=9790 #9790]]

* Test transition is still in progress.
* Review test cases on tl (BMC#12536)
* Formalize bug handling workflow

SDK/QA/MeetingMinutes/20110322

2011-03-22T15:08:10Z

Ionutgavaz: Created page with "*Attendees: Arcadie, Alex, Ionut,Andreea, Juha *APs: ** AP1: Juha - set the following features to "Verified":9961 and 9461 ** AP2: Juha - verify 9446 ** AP3: Alex - verify 11679 …"

*Attendees: Arcadie, Alex, Ionut,Andreea, Juha
*APs:
** AP1: Juha - set the following features to "Verified":9961 and 9461
** AP2: Juha - verify 9446
** AP3: Alex - verify 11679
** AP4: Ionut - update the QA meeting minutes on wiki starting today and check out the Bugzilla rights needed to verify/close features

SDK/QA

2011-03-22T14:59:28Z

Ionutgavaz: /* Meeting Minutes */

= 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
* Ionut Gavaz -- 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 @ [[SDKTestPlan|SDK Test Plan]]

== Test Report ==
*[http://qa-reports.meego.com/ MeeGo SDK Test Reports]

== Meeting ==
* When: Every Tuesday at 11:00~12:00 (UTC+2).
* Sharing point during the meeting: http://piratepad.net/MXIM107LUe

=== 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]]