Extras-testing/QA checklist

(→Lack of bug reporting database)
Line 1: Line 1:
-
== Community Quality Assurance ==
+
'''The software hosted in [[Extras-testing]] is not be ready for ordinary users!'''  
-
Offering good quality community software to owners of Maemo devices is a top priority. We have a chance to show the world that open source software developed by community projects can match commercial software in terms of features, usability, reliability and fun. But we also face the risk of getting maemo.org Extras associated with beta quality software made by geeks for geeks only, without the last mile of polishing.
+
This testing software may put your tablet in an unresponsive state and may require flashing.  
-
 
+
Please don't download software from extras-testing if you haven't backed up your data or are prepared to re-flash your device.
-
This is why we have put a community QA process in place in order to help developers to get their software ready for end users. Free community certification for free software.
+
-
 
+
-
You can help improve this QA process. Feel free to check the [[Talk:Extras-testing/QA_Checklist|discussion page]] and the [http://talk.maemo.org/showthread.php?t=33317 Talk discussion thread].
+
-
 
+
-
== How it works in practice ==
+
-
Developers upload their software to extras-devel, the unstable repository. extras-devel is where anything can break and where no end users are expected unless they know perfectly well what they are doing. When the developer of an application thinks that it's ready for the masses, he or she promotes it to extras-testing. There is a series of automatic tests to filter the jump from extras-devel to extras-testing already. If everything is ok, the application ends up in extras-testing, and from that point it will be subject to a human evaluation.
+
-
 
+
-
=== The extras-testing QA queue & you ===
+
-
The list of applications waiting to be evaluated in extras-testing can be found at http://maemo.org/packages/repository/qa/fremantle_extras-testing/ . They are sorted by age: the first application is the oldest in the extras-testing queue and the last is the youngest. When a developer sends a new version of an application the old version disappears from the list and the new one is located at the end of the list.
+
-
 
+
-
There are three basic types of beta testers:
+
-
* The ones that concentrate on the applications on top of the list (the apps that have been longest in the queue). Do this unless you have a better agenda. It is important to give feedback to developers soon. Either they get their software approved to Extras or they get bad reports so work on a new version in extras-devel.
+
-
* The ones that concentrate on the applications they regularly use. By following this path you become an expert in specific applications, able to evaluate new releases quickly and get involved in the project as a regular.
+
-
* The ones that concentrate on a type of testing. Some prefer to check that the features work and there are no crashes. Others might prefer to look at performance or power management metrics. Testing is a complex activity and nobody is expected to be an expert in all fields.
+
-
 
+
-
=== Report soon, report often ===
+
-
Testing a specific version of an application thoroughly takes time, and most of us are busy. This is why you are encouraged to handle testing in chunks, testing a specific aspect of one application and reporting back to the page where the evaluations are made. If you report that the content of ExampleApp is correct (something that took you only ten minutes to check), then someone else after you can concentrate on something else. Ten people can look at one thing each, instead of ten people each having to go through the ten things.
+
-
 
+
-
=== One after another ===
+
-
If you are testing aspects like power management and system stability it is recommended that you install and try out applications one by one (this is a good idea for all users anyway). If you install many applications at once then it will be difficult to find out which one is causing trouble.
+
-
 
+
-
Below you have a modular checklist to help you evaluate apps soon and often.
+
-
 
+
-
==The checklist==
+
There are several elements to be considered by developers before promoting software to extras-testing. The same criteria are useful for beta testers before approving applications to go to Extras. Please take your time looking at them. Don't evaluate an application lightly! If you are busy or in a hurry just let others do the job.
There are several elements to be considered by developers before promoting software to extras-testing. The same criteria are useful for beta testers before approving applications to go to Extras. Please take your time looking at them. Don't evaluate an application lightly! If you are busy or in a hurry just let others do the job.

Revision as of 06:27, 27 October 2009

The software hosted in Extras-testing is not be ready for ordinary users! 
This testing software may put your tablet in an unresponsive state and may require flashing. 
Please don't download software from extras-testing if you haven't backed up your data or are prepared to re-flash your device.

There are several elements to be considered by developers before promoting software to extras-testing. The same criteria are useful for beta testers before approving applications to go to Extras. Please take your time looking at them. Don't evaluate an application lightly! If you are busy or in a hurry just let others do the job.

Please check the points of this list. Don't rush to give thumbs up to an application before it is tested. But don't try to delay the release of an app with minor bugs or enhancement proposals separate from this discrete QA checklist.

Contents

Blockers

If one of these criteria is not met, the application cannot go into Extras. A Critical bug at http://bugs.maemo.org/ against the application is required to justify your thumbs down.

Lack of bug reporting database

http://bugs.maemo.org/ is the preferred option. Otherwise it needs to be identified in the http://maemo.org/packages/ page.

Developers: filling the XSBC-Bugtracker field in your packages address this problem (((FIXME: link to documentation?))). Check this wiki page to get your bugtracker at bugs.maemo.org.

Legal issues

Evident licensing problems or copyright violation. The open source licenses need to be compliant. It needs to be clear that the product is not officially supported by Nokia, Maemo or other commercial entities and trademarks.

Missing announced features

Core features advertised through UI or product page don't work or are missing.

Illegal or dubious content

For the avoidance of doubt, the content must not depict explicit sexual activity; depict or endorse acts that cause or are intended to cause excessive pain or suffering; promote or endorse the misuse of alcohol, tobacco, illegal drugs or other addictive substances; promote intolerance or discrimination based on racial, political, ethnic, religious, gender or sexuality; promote invasion of rights of privacy; promote gambling or promote illegal activity.

Reproducible crashes

You can provide a list of steps that lead to an application crash.

System performance compromised

Running the application visibly affects the performance and responsiveness of the system, either through specific actions or leaving the application open/running during a long period of time.

Too much memory used in root partition

The application or its dependencies ignore the recommendation to use the eMMC to install as much files as possible, filling the root partition with 500kb or more.

dpkg -L packagename shows all files installed by a package. Also see Opt Problem.

Power management issues

Battery life is diminished beyond acceptable standards by having the application running in the background or just through normal use. The use case of a full day without charging shouldn't be compromised.

If specific applications are explicitly using a lot of power to boost speed or performance (for instance games, Wi-Fi heavy apps) then they must warn the user explicitly with a first boot banner.

Security risks

The main security risks are financial damage, access to private data and harm to device components. If you find such risk in an application then you need to report it and the app can't be uploaded to Extras until a deeper analysis has been done with favourable results.

Warnings

If one of these criteria is not met, the developers will be asked to fix them urgently. Still, the app can make it slowly to Extras unless a blocker is raised.

  • Details at http://maemo.org/packages/ are missing or incomplete: summary, URL to project, updates info.
  • Application icon missing or not visible in the device. This is only optional for command-line applications.

Testers with good technical knowledge are invited to look deeper in the Maemo Quality considerations (((waiting for Fremantle update))) in order to find weak points in applications waiting to be promoted.

Non-blockers

The extras-testing QA process shouldn't be used to delay the release of new applications and updates with minor/normal bugs or enhancement requests. These can be filed as bugs just as usual.

  • Developers are encouraged to adopt the Maemo 5 UI guidelines and optimize their application to finger use. However, lack of Maemo 5 UI optimization is not a reason to block an application in its way to Extras unless it is unusable even with stylus.
  • Maemo 5 offers stock icons covering most regular use cases, but developers can use the icons they prefer as long as they respect copyrights. Broken icons can be a major bug stopping a release to Extras but discussions about beauty/ugliness of a UI are out of scope in the QA process.
Retrieved from "http://wiki.maemo.org/Extras-testing/QA_checklist"