Author: Bill Echlin

Different test management tools use different terminology for the concept of having a library of reusable test cases. With Quality Center the term used is the test plan. Not quite sure why it’s referred to as the test plan as a test plan is far more than just a repository of reusable testcases you’ve written. I suspect it’s just historical so we’ll let that point go. Anyway, in Quality Center terms the test plan is a library of testcases. Those testcases reside in the test plan area and can be used in sets. Those sets are then executed and the associated testcases executed. So you can see that you have two different instances of the testcase…. 1. The instance that...

Scaling up your test cases effectively usually involves the practice of parametrization. That is, the concept of having one testcase and then feeding in parameter values to create variations of the test case at run time. So essentially you have the same testcase which you execute repeatedly with different data values. Defining parameters in Quality Center is done at the step level where each step is fed parameter values from a grid of values. Each value having a default value, a description and order information associated with it. In this session we look at defining, adding and assigning values to params that are used when executing a run. As with other test management tools there are a number of key...

An important part of our Quality Center test management process is tracking which releases and configurations our test cases are executed against. So for example, when we run a test we should record the fact that it was executed on Windows XP with IE9 and executed against version 1 build xyz of the product we’re developing. What we’re looking at in this session is, firstly defining a release/cycle and linking test sets and runs. Then we look at how we can factor in and link configurations into these runs in various different ways. With Quality Center we define releases at the top level. These releases track a group of changes we might be making to a product under development. We...

Reusable test cases that can be used across different projects can be a difficult to implement and manage. There are some good ways to approach this though. In this article we look at ways to configure your test management tool so that you can effectively handle main products and sub products effectively. As a practical example we’re going to base this on a submarine. Where we’re looking at managing the major release of the submarine, and independently managing the Engine, Periscope and Radar sub products. We’ll look at working separately on these engine, periscope and radar products. Then rolling up work on those to include them in a major release of the submarine. You can see an example of this...

Selecting the right test management tool is critical to your business. Select the wrong tool and you’ll end up fighting and wrestling to get the benefits you know you should be gaining. Select the right tool and you’ve got a solution that will support and promote your QA process. Your approach to selection is not one to be taken lightly. With well over 30 applications on the market you’ve got a lot of work to evaluate all of them. You can evaluate all of them in detail. Take a gamble and just select one. Or you can use an efficient evaluation process that will help you identify the right solution with the minimum of time and effort. We’d recommend the...

Continuing with our look at the complexities of test management with Quality Center we’re looking at version control this time. At a basic level version control means tracking which changes have been made to a testcase, who made them and when. Furthermore version control can mean tracking which version of a testcase was run against which release of a product and within which cycle. This is where version control starts to get complicated. Within Quality Center we have 3 different areas of version control that we can apply to our test management process: basic change tracking (audit log) baselines versioning In this video we look at each of these test management versioning concepts in turn. Audit Logs – When we...

One important aspect to monitor on any test management project is the time it takes to execute a number of test cases. Capturing and reporting this information usually drives the average QA engineer slightly mad (after all you only need to find one bug during the execution and all figures will be distorted). So yes there is a certain amount of ambiguity associated with tracking this. Having said that there is some merit to this. Not least it helps provide some idea on the resources needed for a particular project. If you can estimate the testing duration (and provide past evidence) it’s far easier to argue the case for the right level of resources for future project. So it’s not...

As part of our test management complexities series we’re looking here at assignment of testcases within Quality Center. Assignment within QC typically works at the “testcase” level within the Plan and Lab areas. We can extend assignment to sets and steps but this requires custom field set up (which we look at in the video). In this video we first put this in context by looking at some of the key Quality Center concepts for planning and execution; the Plan where we define cases, with steps and group them into folders. and the Lab where we create sets which link to a number of cases from the plan area. With this concept we can then link the folders, that contain...

A healthy test management system requires maintenance. When I say healthy I mean a system that gives you accurate reports, doesn’t add a significant overhead to the testers work load and accurately mirrors your real world process. Rarely does a company implement a test management tool then leave it untouched for years. You’re aiming to improve over time and get more out of your tool as your experience grows. You should be looking to make continuous improvements to the process and tool over time. First it’s best to take a step back and look at what it is you want to achieve. Consider your goals. Why are you using a test management system? “To track the tests we’re running” is...

It’s well known that keeping track of results from testcases against builds, configurations, environments, etc can become quite difficult to manage. It’s one of the reasons we usually implement test management tools. These tools enable us to log our results against these different aspects of our testing and then quickly produce traceability reports to show our coverage. It’s just that the permutations and combinations can become quite difficult to track, even with the right tools. If we have just 1 testcase, which we need to run against 2 platforms, 2 operating systems along with three configurations relevant to our application we already have 12 permutations. That’s 12 permutations for just 1 testcase. And with this example we’re not even considering...