WORK IN PROGRESS - please contribute by editing this page or posting your comments on discussion area for this page.
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>|
for QA/Quality/Testing related glossary, please refer to http://wiki.meego.com/Quality/Glossary
for other glossary used in the test plan, this section will provide the definitions to properly interpret them
|<please add term here: e.g. SMS>||<please add definition here: e.g. Short Message Service>|
Expect a short paragraph to describe the component and add link for further information about this component.
(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
(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:
(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.
If you adopt any specific test methodology to the component test, please give the summary and provide enough information of the methodology.
Describe how you will use the different test types for the component, considering adopting the following test types while test design:
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
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
Describe test automation approach, following contents are suggested
Adopting the test approach above to the component, define test points or design detailed test cases.
This section shall identify everything needed to do the testing except the software itself.
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|
Any tools required during testing or test development?
This section lists any risks and limitations that may affect the design, development or implementation of testing.
email@example.com , ...
place the reference here