Manual

IconsPage/iconCircle48.png

Home

Calendar

Calendar

Cadence Schedule

Roles

picto_office_application_orange_hex_48.png

Events

Contacts

FAQ


Your first manual testcase

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

Video Screencast of Tutorial

A video version of this tutorial can be seen here.

Requirements

Things you need to know

Should you get stuck / need help

Don't forget there is a wonderful quality community get help from if you get stuck! Here's a list of resources to help you connect with for help.

Use these resources to help you!

Launchpad

Launchpad holds the source code for all manual testcases in the manual testcase project. Code contributions are submitted as merge requests.

QATracker

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.

Bzr

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.

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

Make a new folder for you to develop under.

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

mkdir ~/manualtests

Open up a terminal and change directory into the folder.

cd ~/manualtests

Now, branch the current testcases.

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 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 primary 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. The test tests the import capabitilities of shotwell from plugging in a camera, to displaying the imported picture.

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: Plug in your camera using a USB cable. Your camera may need to be switched on, check the camera manual RESULT: A window appears telling you that it has detected media that contain digital photos

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.

Using Bzr

Now that your changes are complete, it's time to commit them to your local repository and then sync your local repository to launchpad so others can view and utilize your work. If needed, reference the links in the Bzr section at the beginning of this tutorial. Bzr commands require you to run them inside the directory (or a sub-directory) of the repository on your local machine. If needed, cd to the directory of the files you made / changed before running these commands.

First, let's commit to your local repository. Bzr allows you to view the status of a repository using bzr status. This will show you the changes you made to your local repository. For example;

$ bzr status
modified:
  testcases/packages/Mousepad
unknown:
  testcases/packages/nautilus

In this example you can see I've modified the Mousepad testcase, and made a new file for a new testcase for nautilus. The new file shows up as "unknown" to bzr.

If you made a new file, use the bzr add command to add it to the repository. If you only modified an existing file, you can skip this step and jump down to "Commit your work".

Add a file

bzr add /path/to/testcase

This will add the file to the repository so changes to it are tracked. The bzr status should now reflect that you are adding the new file to the repository. For example;

$ bzr add testcases/packages/nautilus 
adding testcases/packages/nautilus
$ bzr status
added:
  testcases/packages/nautilus
modified:
  testcases/packages/Mousepad

Commit your work

bzr commit -m "COMMIT MESSAGE"

You must enter a message of some sort in order to commit your changes. The message should be a short description of what you changed. For example, the message for my changes above could say "Added a new test for mousepad to verify keyboard layout. Created a new nautilus testcase".

Push your branch to launchpad

Replace the YOURUSERID field below with your launchpad id. Replace the YOURBRANCHNAME with a unique name for your branch -- it can be anything you wish. Naming the branch after the testcase you created/changed is an excellent choice.

bzr push lp:~YOURUSERID/ubuntu-manual-tests/YOURBRANCHNAME

You can confirm your branch is uploaded and view the code on launchpad here.

Now you simply need to submit a merge proposal to ensure your new branch gets reviewed and imported to the main trunk branch.

Contribute your new test!

Linking the branch to a bug

Find the bug from earlier. Copy it's bug number. Click your branch shown on this page and then click "Link a bug report". Paste the bug number, click search, then click OK.

Submitting a merge proposal

Select the "Propose for merging" link to start the merge request. Submit a merge request that includes your new testcase to the project. It will be reviewed and merged accordingly. Thanks for contributing!

What next?

Once your new case has been accepted and merge, 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.

QATeam/ContributingTestcases/Manual (last edited 2013-07-30 11:26:58 by smiddy84)