Your first manual testcase

This page will walk through writing and contributing a manual testcase.

Requirements

There are some things you need to have set up first to be able to contribute, documented here

An optional tools is bzr-explorer

sudo apt-get install bzr-explorer

Should you get stuck / need help

• Mailing list:

  • ubuntu-quality

• IRC channel:

  • #ubuntu-quality

Use these resources to help you!

Where Manual Testcase data is kept

Launchpad holds the source code for all manual testcases in the manual testcase project. Currently required testcases and bugs for already written testcases can all be found on Launchpad. Code contributions are submitted as merge requests.

Bzr is the version control system used. You can see a reference chart here as well as a quick start guide if you need help on the basic commands you'll need to contribute a testcase.

The QATracker is the master repository for all our our testing within ubuntu QA. It records results and helps coordinate our testing events. Learn more about it here. Code committed to the manual testcase project will be utilized for testing on the qatracker.

Style Guide

A quick review of how the testcases should look and tips to keep in mind while your writing.

Writing the testcase

Get the current testcases

Open up a terminal and make a new folder for you to develop under.

For this example, let's utilize ~/manualtests.

mkdir ~/manualtests

Change directory into the new folder, then branch the current testcases

cd ~/manualtests

bzr branch lp:ubuntu-manual-tests

This will grab a copy of the current testcases used by the project. We can then use bzr to add a new testcase we'll write below and then finally commit the testcase back to the project.

Choose an application

Choose an application you wish to write the testcase for. Here's a list of needed testcases that you can choose from. Don't see something you like on the list? We still welcome your contribution. Testcases for any image, package, or potential piece of hardware that runs on Ubuntu or official flavours is welcome!

Assigning the work to you

Each testcase request is listed as a bug report. Once you've chosen a bug (test) or two to work on, assign yourself to that bug (test) in launchpad and mark the bug as "In Progress". You will use the bug later on as well as part of your merge request.

Write the test

Create Action Steps

Run the application you've chosen and pick a few of the features of the application. Document each feature you've chosen and write down step by step instructions in order to utilize the feature. Let's quickly take a look at a current testcase to get an idea of how this works.

The first testcase is simple enough. It's goal is to 'check that Update Manager opens correctly'. You can see each step is laid out with an action and expected result.

Notice the formatting and the action followed by expected result format, and notice the html markup of dd and dt used. You can see the proper format information here.

Create Expected Results

Now, run through the steps you wrote down to ensure they exercise the feature you targeted. As you step through your instructions, record what happens for each step so you can add them to the test case. These will become your expected results in the testcase. In our example, you can see this like so:

ACTION: Open Update Manager

RESULT: The Software Updater starts, checking for updates as it opens.

Finish Formatting and verify your test

Format your testcase steps and expected results in the proper testcase format. You should utilize the 'normal' testcase format where each step represents and 'action', followed by an 'expected result'. Note that you have to use the html markup as shown. The tracker will interpret the html to display and number your items properly.

Run through your test as if you were executing it as a testcase. Ensure you didn't miss any steps, or make any assumptions. It can be helpful to have someone else run the test for you to ensure it's successful for them as well. Opening the file in a word processor is an easy way to check for spelling mistakes.

Check the formatting

Once you have saved your testcase, you can check that the formatting is correctly applied with the testcase format script.

If the formatting is correct, the script will report that by showing the testcase name

test-case-format 1596_Update\ Manager 
1596_Update Manager

If an error is found it will report that by showing where the first line with errors can be found.

 test-case-format 1656_StartupDiskCreator 
1656_StartupDiskCreator
line 1 column 1 - Warning: discarding unexpected plain text
line 5 column 15 - Error: unexpected </dt> in <dl>
1 warning, 1 error were found!

Fix the formatting error found and retest until there are no errors in the file. Now you are in a position to push your new testcase to the branch for verification.

What next?

Before your new testcase can be verified and merged, it needs to be pushed so that others can see it, comment on any changes that might be required and of course, approve it.

After that it will enter the pool of testcases available for usage on the various qatrackers. From there it can be utilized for all sorts of manual testing events; a special call for testing or as part of the normal cadence testing that occurs throughout the cycle.

To push your new testcase to your branch check out the QA Tool Usage page where more detail regarding BZR and importantly linking your branch to bugs can be found.

Video Screencast of Tutorial

A video version of the previous version of this tutorial can be seen here.