Quality/Plans/Testability-checklist

Revision as of 05:36, 7 June 2010

Introduction

Testability checklist is intended to be used when quality assurance is ensuring testability of planned features forming MeeGo software release content. Based on testability checklist feedback is given directly to person who has defined feature and its content description. Without proper testability checking of feature(s) Quality Assurance can't quarantee that defined feature(s) is tested according to its original intent properly.

Testability Checklist

• Is it located in correct place in requirement management tool (according to guidelines, otherwise it can't be found)
• Is feature tagged to relevant MeeGo release
• Is it testable from UX / MeeGo API / MW IF, if not then development testing
  • If feature is testable at MeeGo API or MW IF then following information should be available for feature
    • API or API's implementing the feature. List of API's and/or components implementing the feature
    • Reference to API documentation of API(s) implementing features. Location where more information is available
• Is naming of feature understandable
• Is description in place and understandable so that test cases can be designed based on it
• Are relevant technology parameters available (especially if related to multimedia, e.g. Scenario local audio playback, Codec: MP3 decoder, Profile/Level/Version: MPEG-1 Layer 3, Sampling Frequency (kHz): 48kHz, Bit rates (Kbps): 384 kbit/s, Channels: Up to Stereo)
• Is there features missing for key usage model(s)
• Is there existing Non-Functional Requirement (NFR)
• Are NFR parameters in place (NFR type, target value with test data information and measurement points)

Notes

• Testability shall be checked for every feature for UX, MeeGo API, MF IF levels. If feature is not testable e.g. MeeGo API nor MW IF then it shall be pointed to UX.
• Target is to ensure that there is no coverage gaps in test cases against features.