Revision as of 03:30, 26 May 2011 (view source) Elvafu (Talk | contribs) (→Glossary) ← Older edit		Revision as of 02:15, 27 May 2011 (view source) Elvafu (Talk | contribs) (→Glossary) Newer edit →
Line 24:		Line 24:
	|''<please add term here>''|| ''<please add definition here> ''		|''<please add term here>''|| ''<please add definition here> ''
	|}		|}
		+
		+	''for QA/Quality/Testing related glossary, please refer to http://wiki.meego.com/Quality/Glossary ''
	== Component Summary ==		== Component Summary ==

---

Revision as of 02:15, 27 May 2011

WORK IN PROGRESS - please contribute by editing this page or posting your comments on discussion area for this page.

Contents 1 <Component Name> Test Plan 1.1 Revision History 1.2 Glossary 1.3 Component Summary 1.4 Feature to be Tested 1.5 Feature not to be Tested 1.6 Test Strategy and Approach 1.6.1 Test Automation 1.7 Test Design 1.8 Test Environment 1.8.1 Hardware Platforms 1.8.2 Tools 1.9 Risks/Limitations 1.10 QA Contact 1.11 Developers 1.12 References

<Component Name> Test Plan

Revision History

Provide a complete list of modification records for the test plan.

Vision	Date	Author	Reason for Changes
<please add version here>	<please add date here>	<please add author here>	<please add reason for changes here>

Glossary

Provide the definitions of all terms, acronyms and abbreviations required to properly interpret within the test plan.

Term	Definition
<please add term here>	<please add definition here>

for QA/Quality/Testing related glossary, please refer to http://wiki.meego.com/Quality/Glossary

Component Summary

Expect a short paragraph to describe the component and add link for further information about this component.

Feature to be Tested

(WHAT TO TEST)

List all of the features for this component

Assign a test priority to each feature, and add comments describing why you give the feature the assigned priority. This will require some risk analysis. Here Priority considerations are user impact, potential bug and test complexity.

P1– User impact big, potential to have more bugs, or complexity of test

P2 – User impact small, potential bug or test complexity is low

Feature not to be Tested

(WHAT NOT TO TEST)

Identify any significant software features or other items that will not be tested. If necessary, explain why these items are not addressed by this test plan. Identify WHY the item is not to be tested. This could include such reasons as:

• Not to be included in this release of the Software.
• Low risk, has been used before and is considered stable.
• Will be released but not tested or documented as a functional part of the release of this version of the software.
• Third-party features or components that will not be tested by our team.
• Software features will be tested by other teams.
• Documentation or legal requirements.

Test Strategy and Approach

(HOW YOU WILL TEST THE COMPONENT)

Specify refinements to the approach described in the project/product test plan. Include specific test techniques (test methodology, test framework, automation, test type, test level...) to be used.

Test Methodology:

If you adopt any specific test methodology to the component test, please give the summary and provide enough information of the methodology.

Test Types:

Describe how you will use the different test types for the component, considering adopting the following test types while test design:

• Feature Functional Test (positive, negative, internationalization and localization, ...)
• GUI Test if the component has GUI, validate if the implementation conforms to UI design.
• Stress Test to guarantee the reliability
• Performance Test

Test level:

Describe the test level (API level test, integration test, test from UI, system functional test, and so on) for the different sub-components, test level will reflect the test priority of features. Test the high priority items extensively, medium priority items broadly, and the low-priority cursory.

If certain areas or aspects of the system imply high risks for the product, then more thorough testing is obviously a solution. Focus testing effort on portions of the software where risk of potential failure is greatest or where potential failure would be most catastrophic

Flexibility:

Adjust your strategy if it produces an amount of necessary test effort or a time schedule that does not fit testing goals or project constraints

Test Automation

Describe test automation approach, following contents are suggested

• Which part of tests will be automated.
• Automation goal, automation percentage
• Follow the overall test automation strategy in project overall test plan
• The whole automated test suite low level design which is used for guiding implementation. If need, create dedicated doc for it.
• Test framework, test automation tools used
• Test automation environment, including hardware, peripherals, software configuration and etc
• Programming language, code style and etc

Test Design

Adopting the test approach above to the component, define test points or design detailed test cases.

Test Environment

This section shall identify everything needed to do the testing except the software itself.

Hardware Platforms

Target test platforms (url of hardware wiki page if have), networking environment, peripherals, test and measurement equipment, and etc

Test Platforms	Networking	Other Devices	Priority
Pinetrail Netbook: HP mini 210	Lan, Wifi (WPA)	BT earphone, usb disk, usb key, power meter, ...	P1
Diamondville Netbook: Acer Airespone One D150	Lan, Wifi (WPA)	BT earphone, usb disk, usb key, power meter, ...	P2

Tools

Any tools required during testing or test development?

Risks/Limitations

This subsection lists any risks and limitations that may affect the design, development or implementation of testing.

QA Contact

foobar@intel.com

Developers

foobar@intel.com , ...

References

place the reference here