Views
Quality/TestDesignProcessAndGuideline
From MeeGo wiki
< Quality(Difference between revisions)
(→Analysis for Testability) |
|||
| (12 intermediate revisions not shown) | |||
| Line 4: | Line 4: | ||
* Common: | * Common: | ||
** Common test case template to be used in UX and Core. | ** Common test case template to be used in UX and Core. | ||
| - | *** | + | *** [[Quality/Test_case_template|Test case template]] |
* For UX: | * For UX: | ||
** Test cases are designed and stored to Test Link test asset management tool. | ** Test cases are designed and stored to Test Link test asset management tool. | ||
* For Core: | * For Core: | ||
| - | ** Test cases are following test packaging instructions available at: | + | ** Test cases are following test packaging instructions available at: [[Quality/QA-tools/Test packaging|Test packaging]] |
** Instances of test cases are available in Test Link test asset management tool | ** Instances of test cases are available in Test Link test asset management tool | ||
* This document describes overall test design process and guideline for MeeGo QA | * This document describes overall test design process and guideline for MeeGo QA | ||
| Line 15: | Line 15: | ||
[[File:TDPaG.jpg]] | [[File:TDPaG.jpg]] | ||
| + | |||
| + | == Features for Meego == | ||
| + | * Defined by Product Management and/or relevant stakeholder(s) | ||
| + | * Located in Bugzilla | ||
| + | * Additional material that would be useful | ||
| + | ** UI documents / UI design briefs / Visual references | ||
| + | |||
| + | == Analysis for Testability == | ||
| + | * Done by Quality Assurance Owner | ||
| + | * Checklist to be used can be found: | ||
| + | ** [[Quality|Quality Assurance Team]] or | ||
| + | ** [[Quality/Plans/Testability-checklist|Testability Checklist]] | ||
| + | * Feedback of feature testability is given directly as comment to Feature comment-field in Bugzilla. Also separate meeting between QA owner and relevant Product Manager can be arranged on need basis. | ||
| + | |||
| + | == Test Case Title(s) == | ||
| + | * Filled by Quality Assurance Owner | ||
| + | * Define TC title(s) and create coverage analysis matrix | ||
| + | ** TC title length should be less than 30 | ||
| + | ** Use ‘_’ to connect words | ||
| + | ** Title should be describing well purpose of test case | ||
| + | |||
| + | == Informal Review == | ||
| + | * Arranged by QA owner | ||
| + | * Wiki, Email and IRC to be used | ||
| + | * Participants: Feature owner, QA owner, QA CC-owner, Developer and community members | ||
| + | * Minutes are stored to <exact place to be defined later> | ||
| + | * Target is to ensure that designed TC title’s are matching to given feature in high level, target test case coverage is achievable and share information between relevant parties | ||
| + | |||
| + | == Implement Test Case(s) == | ||
| + | * Done by QA owner to Test Link (UX) or as test code and test.xml created accordingly. Test case instance in Test Link to be available in Test Link | ||
| + | * Test Case Template and its guidelines must be followed when filing Test Case Description | ||
| + | ** Link: [[Quality/Test_case_template|Test Case Template]] | ||
| + | * Note! Test Case Template must be available also directly in Test Link database for manual TC’s | ||
| + | * Design Steps | ||
| + | ** Each test step must have description and expected results defined. | ||
| + | ** Each clause should start with a capital letter and end with full stop mark. | ||
| + | ** One test step should contain only one activity. | ||
| + | ** Measurement start and end points should be clearly defined in test steps. | ||
| + | |||
| + | == Technical Review == | ||
| + | * Arranged by QA owner | ||
| + | * Wiki, Email and IRC to be used | ||
| + | * Participants: QA Owners, QA CC-owner, Developer, Test Engineer and community members | ||
| + | * Test Case(s) including design steps are reviewed from Test Link, Source Code review in need basis. | ||
| + | * TC status is marked as Proposal | ||
| + | * Target is to finalize and approve full test cases used in test execution and share information between QA owners and Test Engineers | ||
| + | |||
| + | == Test Case(s) == | ||
| + | * Test cases in place in Test Link tool and test-xml’s available | ||
| + | * Test cases are uploaded to public repositories. | ||
| + | * TC status is marked as Approved | ||
| + | * Test code available in agreed place (as development project in MeeGo.Com) | ||
| + | * Test data available in public domain <link to be added> | ||
| + | |||
| + | == Other Notes == | ||
| + | * Test Plan and Scope creation/definition is excluded from this process | ||
| + | * Model of Coverage analysis matrix: <Link to be added here when available> | ||
Latest revision as of 05:24, 24 March 2011
Contents |
Introduction
Purpose of this document is to introduce process and guideline for creating high quality test cases for common usage in MeeGo quality assurance teams.
- Common:
- Common test case template to be used in UX and Core.
- For UX:
- Test cases are designed and stored to Test Link test asset management tool.
- For Core:
- Test cases are following test packaging instructions available at: Test packaging
- Instances of test cases are available in Test Link test asset management tool
- This document describes overall test design process and guideline for MeeGo QA
Overall Test Design Process
Features for Meego
- Defined by Product Management and/or relevant stakeholder(s)
- Located in Bugzilla
- Additional material that would be useful
- UI documents / UI design briefs / Visual references
Analysis for Testability
- Done by Quality Assurance Owner
- Checklist to be used can be found:
- Feedback of feature testability is given directly as comment to Feature comment-field in Bugzilla. Also separate meeting between QA owner and relevant Product Manager can be arranged on need basis.
Test Case Title(s)
- Filled by Quality Assurance Owner
- Define TC title(s) and create coverage analysis matrix
- TC title length should be less than 30
- Use ‘_’ to connect words
- Title should be describing well purpose of test case
Informal Review
- Arranged by QA owner
- Wiki, Email and IRC to be used
- Participants: Feature owner, QA owner, QA CC-owner, Developer and community members
- Minutes are stored to <exact place to be defined later>
- Target is to ensure that designed TC title’s are matching to given feature in high level, target test case coverage is achievable and share information between relevant parties
Implement Test Case(s)
- Done by QA owner to Test Link (UX) or as test code and test.xml created accordingly. Test case instance in Test Link to be available in Test Link
- Test Case Template and its guidelines must be followed when filing Test Case Description
- Link: Test Case Template
- Note! Test Case Template must be available also directly in Test Link database for manual TC’s
- Design Steps
- Each test step must have description and expected results defined.
- Each clause should start with a capital letter and end with full stop mark.
- One test step should contain only one activity.
- Measurement start and end points should be clearly defined in test steps.
Technical Review
- Arranged by QA owner
- Wiki, Email and IRC to be used
- Participants: QA Owners, QA CC-owner, Developer, Test Engineer and community members
- Test Case(s) including design steps are reviewed from Test Link, Source Code review in need basis.
- TC status is marked as Proposal
- Target is to finalize and approve full test cases used in test execution and share information between QA owners and Test Engineers
Test Case(s)
- Test cases in place in Test Link tool and test-xml’s available
- Test cases are uploaded to public repositories.
- TC status is marked as Approved
- Test code available in agreed place (as development project in MeeGo.Com)
- Test data available in public domain <link to be added>
Other Notes
- Test Plan and Scope creation/definition is excluded from this process
- Model of Coverage analysis matrix: <Link to be added here when available>