Meego Wiki
Views

Quality/Plans/Testability-checklist

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(Testability Checklist)
(wording, + transform to questions + wikify Quality Assurance Team)
Line 1: Line 1:
== Introduction ==
== Introduction ==
-
Testability checklist is intended to be used when quality assurance is ensuring testability of planned features forming MeeGo software release content.  
+
The 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.  
+
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 tested according to its original intent properly.
+
Without proper testability checking of feature(s) [[Quality Assurance Team|Quality Assurance]] can't quarantee that defined feature(s) is/are tested according to its original intent properly.
== Testability Checklist ==
== Testability Checklist ==
-
* Is it located in correct place in requirement management tool (according to guidelines, otherwise it can't be found)
+
* Is it located in the correct place in the requirement management tool (according to guidelines, otherwise it can't be found)?
-
* Is feature tagged to relevant MeeGo release
+
* Is the feature tagged to the relevant MeeGo release?
-
* Is it testable from UX / MeeGo API / MW IF, if not then development testing
+
* 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
+
** 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
+
*** 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
*** Reference to API documentation of API(s) implementing features. Location where more information is available
-
* Is naming of feature understandable
+
* Is naming of feature understandable?
-
* Is description in place and understandable so that test cases can be designed based on it
+
* 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 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)
+
* Are there features missing for key usage model(s)?
-
* Is there existing Non-Functional Requirement (NFR)
+
* Is there existing a Non-Functional Requirement (NFR)?
-
* Are NFR parameters in place (NFR type, target value with test data information and measurement points)
+
* Are NFR parameters in place (NFR type, target value with test data information and measurement points)?
== Notes ==
== 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.
+
* 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.
* Target is to ensure that there is no coverage gaps in test cases against features.

Revision as of 18:13, 9 June 2010

Introduction

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.

Testability Checklist

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

Notes

  • 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.
Personal tools