| Line 1: | Line 1: | ||
= QA TODOs = | = QA TODOs = | ||
| - | == | + | == OTS setup and automated hourly testing == |
| - | * OTS server | + | |
| - | * OTS worker(s) for core tests | + | === OTS setup === |
| - | * OTS worker for UX tests | + | * OTS server - DONE |
| + | * OTS worker(s) for core tests - DONE (2 workers up) | ||
| + | * OTS worker for UX tests | ||
* Power consumption measurements | * Power consumption measurements | ||
* Reporting to QA-reports | * Reporting to QA-reports | ||
* Minimize automatic installation time | * Minimize automatic installation time | ||
| - | == | + | === Test automation images === |
| + | * Setup image building for autotest image on own setup (maybe later with BOSS) | ||
| + | * We need to be able to control included test packages | ||
| + | |||
| + | If you need something else from QA please tell it to us :) | ||
| + | |||
| + | == Applications for testing == | ||
* Package QML demo/example applications from http://doc.qt.nokia.com/latest/qdeclarativeexamples.html | * Package QML demo/example applications from http://doc.qt.nokia.com/latest/qdeclarativeexamples.html | ||
| - | == | + | == Test asset == |
* Define what the asset includes | * Define what the asset includes | ||
* Automating as many core/ux tests as possible | * Automating as many core/ux tests as possible | ||
* Call/SMS cases will require parallel test execution support (If we want to automate those kind of tests) | * Call/SMS cases will require parallel test execution support (If we want to automate those kind of tests) | ||
| - | == | + | == Test Execution Schedule == |
* Core | * Core | ||
| Line 89: | Line 97: | ||
|} | |} | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
== Crashdb support for ARM core dumps == | == Crashdb support for ARM core dumps == | ||
Contents |
If you need something else from QA please tell it to us :)
| Day | Test set (status) | Release |
|---|---|---|
| Monday | Key feature (OK) | Preview |
| Monday | Acceptance (OK) | Testing trunk |
| Tuesday | Acceptance (Ok) | Testing trunk |
| Tuesday | Sanity (Ok) | Daily trunk |
| Tuesday | DE Dataflow (Ok) | Preview |
| Tuesday | DE use cases (Ok) | Preview |
| Wednesday | Acceptance (Ok) | Testing trunk |
| Wednesday | Key feature (Ok) | Weekly |
| Thursday | DE Dataflow (Ok) | Weekly |
| Thursday | DE use cases (Ok) | Weekly |
| Thursday | Acceptance (Ok) | Testing trunk |
| Thursday | Sanity Ok | Daily trunk |
| Thursday | DE Reliability (Ongoing) | Weekly |
| Thursday | DE Performance (Ongoing) | Weekly |
| Friday | Acceptance (Ok) | Testing trunk |
| Friday | Sanity (Ok) | Daily trunk |
Core dump processing and backtraces from crashing ARM processes.
There is a wiki article about the Developer Edition.
QA tasks for the Developer Edition differ from the usual N900 approach in that there are less features to be tested. There are currently 2 test sets for the Developer Edition, these are the Sanity Test Set and the Feature Test Set. They are described below.
The sanity set should be run automatically on every image. As such it must meet the following requirements:
The feature set will be run periodically and will test the basic features as well as enablers for those features (e.g. PIM for phoning contacts). Performance will also be analysed, at the moment, this will include browser startup time and a CPU benchmark but this will be expanded later.
Suggestions are welcome.