MeeGo wiki - User contributions [en]

Quality/QA-tools/Testrunner-lite

2011-06-06T11:17:46Z

Jokylanp: /* Usage */

= Testrunner-lite =

Testrunner-lite is a lightweight tool for test execution, which reads [[Quality/QA-tools/Test plan|Test Plan XML]] files as input, and produces [http://gitorious.org/qa-tools/test-definition/blobs/master/src/data/testdefinition-results.xsd a common-format] test result file which can be published at [http://qa-reports.meego.com/ qa-reports.meego.com]. With testrunner-lite, you can
* Execute automatic, semi-automatic and manual test cases
* Execute tests locally or in host-based mode by yourself or as a part of test automation system
* Use [[Quality/QA-tools/Testrunner-lite#Filtering options|filters]] to select the test cases to be executed
* Validate the used test plan file automatically

See our demo videos at Youtube:
* [http://www.youtube.com/watch?v=VKc5WWRLFgo Demo of new libssh2 feature in version 1.5.0]
* [http://www.youtube.com/watch?v=iYzxKU96xEg Proof of concept of parallel execution (not released yet)]
* [http://www.youtube.com/watch?v=TZhHDPUeHIw Demo of version 1.3.17]
* [http://www.youtube.com/watch?v=A0V94xZ_VwI Demo of version 1.3.11]
* [http://www.youtube.com/watch?v=OSF8tyUxI8U Demo of version 1.3.10]
* [http://www.youtube.com/user/meegoqatools MeeGo QA tools Youtube channel]

There is also a graphical user interface version of the tool called [[Quality/QA-tools/Testrunner|Testrunner]] available.

== Installation ==

Testrunner-lite can be installed on MeeGo Netbook UX, Ubuntu 10.04 (and newer) and Fedora 13 by doing the following:
# [[Quality/QA-tools/How to set up repositories|Set up the repository]]
# Install testrunner-lite

MeeGo Netbook 1.1:

sudo zypper install testrunner-lite

Ubuntu:

sudo apt-get install testrunner-lite

Fedora 13:

# yum install testrunner-lite

== Usage ==

The program is executed from command line

/usr/bin/testrunner-lite [options]
Options

-h, --help
Show this help message and exit.

-V, --version
Display version and exit.

-f FILE, --file=FILE
Input file with test definitions in XML (required).

-o FILE, --output=FILE
Output file for test results (required).

-r FORMAT, --format=FORMAT
Output file format. FORMAT can be xml or text. Default: xml

-e ENVIRONMENT, --environment=ENVIRONMENT
Target test environment. Default: hardware

-v, -vv, --verbose[={INFO|DEBUG}]
Enable verbosity mode; -v and --verbose=INFO are equivalent outputting INFO, ERROR and WARNING messages.
Similarly -vv and --verbose=DEBUG are equivalent, outputting also debug messages. Default behaviour is silent mode.

-L, --logger=URL
Remote HTTP logger for log messages. Log messages are sent to given URL in a HTTP POST message.
URL format is [http://]host[:port][/path/], where host may be a hostname or an IPv4 address.

-a, --automatic
Enable only automatic tests to be executed.

-m, --manual
Enable only manual tests to be executed.

-l FILTER, --filter=FILTER
Filtering option to select tests (not) to be executed. E.g. '-testcase=bad_test -type=unknown' first disables
test case named as bad_test. Next, all tests with type unknown are disabled. The remaining tests will be
executed. (Currently supported filter type are: testset,testcase,requirement,feature and type)

-c, --ci
Disable validation of test definition against schema.

-s, --semantic
Enable validation of test definition against stricter (semantics) schema.

-A, --validate-only
Do only input xml validation, do not execute tests.

-H, --no-hwinfo
Skip hwinfo obtaining.

-P, --print-step-output
Output standard streams from programs started in steps

-S, --syslog
Write log messages also to syslog.

-M, --disable-measurement-verdict
Do not fail cases based on measurement data

--measure-power
Perform current measurement with hat_ctrl tool during execution of test cases

-u URL, --vcs-url=URL
Causes testrunner-lite to write the given VCS URL to results.

-U URL, --package-url=URL
Causes testrunner-lite to write the given package URL to results.

--logid=ID
User defined identifier for HTTP log messages.

-d PATH, --rich-core-dumps=PATH
Save rich-core dumps. PATH is the location, where rich-core dumps are produced in the device. Creates UUID mappings between executed
test cases and generated rich-core dumps. This makes possible to link each rich-cores and test cases in test reporting
NOTE: This feature requires working sp-rich-core package to be installed in the Device Under Test.

Test commands are executed locally by default. Alternatively, one
of the following executors can be used:

Chroot Execution:
-C PATH, --chroot=PATH
Run tests inside a chroot environment. Note that this doesn't change the root of the testrunner itself,
only the tests will have the new root folder set.

Host-based SSH Execution:
-t [USER@]ADDRESS[:PORT], --target=[USER@]ADDRESS[:PORT]
Enable host-based testing. If given, commands are executed from test control PC (host) side. ADDRESS is the ipv4 address
of the system under test. Behind the scenes, host-based testing uses the external execution described below with SSH
and SCP.

-R[ACTION], --resume[=ACTION]
Resume testrun when ssh connection failure occurs.
The possible ACTIONs after resume are:
'''exit''' Exit after current test set
'''continue''' Continue normally to the next test set
The default action is 'exit'.

-i [USER@]ADDRESS[:PORT], --hwinfo-target=[USER@]ADDRESS[:PORT]
Obtain hwinfo remotely. Hwinfo is usually obtained locally or in case of host-based testing from target address. This option
overrides target address when hwinfo is obtained. Usage is similar to -t option.

-k KEY, --ssh-key=KEY
path to SSH private key file

Libssh2 Execution:
-n [USER@]ADDRESS, --libssh2=[USER@]ADDRESS
Run host based testing with native ssh (libssh2) EXPERIMENTAL

External Execution:
-E EXECUTOR, --executor=EXECUTOR
Use an external command to execute test commands on the system under test. The external command must accept a test
command as a single additional argument and exit with the status of the test command. For example, an external executor
that uses SSH to execute test commands could be "/usr/bin/ssh user@target".

-G GETTER, --getter=GETTER
Use an external command to get files from the system under test. The external getter should contain <FILE> and <DEST>
(with the brackets) where <FILE> will be replaced with the path to the file on the system under test and <DEST> will be
replaced with the destination directory on the host. If <FILE> and <DEST> are not specified, they will be appended
automatically. For example, an external getter that uses SCP to retrieve files could be "/usr/bin/scp target:'<FILE>' '<DEST>'".

=== Filtering options ===

Filtering options allow selecting which tests are to be executed. Filtering options are given as a string. String may contain one or more filter entries. Format of each entry is 'filtername=values' where 'filtername' typically corresponds to an attribute in Test Definition XML and 'values' is a string to which the filter should match. Multiple values can be specified if separated by comma (without extra space). A value containing space must be enclosed in double quotes (""). Current list of forbidden characters in values is as follows: Single quote ('), double quote ("), is-equal-to sign (=), comma (,).

How filtering is carried out: Before processing the filter options, all tests are active by default. Filters can only deactivate tests: If filter value does not match with the value of the corresponding attribute, the test is disabled. Each filter entry is applied for all the active tests in the test package, one after another, in the given order. Filtering is always carried out at the lowest level of the "suite-set-case-step" hierarchy where the corresponding attribute can be defined. Note that some attributes may inherit the value from the upper level. Please refer to Test Definition XML for details.

If 'filtername' is prefixed with dash (-), the filter behaviour is reversed: those tests for which the filter value does match, are disabled.

'filtername' can be any of the following:

* feature
* requirement
* testset
* type
* testcase

The following example does the following: First it disables all test cases except those with attribute type='Integration'. Next, a test case named as Bad Test is disabled. The tests left active will be executed.

testrunner-lite -f tests.xml -o ~/results -l 'type=Integration -testcase="Bad Test"'

The following example executes test cases that specify the requirement attribute with a value containing at least one of the following strings: '50001', '50002', '50003'.

testrunner-lite -f tests.xml -o ~/results -l 'requirement=50001,50002,50003'

Note that each key=values is handled as a separate filter, when checking whether a test case should be filtered. The following example will filter all the test cases,

testrunner-lite -f tests.xml -o ~/results -l 'testset=set1 testset=set2'

whereas the following will accept tests from test sets "set1" and "set2".

testrunner-lite -f tests.xml -o ~/results -l 'testset=set1,set2'

== Manual Test Cases ==

It is also possible to execute manual test cases using testrunner-lite, as defined in Test Definition XML.

In case manual test case is encountered during execution, testrunner-lite will go through the defined test steps and ask user whether the step is passed or failed. The test case will terminate at the first failure, otherwise every step defined will be executed. After the test case is done, user has the option to enter additional comments.

Example output when running manual case:

[INFO] 15:15:53 Starting test case: ExampleTestCase
--- Execute test step ---
Description:
Open calculator. Expected result: calculator opens up.

Please enter the result ([P/p]ass or [F/f]ail):
P

--- Execute test step ---
Description:
Stop calculator

Please enter the result ([P/p]ass or [F/f]ail):
P

--- Test steps executed, case is PASSED ---
Please enter additional comments (ENTER to finish):
Execution was slow.

[INFO] 15:16:41 Finished test case. Result: PASS

== Testrunner-lite and test case verdicts ==

For manual cases the result is naturally set by the user. For '''automatic''' cases a result of a test case is set as follows:
* PASS
** all test steps finished with expected results
* FAIL
** test step has unexpected return value
** test step timed out
** pre-steps on the set the case belongs to have failed
** fail based on [[Quality/QA-tools/Test_plan#Measurement_data|measurement data]]
* N/A
** test case has state=Design in the tests.xml
** test case has no steps

If a test case is filtered it doesn't get any result; meaning it is not written to results file at all.

The goal is to align testrunner-lite functionality with what is agreed [[Quality/Glossary#Test_case_verdict|here]].

== About process control ==

Each test step is executed in a separate shell. Testrunner-lite spawns new process for the execution, and waits for the step to finish (or timeout). In case test step contains command that is started to background, the step returns immediately. After test case has finnished a cleanup routine is executed, where testrunner-lite tries to kill all processes that may have been left running by the test steps. Cleanup for pre-steps and post-steps is done after the post steps are executed (i.e. when test set has been executed).

== About host based execution ==

Testrunner-lite supports host based execution, where testrunner-lite is executed on a PC, and the test steps over ssh on hardware. This requires that key based ssh authentication is enabled between device and host.

Remember that each single step in pre_steps, post_steps or inside testcases is executed in a separate SSH session, so you'll have to make sure that if your steps leave some processes running in the background which inherits its pipes straight from the parent shell, the SSH connection will hang until those processes are terminated (or until they close their pipes). Therefore, you should always redirect the stdout, stderr and stdin streams of your background processes, if you don't want your test steps / pre- / post steps to time out in host-based execution.

See http://www.snailbook.com/faq/background-jobs.auto.html for more information.

== Testrunner-lite state machine ==

Below is a simplified picture describing the operation of testrunner-lite. The program flow can be considered to consist of three phases: initializing, executing and clean up. The execution is done set by set, so that the tool needs to maintain only one set at a time in its memory.

[[File:testrunnerlitefsm.png]]

xfig file:
[[File:testrunnerlitesm.fig]]

== Further development ==
We're actively making testrunner-lite a better tool. See discussion about architecture changes and suggestions in following page:
[[Quality/QA-tools/Testrunner-lite/Testrunner-lite_development|Testrunner-lite development]]

== Contact ==

Testrunner-lite is developed by [[Quality/QA-tools | QA tools team]]. You can contact us and contribute via the following channels:
* [http://webchat.freenode.net/?channels=meego-qa #meego-qa IRC channel on irc.freenode.net]
* [http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Quality%20Assurance File new bugs or improvement ideas to Bugzilla]
* [http://bugs.meego.com/buglist.cgi?bug_status=NEW&bug_status=NEEDINFO&bug_status=INDEFINITION&bug_status=ASSIGNED&bug_status=ACCEPTED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=WAITING&bug_status=REOPENED&bug_status=RESOLVED&bug_status=RELEASED&bug_status=VERIFIED&component=testrunner-lite&query_format=advanced&order=priority%2Cbug_severity%2Cchangeddate%2Cbug_status%2Cassigned_to%2Cbug_id&query_based_on= Leave a comment or vote the items in our backlog]
* [http://lists.meego.com/listinfo/meego-qa meego-qa@lists.meego.com mailing list]
* [http://meego.gitorious.org/meego-quality-assurance/testrunner-lite Source codes in Gitorious]

Quality/QA-tools/Test plan

2010-11-09T10:56:09Z

Jokylanp: Added documentation about hwiddetect and get

== Test plan overview ==

The basic principle of test plan XML and tool support is that you can use 'any' executable for testing.
Test results are checked from exit codes (automated testing) or prompt (manual testing). Executed test plan XMLs produce XML results - wrapping variety of test methods in consistent format required by test automation and data processing.

The test plan information stored in Test Definition XML files consists of:

1. suite, set, case: Hierarchical structure of the tests.
2. feature, subfeature, requirement: Information about why the tested software has been implemented in the first place (which is why it’s being tested as well).
3. type: Information about the viewpoint of the tests (which quality aspect of the software they are testing, see DevelopmentTestArea in Agile Testing Wiki).
4. level: Information about which test level the tests belong - for test level.
5. domain: Information about which architectural domains the tests are focused on.
6. description: descriptions of the tests (what each test is, and what it is supposed to do).
7. step: Execution instructions (for automated tests), which determine the actual commands to execute to run each test.

''Note:'' that all of the above are not mandatory. Mandatory fields for executing tests are defined with test plan XML validation schema.

== Creating Test plan ==

There are certain mandatory things you’ll need to provide in a test definition XML.

The structure of the XML and the possible attributes/values are defined in the Test Definition XML schema. It’s important to validate (see validation) your XML against the up-to-date schema (also shown on this page).

Important information that you can’t get directly from the schema, about which attributes are mandatory, which values are possible, and where you should get the values from to be used in the definition, is available in the appendices section on this page.

=== Test Cases ===

The main thing in test plan are the test cases, which define what to execute (test steps), what to expect from the execution (expected results) and also some additional information for reporting purposes. An example test case could be:

<case name="my-first-case">
<description>Creating my very first test case</description>
<step>ls</step>
<step>uname -r</step>
</case>

What did we just do? We created a simple test case named <code>my-first-test-case</code>, which executes two steps and expects that they return the common “success return value” 0. Want to check for some other return value? Use <code>expected_result</code>:

<step expected_result="-1">ls</step>

In case you feel that some test cases are insignificant, i.e. that they shouldn’t be taken into consideration when choosing whether the test run is passed or failed, you can use insignificant-attribute (defaults to <code>false</code>, i.e. every case is considered to be significant):

<case name="not-so-important-test" insignificant="true">

In addition to test execution, the “story” of the test case should also be told, and for telling this story, we have fields for test type (what quality characteristics are tested) and test level (what level of system is being exercised. The possible values for both of these are listed in the appendices. Let’s add level and type to our test case:

<case name="my-first-case" level="Product" type="Functional">
<description>Creating my very first test case</description>
<step expected_result="-1">ls</step>
<step>uname -r</step>
</case>

And that’s our first test case! Not that difficult...

=== Grouping Cases - Sets and Suites ===

Grouping cases to sets and suites makes your life easier and more organized. A good idea is to group test cases that test the same features into same sets, and sets that test the same architectural domain under same suites. E.g.:

<suite name="my-multimedia-tests" domain="Multimedia">
<set name="video-playback-tests" feature="Video Playback">
<description>Video</description>
<case ...
<case ...
</set>
</suite>

So, sets contain test cases, and may also contain description (the same way as the cases do). More about sets in Test Definition Execution part

'''Note:''' There are several attributes that need to be defined on the test case, test set, or test suite level in the test definition XML.<br /> You can find more information about these attributes in the Appendices section of this page.

=== Time outs ===
Test steps will time out by default after 90 seconds. You can change the default time out by adding timeout attribute to your test case. for example

<case name="my-test-case" timeout="120">

Note that this the timeout is for single test step not for the whole case.

For [pre|post]-steps the the default timeout is 180 seconds, it can also be changed:

<pre_steps timeout="600">

=== Putting It All Together ===

Now that you have some knowledge on grouping and test cases in general, it is time to put it all together. Before showing an example, it is important to note that all the mentioned case attributes (e.g. level, type) are inheritable. So, if you have e.g. a set which contains only certain type of cases, you can define the type at the set-level, instead of writing it separately into each case.

Now, the example. Let’s first add the mandatory tags, which each test definition should have:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
</testdefinition>

That’s the mandatory part; we defined that we have a XML-document, and that this particular one is test definition version 1.0. Let’s add more beef to the bones by adding one suite with couple of sets:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
<suite name="my-multimedia-tests" domain="Multimedia">
<description>Testing AF stuff</description>
<set name="video-playback-tests" feature="Video Playback">
<description>Video playback tests</description>
</set>
<set name="video-recording-tests" feature="Video Recording">
<description>Video recording tests</description>
</set>
</suite>
</testdefinition>

Okay, we have one suite named <code>my-multimedia-tests with two sets</code>, testing video playback and recording features. Cases are still missing:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
<suite name="my-multimedia-tests" domain="Multimedia">
<description>Video playback tests</description>
<set name="video-playback-tests" feature="Video Playback">
<description>Video playback tests</description>
<case name="playback1" type="Functional" level="Component">
<step>execute_playback_test</step>
</case>
</set>
<set name="video-recording-tests" feature="Video Recording">
<description>Video playback tests</description>
<case ...
</set>
</suite>
</testdefinition>

And that’s the basic story. Next chapters cover more details about the definition, but you should now have the general understanding of the subject!

== Controlling Environment for Execution ==

=== Setup and Teardown ===

In case you want to do some setup and cleaning before and after the cases are executed, sets may have pre- and post-steps in them:

<set ...>
<pre_steps>
<step>do_some_setup</step>
</pre_steps>
<case ...
<post_steps>
<step>clean_up</step>
</post_steps>
</set>

If you want to ensure that pre-step is executed properly before starting the real testing, you can use expected result also in those:

<pre_steps>
<step expected_result="1">do_some_setup_that_may_fail</step>
...

:'''Warning''' When using expected result in this context, the process return value will be waited for, thus you cannot use this with daemon or background processes since they basically never return and cause execution to jam. Another thing to note is that the steps are executed in separate shells, so it is not possible to e.g. set environment variables or change directories in pre-steps as those will be lost.

=== Filtering Based on Hardware Identifier ===

If different tests sets for different hardware are required then hwiddetect feature can be utilised. User can define a command used to get a hardware identifier within hwiddetect tag. The hardware identifier returned by the command is matched with optional hwid attribute of a test set. If not equal, test cases in the set are skipped and are not written to the result file. A test set will never be skipped if hwid attribute has not been defined for it. You can also define multiple hwid values separated by comma for a set.

Command defined by hwiddetect can be a shell command or a separate executable. The executable should be included in the test package. Testrunner-lite removes extra whitespace and linefeeds from the the output of the hwiddetect command so that test developer does not need to care about it.

Example usage of hwiddetect:

<?xml version="1.0" encoding="UTF-8"?>
<testdefinition version="1.0">
<hwiddetect>/usr/bin/getmyhwid</hwiddetect>
<suite name="suite1">
<set name="test_feature_X_on_hw_bar" hwid="bar">
<case name="test_X_1">
<step>echo "hwid is bar"</step>
</case>
</set>
<set name="test_feature_X_on_hw_foo" hwid="foo">
<case name="test_X_1">
<step>echo "hwid is foo"</step>
</case>
</set>
<set name="test_feature_X_on_hw_foo_or_bar" hwid="foo,bar">
<case name="test_X_1">
<step>echo "hwid is foo or bar"</step>
</case>
</set>
</suite>
</testdefinition>

=== Fetching Additional Files ===

In addition to normal result file, you can also fetch what ever files you need with get-tag:

<set ...>
...
<get>
<file>/tmp/myadditionalresult.1</file>
<file>/tmp/myadditionalresult.2</file>
</get>
</set>

== Manual, Automatic and Semi-automatic Test Cases ==

If not specified by the "manual" attribute all cases are automatic. The value for the attribute is inherited from higher entity (set->case->step). By semi-automatic test case we mean a manual case that has some automatic parts; the idea being that only those steps that have to be manual, are. Note that this does not work the other way around, we cannot have automatic test case with manual steps (would be semantically weird thus our tools do not support it).

The example below tries to clarify the above. The "example_set" shows a manual, automatic and semi-automatic case. The example works with testrunner-lite/testrunner-ui, give it a try: [[File:example_definition.xml]].

<?xml version="1.0" encoding="UTF-8"?>

<testdefinition version="1.0">
<suite name="example_suite">
<set name="example_set">
<description>Example test set with manual, automatic and semi-automatic case.</description>
<case manual="true" name="manual_case">
<description>Manual test case with three steps inside one step tag.</description>
<step>Step 1: execute command ttt on shell.
Step 2: write something into edit box.
Step 3: press ok button.
Expected: Text should be updated into label.
</step>
</case>
<case timeout="96" name="automatic_case">
<description>Automatic test case that executes some shell commands.</description>
<step>ls /tmp</step>
<step expected_result="2">ls /nosuchfile</step>
<step>pwd</step>
</case>
<case manual="true" name="semi_automatic_case">
<description>A case with two automatic and two manual steps.</description>
<step manual="false">xcalc &</step>
<step>Step: Type in 2 + 2 =. Expected: 4 is displayed </step>
<step>Press x² button. Expected: 16 is displayed.</step>
<step manual="false">killall xcalc</step>
</case>
</set>
</suite>
</testdefinition>
(A real test developer / tester might come up with nicer examples, any input welcome).

== Test Plan Execution ==

Test definitions are run with test runner (“<code>testrunner-lite</code>”), which reads the definition and produces a result XML file. We also provide testrunner user interface to support testing - please see [http://wiki.meego.com/Quality/QA-tools/Autotest-guide#Setting_up_test_automation_environment repositories] to install it and [http://www.youtube.com/watch?v=nileVzw52xM demo video]

Quality/QA-tools

2010-08-27T08:45:26Z

Jokylanp: /* Team Members */

== Quality Assurance (QA) Tools ==

Quality Assurance tools are developed to ensure MeeGo SW quality.

Work in progress includes open sourcing Nokia / Intel quality assurance tools and making open source test tools available for anyone interested in MeeGo software quality.

== QA Tools ==

Open source tools – available for all, available for development and contributions. Make people accountable for quality.

QA tools team develops and maintains tools for Quality Assurance.

Anyone is welcome to contribute and non-member contributions will be treated
with same process and review as member contributions.

Team communication is in English.

=== Meetings ===

Meetings will be held weekly in <code>#meego-meeting on irc.freenode.net</code>.

==== Agenda for the next meeting - Tuesday 31th 2010 12:00 UTC ====

* Short intro for project targets and tools we work with
* Status of open bugs / features at [http://bugs.meego.com/buglist.cgi?classification=MeeGo%20Platform&query_format=advanced&bug_status=NEW&bug_status=NEEDINFO&bug_status=ASSIGNED&bug_status=WAITING%20FOR%20UPSTREAM&bug_status=REOPENED&component=eat&component=min&component=testdefinition&component=testrunner-lite&product=Development%20Tools bugs.meego.com]
* Review of released demo videos
* Review of contribution guidelines

=== Team Members ===

The current team members are (in no particular order):

{| border="1" cellspacing="0"
|+
| Name
| Role
| Affiliation
| IRC nickname
|-
| Ville Ilvonen || Team lead (act.) || Nokia || vilvo
|-
| Riku Halonen || Team member || Nokia || rikhalon
|-
| Kari Sievi || Team member || Digia || -
|-
| Timo Härkönen || Team member || Digia || timoph
|-
| Carol Rus || Team member || Digia || -
|-
| Sami Lahtinen || Team member || Digia || slahtinen
|-
| Raimo Gratseff || Team member || Digia || -
|-
| Kyösti Ranto || Team member || Digia || kyranto
|-
| Arto Sinnelä || Team member || Digia || asinnela
|-
| Joonas Kylänpää || Team member || Digia || Kaadlajk
|-
| Sampo Saaristo || Team member || Sofica || -
|-
| Ling Yu || Team member || Intel || -
|-
| Jing Wang || Team member || Intel || -
|-
|}

Our collaboration spaces are:

* [http://lists.meego.com/listinfo/meego-dev meego-dev@meego.com mailing list], please prefix with 'QA-tools' for team related topics.
** Please also poke team members or Ville Ilvonen either by email or on IRC because of high traffic @ meego-dev
* [http://webchat.freenode.net/?channels=meego-qa-tools #meego-qa-tools IRC channel on irc.freenode.net]
* Gitorious team, http://gitorious.org/qa-tools (to be moved meego.gitorious.org)
* MeeGo OBS - devel:quality
* This wiki area
* [http://wiki.meego.com/Quality/QA-tools/ServiceOS ServiceOS]

[[Category:QA]]