Meego Wiki
From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(Projects)
(Projects)
 
(37 intermediate revisions not shown)
Line 3: Line 3:
This page is for MeeGo Quality Assurance related material.
This page is for MeeGo Quality Assurance related material.
 +
== Getting Started ==
 +
* [[Quality/Getting started|How Can I Contribute]]
== Projects ==
== Projects ==
Line 21: Line 23:
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.3/Core Core Test Reports]
* [http://qa-reports.meego.com/1.3/Core Core Test Reports]
-
* [http://wiki.meego.com/Quality/CoreQualityMetrics Quality Metrics]
+
* [[Quality/CoreQualityMetrics | Quality Metrics]]
 +
* [[/meego core feature/1.3 | Core Requirements]]
|  
|  
* [[Quality/Plans/Handset UX test plan|MeeGo HandSet UX Test Plan]]
* [[Quality/Plans/Handset UX test plan|MeeGo HandSet UX Test Plan]]
-
* [[Quality/TestSuite/handset-test-suite|Test Suite]]
+
* [http://meego.gitorious.org/meego-quality-assurance/handset-ux-tests Test Suite]
* [http://qa-reports.meego.com/1.3/Handset Handset Test Reports]
* [http://qa-reports.meego.com/1.3/Handset Handset Test Reports]
|
|
Line 39: Line 42:
* [http://qa-reports.meego.com/1.3/SDK SDK Test Reports]
* [http://qa-reports.meego.com/1.3/SDK SDK Test Reports]
|
|
-
* IVI Test Plan
+
* [[/Plans/IVI Test Plan | MeeGo IVI Test Plan]]
* IVI Test Suite
* IVI Test Suite
* [http://qa-reports.meego.com/1.3/IVI IVI Test Reports]
* [http://qa-reports.meego.com/1.3/IVI IVI Test Reports]
 +
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|-
|-
| Release 1.2
| Release 1.2
Line 48: Line 52:
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [[/TestSuite/MCTS | MeeGo Core Test Suite (MCTS)]]
* [http://qa-reports.meego.com/1.2/Core Core Test Reports]
* [http://qa-reports.meego.com/1.2/Core Core Test Reports]
-
* [http://wiki.meego.com/Quality/CoreQualityMetrics Quality Metrics]
+
* [[Quality/CoreQualityMetrics | Quality Metrics]]
|  
|  
-
* [http://wiki.meego.com/Quality/Plans/1_2_Handset_UX_test_plan MeeGo HandSet UX Test Plan]
+
* [[Quality/Plans/1_2_Handset_UX_test_plan|MeeGo HandSet UX Test Plan]]
* [[Quality/TestSuite/handset-test-suite|Test Suite]]
* [[Quality/TestSuite/handset-test-suite|Test Suite]]
* [http://qa-reports.meego.com/1.2/Handset Handset Test Reports]
* [http://qa-reports.meego.com/1.2/Handset Handset Test Reports]
Line 58: Line 62:
* Test Suite
* Test Suite
* [http://qa-reports.meego.com/1.2/Tablet Tablet Test Reports]
* [http://qa-reports.meego.com/1.2/Tablet Tablet Test Reports]
 +
* [[Quality/TabletQualityMetrics | Quality Metrics]]
|
|
-
* Test Plan
+
* [[Quality/1.2NetbookTestPlan|1.2 SW Update Test Plan]]
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [[Quality/Netbook_Test_Suite_and_Utilities|Test Suites and Utilities]]
* [http://qa-reports.meego.com/1.2/Netbook Netbook Test Reports]
* [http://qa-reports.meego.com/1.2/Netbook Netbook Test Reports]
Line 67: Line 72:
* [http://qa-reports.meego.com/1.2/SDK SDK Test Reports]
* [http://qa-reports.meego.com/1.2/SDK SDK Test Reports]
|
|
-
* Test Plan
+
* [[Quality/1.2.0_IVI_Update_Test_Plan|1.2.0 Update Test Plan]]
-
* Test Suite
+
* [[MeeGo IVI Test Suite]]
* [http://qa-reports.meego.com/1.2/IVI IVI Test Reports]
* [http://qa-reports.meego.com/1.2/IVI IVI Test Reports]
 +
* [[Quality/IVIQualityMetrics | Quality Metrics]]
|}
|}
Line 75: Line 81:
Quality assurance tools are developed to ensure MeeGo SW quality. They are developed and maintained by QA tools team.
Quality assurance tools are developed to ensure MeeGo SW quality. They are developed and maintained by QA tools team.
-
* [[Quality/QA-tools|Meet the team and find our tools]]
+
* [[Quality/QA-tools|Find our tools and contact information]]
* [[Quality/QA tools development|Participate in development activities]]. You are most welcome!
* [[Quality/QA tools development|Participate in development activities]]. You are most welcome!
Line 106: Line 112:
* [[/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]] -- WORK IN PROGRESS, please contribute
* [[/Bugtriage_Stock_Answers | MeeGo Bug Triage Stock Answers]] -- WORK IN PROGRESS, please contribute
* [[/SysDebug | MeeGo Sys-Debug]] (finding the right component for a report)
* [[/SysDebug | MeeGo Sys-Debug]] (finding the right component for a report)
 +
* [[/triageteam_assignee | Process to deal with bugs assigned to triageteam@meego.bugs]]
* [[/How_To_Report_Bugs|How to report bugs]]
* [[/How_To_Report_Bugs|How to report bugs]]
* [[/Bug_Access_Restrictions|Bug Report Access Restrictions]]
* [[/Bug_Access_Restrictions|Bug Report Access Restrictions]]
-
* [[MeeGoBugzilla_Customization|Bugzilla customized features]]
+
* [[MeeGoBugzilla_Customization|MeeGo Bugzilla Customization Features]]
-
 
+
* [https://gitorious.org/meego-bugzilla Bugzilla Codebase repository] (move not finished yet)
-
== Error Management ==
+
* [[/MeeGoBugzillaRequestProcess|How to requests changes in Bugzilla code/UI itself]]
-
See the [[Quality/Error Management]] subpage.
+
* [[/error_manager | MeeGo Error Managers]]
== Compliance Program ==
== Compliance Program ==
Line 121: Line 128:
*  IRC: Channel #meego-qa on irc.freenode.net
*  IRC: Channel #meego-qa on irc.freenode.net
-
=== Meetings ===
+
== Meetings ==
General QA Meetings are held weekly on Tuesdays 07:00 UTC in the channel #meego-meeting on irc.freenode.net. [[Quality/Meetings|Click here for more information.]]
General QA Meetings are held weekly on Tuesdays 07:00 UTC in the channel #meego-meeting on irc.freenode.net. [[Quality/Meetings|Click here for more information.]]
Line 135: Line 142:
* [[Quality/Plans/Quality-considerations|Quality Considerations / Testing Quality Characteristics]]
* [[Quality/Plans/Quality-considerations|Quality Considerations / Testing Quality Characteristics]]
** Some ideas around testing quality characteristics hopefully helping you identify what kind of things could be checked from applications - can be used as a frame to define test considerations – as a set of logical test cases - for applications targeting to run on MeeGo.
** Some ideas around testing quality characteristics hopefully helping you identify what kind of things could be checked from applications - can be used as a frame to define test considerations – as a set of logical test cases - for applications targeting to run on MeeGo.
 +
 +
== Tasks of the "QA Contact" ==
 +
 +
* QA contact work with/support/advice/help package maintainers (see [http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility|Fedora example] or [[Packaging/Guidelines#Maintaining_a_Package|MeeGo guidelines for maintaining package]]) and other users on QA related issues/questions for component in case.
 +
** Features ("Once a requirement is integrated, MeeGo QA verifies it by running the corresponding test cases." from [[https://meego.com/developers/requirements ]])
 +
*** make testability analysis for features (yes or no value to testability field) and
 +
*** identify "feature acceptance tests" together with product management and package maintainers that could be used at the end as a criteria for feature status to be changed as "VERIFIED".
 +
** Bugs ("QA Contact or Bug Submitter verifies bug fixing with the "how to re-produce" instructions in the original bug report when the bug is marked as RELEASED - FIXED." from [[Quality/Bug_Life_Cycle_and_Handling|Bug Life Cycle and Handling page]])
 +
*** facilitate the whole bug life-cycle from QA perspective, including ensure bug report completeness, follow up bugs by providing helpful or required information in timely fashion to accelerate bug fixing and verify the issue after fix is integrated, especially when the original reporter is not responsive or has difficulty to follow the bug up.
 +
*** actively follow-up the bugs. Making sure the bug is attended properly, ping the default assignee or assignee or reporter to get visibility and comments on the progress, triage bugs, verify and close them whenever possible.
[[Category:QA]]
[[Category:QA]]

Latest revision as of 03:16, 19 October 2011

Contents

Quality

This page is for MeeGo Quality Assurance related material.

Getting Started

Projects

For all test reports see http://qa-reports.meego.com

Release Core OS Handset UX Tablet UX Netbook UX SDK In Vehicle Infotainment
Release 1.3
Release 1.2

QA tools

Quality assurance tools are developed to ensure MeeGo SW quality. They are developed and maintained by QA tools team.

The following links provide some basic information on QA tools and their usage.

Procedures and best practices

Defect tracking

Compliance Program

MeeGo Compliance Program - the compliance spec (initially)

Contact

  • Mailing List: MeeGo-QA
  • IRC: Channel #meego-qa on irc.freenode.net

Meetings

General QA Meetings are held weekly on Tuesdays 07:00 UTC in the channel #meego-meeting on irc.freenode.net. Click here for more information.

QA Tools meetings are held weekly on Tuesdays 08:00 UTC in the channel #meego-meeting2 on irc.freenode.net. Click here for more information.

For information on triaging meetings for specific areas click here.

See also

Tasks of the "QA Contact"

  • QA contact work with/support/advice/help package maintainers (see example or MeeGo guidelines for maintaining package) and other users on QA related issues/questions for component in case.
    • Features ("Once a requirement is integrated, MeeGo QA verifies it by running the corresponding test cases." from [[1]])
      • make testability analysis for features (yes or no value to testability field) and
      • identify "feature acceptance tests" together with product management and package maintainers that could be used at the end as a criteria for feature status to be changed as "VERIFIED".
    • Bugs ("QA Contact or Bug Submitter verifies bug fixing with the "how to re-produce" instructions in the original bug report when the bug is marked as RELEASED - FIXED." from Bug Life Cycle and Handling page)
      • facilitate the whole bug life-cycle from QA perspective, including ensure bug report completeness, follow up bugs by providing helpful or required information in timely fashion to accelerate bug fixing and verify the issue after fix is integrated, especially when the original reporter is not responsive or has difficulty to follow the bug up.
      • actively follow-up the bugs. Making sure the bug is attended properly, ping the default assignee or assignee or reporter to get visibility and comments on the progress, triage bugs, verify and close them whenever possible.
Personal tools