This is outdated. Find the latest version here.
The testability checklist is intended to be used when quality assurance is ensuring testability of planned features forming MeeGo software release content.
Based on the testability checklist feedback is given directly to persons who have defined features and its content description.
Without proper testability checking of feature(s) Quality Assurance can't quarantee that defined feature(s) is/are tested according to its original intent properly.
- Is it located in the correct place in the requirement management tool (according to guidelines, otherwise it can't be found)?
- Is the feature tagged to the 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 a 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)?
- Are there features missing for key usage model(s)?
- Is there existing a Non-Functional Requirement (NFR)?
- Are NFR parameters in place (NFR type, target value with test data information and measurement points)?
- Testability shall be checked for every feature for UX, MeeGo API, MF IF levels. If a 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.