A test run is specific set of test cases for a particular milestone or version of the software under test for a particular tester. The test managment plugin creates a trac ticket of type testcase for each of the selected test cases. This is really powerful because you can take full advantage of the custom reporting engine in TRAC to track test results and test progress of each tester.

The advantage of having a testcase management tool in trac is that it removes the need to have yet another system that manages testcases...with all the usual problems of maintaing user account, system upgrades, licensing issues. The other advantage is that it adds more transparency to the testing process as the tool and any testcases are right there for anyone to see.

Test cases are stored in a very simple XML format. And you can specify collection of test cases (for example a smoke test) by specifying which test cases belong to a test template. This information is also specified in an xml file.

Note this plugin is designed to work with Subversion, although I don't use any specific subversion code. Potentially this plugin could work with other TRAC supported configuration management systems. I just haven't tried it.

Configuration steps required

create a testcases directory within an existing subversion project. We typically structure our development projects with a main project directory and then a source and build subdirectory. So when you add the testcases directory you might have something like this:

project/source/ <-- checked into subversion
project/build/ <-- this is not checked in but created when you build the application
project/testcases/ <-- checked into subversion

The nice thing about this is you add a lot more transparency to the testing process. As testcases are bundled and versioned with the source code

Add testcases and commit those testcases to your subversion repository using the example format (see attachment for correct XML format of the testcase file).

Create a testtemplate file and create and testtemplates you might care about for example the smoke-test (see attachment for correct XML format of the test templates file).

This is important because Trac can be set up against subdirectories so you often don't link trac to your root subversion folder, so only specify the full path from the root node if that's how trac was set up.

add a new ticket type called testcase

I also add a custom ticket type in the trac.config file for reporting purposes (although this is not required yet...just really useful)

Source

Example

'Step 1(Create your test cases)'
Take a look at the example test case I attached at the bottom of this page. It's a very simple XML format for specifying what a test case should be.

A test case has an Id (which should be the file name without any extensions), a component (matching a real component in your TRAC project), a summary, a description, and a field for describing the expected results of the test.

'Step 2(Define any required grouping of testcases in the testtemplates.xml file):'

An example grouping would be specifying that tests: test1, test2, and test3 all belong to the smoketest.

Make sure the tests and template file are checked in.

'Step 3 (Creating a test run)'
Click on the TestManagement tab on the main trac menu.

Click on the Test Run link

Select users to assign testcases to (these have to be known users to the trac system).

Select the appropriate version, and/or milestone/sprint for this testrun.

Select the testcases, and/or the appropriate test template.

Click the generate test run button.

This will re-direct you to the custom ticket reporting page with a pre-built query that should show you all the test cases that you just created grouped by user. It will also pick up previously created testcases if they also exactly match the query criteria.

'Step 4 (Run the testcases)'

Open one of the created tickets and using the testcase_result custom field specify whether the test for this test run passed,failed, or was not run for whatever reason.

Close each ticket in the normal way by setting the ticket to "fixed" (or one of the other appropriate resolved states).