Top Down Test Case Design can be used to break our test case into logical units. This process is also known as decomposition: starting at the highest level and then breaking things down into sub-pieces.
Top Down Test Case Design is useful when having a base of test cases that need to be maintained from build to build. For instance, if a change in the application broke one of our test cases, we would need to find the broken part and, in the best case, just change that part. Sometimes there are radical changes and we might need to re-record the entire test case. But, when the changes are not too extreme, Top Down Test Case Design allows us to isolate the issues because we are dealing with sub-pieces. And these pieces can be shared between test cases, similar to methods in a programming language.
The Top Down Test Case Design is also useful for establishing standards in the test case creation process. For example, a new person joining the team will find test cases that are easy to understand, follow and fix, if needed. Let’s consider a very simple test case. A user logs in, does a set of actions and logs out. In the enterprise world that set of actions could, for example, be an invoice creation process composed of the steps search orders, select an order, click on create invoice, fill out invoice and create the invoice. In the e-commerce world it might be a purchase process that is divided into browse catalog, add item to cart, click on checkout, fill out required info and submit the purchase.
Let’s go with the enterprise example: Log In, Invoice Creation Process and Log Out. Figures 1 and 2 show this in CloudTest as compared to LoadRunner, which you may be familiar with.
In CloudTest terms, the test cases are called clips (scripts in LoadRunner terms) and the clips can be contained (nested) in other clips as shown in Figure 2, where the main clip S1: Invoice Creation contains three nested clips: Log In, Invoice Creation Process and Log Out. These three “sub-pieces” of the main clip contain more steps as shown below. These steps are commonly known as transactions. There are no restrictions to the level of nesting for any element in the clip, including nested clips. One important thing to noteis that nested clips can be in any other clip, which means they can be “shared”. So, if we make a change to any of the nested clips that change will be reflected in all the clips that have it nested. This is key because it enables more durable and maintainable test cases, and is not typically supported in other testing platforms.
Figure 3. Top Down Test Case Design with CloudTest.
The blue symbols above are transactions and the transactions can contain any number of pages as shown in Figure 4. Figure 5 shows what is inside a page; the green icon is the HTML document and the rest of the icons are the page resources. Figure 4. A transaction might have several pages. Figure 5. A Page.
Clips, when nested, can have input and output properties, just as if they were methods. This allows clips to pass property values. For instance, the clip Invoice Creation Process might need the user name and password from the parent clip. For passing this parameter, we double click on that clip and set it up as shown in Figure 6 under Property Sets Before.
Figure 6. Property Sets Before.
Figure 8. Different Operations.
All of the above helps to ensure more durable, easy to understand and maintainable test cases. If a piece (a nested clip) changes we can easily update it and it will be reflected in all other clips using it. It is also very easy to change the flow by simply dragging and dropping any clip element. The steps can be broken into even more pieces if it makes sense. We can also keep doing the middle part, Invoice Creation, by adding repeats, and log out when completed, as shown in Figure 9.
Figure 9. Common way to break down the test case.
Top Down Test Case Design is something to consider as a best practice in any organization. The illustration above shows the most common design, where the 100 repeats were variable depending on the test plan.
Prior to working at SOASTA I worked as a Performance Testing Engineer for a multi-national company with businesses in aviation, appliances, energy, finance, rail and water, among others. In any given division there were about 30 different applications that required testing from build to build. Having standards in a changing environment is essential for the success of performance testing operations, and to meet SLAs in a timely manner. These standards enabled our performance testers to easily modify only the parts that changed, increasing the durability and maintainability of the test cases, as well as enabling more seamless handoffs to other Performance Testing Engineers when needed.
About the Author