Meego Wiki
Views

Quality/Testability-commenting

From MeeGo wiki
< Quality
Revision as of 11:17, 15 November 2010 by Mahalmag (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Introduction

In the past, a QA contact marked a feature with a yes/no statement and a checklist. This does not add any useful information to the process and provides little useful feedback for the feature owner. The objective of this document is to lay down guidelines for feature testability comments that will allow for discussion about test development with the feature owner.

The Big Picture

As an overall view, the comment a QA Contact makes on the testability of a feature should contain the following:

  • Testability Analysis (with justification, if required).
  • Test Name and/or description with a short description of how the test would test the feature.

Testability Analysis

The testability checklist can be found here: Feature Testability Checklist The QA Contact should analyze the feature description and compare it to the requirements of the Testability Checklist. A yes/no verdict should be supplied, and, (especially if the verdict is no) a justification should be provided for the verdict. If the feature cannot be tested, suggesting a method to rectify the situation is strongly suggested.

Theoretical Test

In general, the person who would know how best to test a feature is the feature developer themselves. The suggested way to get their input about the feature and have the information easily accessible is to suggest a test while commenting on the testability.

The suggested test can consist of a name and/or a test description.

By suggesting a test to the feature developer, the barriers for participating in the test development process are lowered. While the test developer may not have time or be inclined to describe a test on their own, if a test is suggested, they can easily comment on the suggested test. This makes it easier to catch a misinterpretation of the feature in an early stage, and can allow for better, more complete, tests.

Feature Verification

By suggesting a test (especially with a test case name), feature verification will be easier as all the information required for feature verification is already present in the feature bugzilla.

Conclusion

By allowing a little more time for testability studies, feature owners/developers can be provided with a clear view on the testing of their feature. This can help avoid misunderstandings with regard to feature functions and can make feature verification easier.

Personal tools