Skip to content

Desktop Client QA Workflow

dragotin edited this page Dec 17, 2014 · 7 revisions

This page describe the QA efforts that we do on ownCloud Desktop Client Development

Manual QA

The Desktop Team currently has one dedicated QA engineer. This is how we collaborate.

Bugfixes

Once reported bugs are fixed by one of the developers, the developer who fixed it sets the Ready to Test tag and mentions the SHA sum of the fixing commit. The bug is not closed. The QA engineer picks up the list of bugs with that label and verifies the bug fix. If the bug is really fixed, the QA engineer closes the bug report. If not, the QA engineer removes the Ready to Test tag and comments the bug. The developer who worked on the bug fix picks the bug up again and fixes again.

Releases

For releases, the QA Engineer works based on a testplan. There is a generic testplan, but also, if applicable, release specific parts of the test plan.

To set up the test plans, the QA engineer needs detailed information on what new functionality or bug fixes is available in the new release.

Automatted QA

Unit Tests

We have two collections of unit tests, one originating from csync here and one based on the Qt Testing Framework available here. To include the unit tests to the build, call cmake with the parameter -DUNIT_TESTING=ON.

The tests can be run manually on Linux, but not (yet) on Windows or Mac by calling make test.

Both unit test groups are part of the continous integration server. They run on every checkin.

tx.pl Scripts

We maintain a set of perl based scripts to perform integration tests between client and server. The scripts wrap around the command line client owncloudcmd. The basic idea is that the client directory and a test server is filled with a defined set of files through the server's WebDAV interface, completely without sync client utilization. After that, one or more sync run is performed by the script. After the sync run completed, the local and remote file trees are asserted if both are equal, or meat the expectation.

The scripts can be run manually on the developers machine on Linux, but not (yet) on Windows or Mac by calling them directly from the csync/tests/ownCloud directory of the git checkout. Prerequisite is to crate a t1.cfg file based on the template in that directory.

The tx.pl scripts are part of the continous integration server. They run on every checkin.