The Bug Catcher - Tips and Tricks from QA Experts

TIP #1: Building modular test cases

Using modularity in your automated test case design can pay big dividends down the road. Initially it may seem fine to have a single long test case that covers every step needed, but the maintenance effort will be greatly reduced if you build your initial test cases with modularity. By grouping any set of logical steps into a modular procedure that is called from all relevant test cases, you allow this procedure to be edited in a single place. So instead of having to modify all of your test cases when something changes, you only have to make one update. For example, if you are using a traffic generator you might have hundreds of test cases that require you to log in. You should consider using a login procedures instead of adding a separate login to every test case. Then, if down the road you want to change the password, you can just modify one procedure instead of modifying hundreds of test cases.

TIP #2: Standardizing testbed configurations

When transitioning from a world of adhoc manual testing to building automated test cases that will eventually run in a regression environment, one of the first tasks to complete is standardizing the testbed configurations that will be used for your test cases. By doing some up front planning between the folks developing the test cases and the team running the test cases in regression, you can build test cases that more easily slide right into your regression environment. The typical pieces that should be defined up front are:

What devices are in the testbed
What are the minimal requirements of these devices
What variables or parameters will be used in the test cases

By making some of the testbed configuration elements variables up front, the test case requires less modification when moving into regression. For example, if you are using a traffic generator in your testbed you might want to define a parameter called traffic_gen_slot and traffic_gen_port. In the test case developer’s testbed these might translate to slot 3, port 1, but in regression you might be using slot 8, port 4. By establishing some variables up front you can build test cases that are portable and more easily move into the regression environment.

TRICK #1: Building a procedure library in FanfareSVT

Building modularity into your test case design is easy with FanfareSVT. The first step is to create a Procedure Library, which is just another Fanfare test case that has a bunch of local procedures defined. When you want to use one of these procedures in a new test case you simply add the Procedure Library as a referenced test case and the procedures in the library are available for your test case. You can now edit these procedures in a single location — the Procedure Library and the changes will flow forward to all of your test cases when they are executed the next time. Taking some time to think through what parts of your test case should be centralized procedures will be well worth the effort down the road.

TRICK #2: Configuring standard testbeds using FanfareSVT

FanfareSVT allows you to configure a separate testbed file for each physical testbed that exists in your test organization. By defining a standardized testbed template up front, new testbed files can use this to define a particular physical testbed. This testbed file can include a diagram of the testbed layout, possibly showing some of the parameters that should be used in the test case design. FanfareSVT allows you to create parameters that are associated with the testbed file so that a test case can easily be run on a new testbed (regression) by just changing the file that the test case is associated with. You can also immediately view any tests that are relevant to a particular test bed. Taking the time to define some parameters up front will greatly reduce the effort to move a test case from development into regression.

Tips and Tricks from QA Experts

Fanfare is pleased to offer the latest "insider" product usage tips and techniques based on our most frequent customer requests. In this issue:

TIP #1: Building modular test cases

TIP #2: Standardizing testbed configurations

TRICK #1: Building a procedure library in FanfareSVT

TRICK #2: Configuring standard testbeds using FanfareSVT