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

Contents 1 Camera Test Plan 1.1 Summary 1.2 Feature to be Tested 1.3 Feature not to be Tested 1.4 Test Strategy and Approach 1.5 Test Design 1.6 Test Environment 1.6.1 Hardware Platforms 1.6.2 Tools 1.7 QA Contact 1.8 Developers 1.9 Referrences

Camera Test Plan

Summary

Camera application will make full use of the high quality camera functionality with two cameras – user-facing and outward facing equipped on MRST platform, which will make our Tablet device more competitive in the market. The camera has several advanced features such as Auto-Focus/Auto-exposure/Auto-white-balance (3A) etc... And this camera application will both include still and video capture functionality.

Camera use mrstcamsrc within modified camerabin. It can support future Qt Mobility camera API. 

OTC US team deliver UI interfaces.

Feature to be Tested

(WHAT TO TEST)

This test plan focus on OTC delivered component quality validation. So UI layer and camera-lib layer, gst-mrst-camera-src-plug-in will have top testing priority, and enter in all formal and regular testing process, which will be marked as P1. For other low level component, it depends on other upstream or third party group, possibly long time can’t upgrade quality and fix issue. So only run with low priority in testing circle(marked as P2). Once root cause issue come from this level, still track as bug and info relative owner.

According 20091113 UI wireframe design, list out key function feature and UI testing key point. Later will follow UI change to update feature list.

• Camera application UI testing(include i18n/l10n testing) P1 • Camera function testing P1 • Camera usage model testing P1 • Camera stress testing P2 • Camera negative testing P2

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:

• Functional Test (positive, negative, internationalization and localization, ...)
• Stress Test
• Performance Test

Automation:

Describe which part of tests will be automated.

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 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?

QA Contact

foobar@intel.com

Developers

foobar@intel.com , ...

Referrences

place the reference here