In our tutorials so far we have assumed that the Test Manager completed the initial setup of the Car test project. The Test Lead now has the responsibility to setup the Test Design structure and setup QaTraq ready for new builds. So in this tutorial we'll concentrate on those tasks in the test management process that the Test Lead needs to complete.

As a Test Team Lead using QaTraq you will probably want to concentrate on the following:

Deciding on the approach you take to defining Test Designs and Test Scripts in QaTraq is key to the success of you test project. Get this bit wrong and you may as well have written your test design and script on tablets of stone (you'll be stuck with it!)....not that we perceive this as a short coming with QaTraq....you get your test setup wrong, or even your application architecture wrong in any arena then you are always going to be fighting a losing battle. Get it right though and your make your life infinitely easier.

There are a couple of approaches to Test Design setup: Both approaches are valid. Whilst we are going to concentrate on the 'release' approach here many people find the 'functionality' approach more logical. The decision really is yours.

So, for each release of the product (i.e. car_0_1) we will create a new test design document. In this example we're going to concentrate on release car_0_1 in which the development team release the Engine to us (nothing else released so just the engine to test at this stage......its a start I suppose!) So we have the first design document for the first release/build of the car. You can see that we may well end up with three test scripts for each of the areas identified above (although we'll leave it to our test analyst to figure this out). For now clicking Design, Search and then View, should give you a page similar to the one shown here.

At this stage you have the test design (or test approach) for the first release of your product. It is at this point that you might want to point your test analyst in the direction of the test design document for the 'engine' component and tell them to get started with designing the tests. Better still perhaps you should sit down with the Test Analyst and work out a good structure for the test cases between you. Between you, you can create the new test scripts and leave the detail for the Test Analyst to enter.

Now that you have an idea of the test areas that need to be covered for this release you probably want to sit down with the test analyst and decide on which test scripts you want to create and run. Before you decide on which test scripts to create bear in mind the following...

"A Test Script is a document which describes in detail how a test is to be conducted. A test script will contain information outlining the test, defines the pre-requisites and contains a number of test cases. The user will enter the outline and pre-requisite text and then link the test script to a number of test cases that need to be contained within the test script."

Whilst we will be leaving the test script detail to our test analyst we'll probably sit down with him/her and talk through the test design document. The test design document for release car_0_1 explains this release will only contain the Engine component. So we might discuss with the test analyst the possibility of creating the following test scripts for this release: In fact when you look here you can see that we did create three separate test scripts under this test design document. To see how the Test Analyst went about creating these test scripts see the section on Test Scripts.

So assume the first wave of testing on car_0_1 is well under way. Our Test Analysts are happily creating test scripts and our testers undertaking the testing. We're 1 month down the road (no pun intended) and the development team inform you that release car_0_2 is imminent. So we create the next test design document to cover testing release car_0_2 Now that we have the second release, you can see that we are building up the test areas. Perhaps we'll have four new test scripts to cover each of the areas above (but we'll leave that for our test analyst to determine). We do know that we need to address functional testing of the chassis and integration test the engine with the chassis. So our latest test design document might look like the design document here.

As each of the releases for the car are delivered and the test design documents developed to cover each release you will see more and more depth added to your test plan. In fact if you look at your test plan once you've added the test designs for each release you might find it looks like this ....note the associated test design documents that now show up in the test plan.

So to summaries, we will create separate test design documents for each release of the product and we are probably aiming for a test document hierarchy along the following lines.... When we look at Test Design for build car_0_2 we see that they are releasing the chassis in this release and that they've fixed some bugs in the engine (see this for more info on this release). So we will concentrate the testing for this release on re-testing, regression testing and new testing of the chassis. So again we're probably aiming for a test document hierarchy along the following lines for release car_0_2.....

Test Des gin (build car_0_2)	Test Script (re-testing) *	Test Cases - Engine max revs - Engine variable revs
	Test Script (regression testing)	Test Cases - Engine minimum revs
	Test Script (integration testing)	Test Cases - Engine fit in chassis - Engine running in chassis
	Test Script (rigidity testing)	Test Cases - Chassis strength - Chassis destruction test
	Test Script (build quality)	Test Cases - weld neatness - paint coverage

* we picked up some bugs in the first release when running Max and Variable rev tests so we've included a test script which covers the retesting of these bug fixes.

Coming soon!

As the Test Lead we've put the test design documents in place which identify what we expect to be covered for each release. Again though, its down to the test analyst to actually start developing the tests and write the test scripts in line with this test design document. We cover the role of the Test Analyst in the next tutorial 'The Test Analyst's Perspective'.