For a previous version of the Testability Checklist, see: http://wiki.meego.com/Quality/Testability_checklist_MeeGo_1.1
User stories are a simple method to describe features, thus, they should be simple to write and to understand. By writing user stories to the features in Bugzilla, features can contain sufficient information to make test development possible without increasing the workload of the feature owner (as much as the "MeeGo 1.1 Testability Checklist"). The testability checklist used for MeeGo 1.1 contained items that were related to the process of feature creation which should be self evident and not be included in testability checklist.
The most effective way to create testable features from QA point of view is to write or user stories. The objective of writing user stories is to explain the feature to the extent that a test to verify the feature can be written. To that end, after writing a user story, ask yourself this question:
Can someone write a test using the information in this user story?
If the answer is 'yes' then the user story is complete, if the answer is 'no', then it may be worth it to consider rewriting the user story or (if this seems like it will not help) add extra information (see the extra information section).
Some of the use case may not be fully applicable for Core OS QA but in most of the cases use cases can be divided to smaller particles and can be considered as enablers for use case. E.g. Browsing use case can be verified using these smaller particles (enablers) as follows:
There is a good wikipedia article on the concept of the user story here. While there are some differences from the article because MeeGo is not a small project that is being implemented by one team.
Three basic forms for a User Story are:
It is important to define the goal clearly. This allows the success criteria of the test to be clearly defined.
It is also important to define the set of actions leading up to the goal clearly. For example, if the user needs to tilt the device from horizontal to vertical for an action to occur, this needs to be described.
The following feature can be found here and can be considered a good example of a user story:
User is browsing multimedia content in browser and a system event triggers a sound, e.g. battery low or alarm. System sound is mixed in with the browser audio.
We can see in this example:
From the above description, a test can be written.
The basic concept of user stories does not usually include the provision for extra information. This is usually not a problem for a single, coherent, project. In a project with as many components (from as many sources) as MeeGo, extra information may be required.
NOTE: Adding extra information is not a requirement, if your feature is adequately described by the story itself, then, stop there.
Some suggestions on what extra information to add:
Even though Testability Checklist is tool for QA teams, persons creating features in Bugzilla should have a thorough look to this in order to make feature flow fluently. Testability Checklist contains mandatory parts (to fulfill the criteria to have Testability marked as YES) and optional part which is recommended for one creating features to consider seriously if there is such information available that will help QA teams to conduct their work at appropriate level, leading well tested MeeGo features and Releases.
By creating user stories for each feature, the feature owner can avoid having to write a "Testability Checklist" as was required for MeeGo 1.1. Adequately written user stories should make life easier for both the product owner and the test developer.
-- Main.MarkHalmagiu - 28 Sep 2010