Lately there has been some discussion in the Mer IRC channel about the
Mer’s quality assurance (QA). The purpose of the QA is to define
processes and tools for measuring and monitoring the quality of the
Mer project and its releases.

1. What is needed?

For the first we should define a testing process: when the tests are
executed and how often, where the tests are executed and what is the
test content.

I recommend that we start the QA process with testing the prelease
image on x86 chroot environment with simple test content. After this
we can expand the test content, automate the process and support other
architectures and devices. Also in the (near) future, the test
automation should be part of the review process.

2. QA Tools and tests

We can reuse many of tools and test packages which were used in MeeGo
project, like testrunner-lite, OTS, QA-Reports, test-definition,
testplanner, min etc.
Only issues is that we should move those tools which are not
maintained anymore from meego.gitorious to some other location. One
idea could be that we create own project for developing and
maintaining the QA tools. That project would offer released QA
toolchain to Mer project and Mer's vendors. And also for other

3. Infra

For the Mer QA we need some infra:
- Test result reporting (QA-Reports will be enough, will require one
virtual machine)
- Test management (Git may be enough)
- Test farm (One server and couple workers, not urgent yet)

I created a wiki page for QA related stuff into Mer wiki:

I am proposing an initial QA meeting to take place in #mer-meeting on
Tuesday’s starting 11:00 UTC (before Mer release management meeting).

Please share your ideas and thoughts (and wild dreams).

-Esa-Pekka Miettinen

Reply via email to