Rational Quality Manager Test Case Execution Record video series

Test Case Execution Records really are the heart and soul of Rational Quality Manager.  TCER’s are what make test case reuse possible across multiple environments and releases.  I talked a bit about them in my post on Keywords and Channels.

TCER’s are also probably the most misunderstood aspect of Rational Quality Manager.  You can get by to a point ignoring execution records, but until you get a grasp on TCER’s, you probably aren’t utilizing RQM to its potential.

Dan Chirillo – a very skilled IT Specialist in the IBM Rational services organization – has been working on a video series that very clearly explain what a Test Case Execution Record is, why it is so important, and how to use it effectively.  This is a work-in-progress, but he has four of his planned six videos out on YouTube.  I highly recommend you take the time to watch them.  Even experienced RQM users will find something useful in these videos.

Part 1: Understanding and Managing Test Case Execution Records
This video is the first in a series of videos aimed at explaining how you can use test case execution records to plan, execute, and report on testing. Part 1, Why You Need to Understand and Manage Test Case Execution Records, introduces test case execution records and explains why they are so important.

Part 2: Exploring Test Case Execution Records
Exploring Test Case Execution Records explores existing test case execution records and introduces different ways to generate them.

Part 3: Generating Test Case Execution Records for a Single Test Case
Generating Test Case Execution Records for a Single Test Case shows how to:

  • Set the iterations, owner, and test environments to generate test case execution records for.
  • Confirm that the execution records were added to the test plan and are reflected in the execution status report.
  • Determine how many tests are planned for a single iteration by filtering the test case execution records list in a test plan.

Part 4: Generating Test Case Execution Records for All Test Cases In a Test Plan
Generating Test Case Execution Records for All Test Cases In a Test Plan shows how to:

  • Select which of a test plan’s test cases to generate test case execution records for.
  • Set the iterations and test environments for the execution records.
  • Confirm that the execution records were added to the test plan and are reflected in the execution status report.
  • Determine how many tests are planned for a single iteration by filtering the data in the execution status report.

Parts 5-6, coming soon, will examine generating test case execution records without a test plan, iteration, or test environment, and show how to run test case execution records.  I’ll update this post with links when they become available.

 

 

Advertisements

Working with REST interfaces in Rational Integration Tester

REST (Representational State Transfer) is a simple, stateless architectural style typically running over HTTP which is common among web service implementations.  REST depends on the use of standard methods such as GET, POST, PUT and DELETE. Until recently, there wasn’t an accepted standard for how REST services were defined. There was no service specification that Rational Integration Tester could synchronized to as an external resource. Web Application Description Language (WADL) is a specification recently ratified by the W3C for defining REST services. WADL models the resources provided by a service and the relationships between them.  We will look at WADL in a bit, but it is important to understand how to define Rational Integration Tester REST schemas manually for a few reasons. First of all, you really need to understand what’s happening under the hood to understand how RIT uses the schema later. Secondly, WADL is new enough that many existing REST services do not have WADL specifications. And finally, there are some limitations in Rational Integration Tester’s support for WADL that may mean you need to manually adjust your model after synchronizing.

Creating REST schemas manually

The Login example

Forget about WADL for a moment. Let’s look at what a simple REST implementation might look like as an example. Let’s say the fictitious JKE Bank has a REST system that authenticates users of its online system. The REST URI for authentication looks like this:

http://services.jkebank.net/user/<username>?password=<password>

Yes, I realize passing the password as a query parameter is highly unsecure, but play along with me, please. It illustrates my point well. Julie Brown is an account holder at JKE and she uses her pet cat’s name, Snuggles, as her password. The request to authenticate the user jbrown might look like this:

http://services.jkebank.net/user/jbrown?password=snuggles

If you simply record a request message to this URL with Rational Integration Tester, how should the elements of the URL be interpreted? What constitutes the “operation” of this system? If you want to create tests for different users, you will want to create data-driven tests and stubs. How can you get RIT to substitute values from a test data file for the “jbrown” element of the URL? The answer lies in a REST schema definition in the Schema view of the Architecture School. REST schemas enable you to define which elements of the URL should be parametrized and which ones should be considered fixed values. To make the process of defining the schema easier, RIT provides the ability to import a URL template.

Once again, let’s use the JKE example to illustrate. Let’s say you have defined an HTTP connection in the logical view and associated it to a physical resource representing your web server. You record the request and you see something like this:

Recorded events for login of user jbrown

Recorded events for login of user jbrown

If you select those two events and attempt to save them as unit test with a simple data set, you will see where the problem comes in.

First Attempt at a Data Driven Test

First Attempt at a Data Driven Test

You would want the username to be a column in your data file, but only the password has been identified as a parameter.  So if you go ahead with this test as it is, this test can only be used for this one username – jbrown.  Furthermore, notice that the operation has been identified as jbrown.  In REST terms, jbrown is the unique ID for the resource.  The operation should really be “user” – the element of the URI just before the unique ID.

This illustrates why Rational Integration Tester needs a little coaching in order to properly identify the fixed versus parameterized elements of the URI.  That coaching comes in the form of a REST schema which is created in the Schema Library view of the Architecture School perspective.  The simplest way that I have found to do this is to follow the steps below.

Enhancing the REST schema

Switch to the Schema Library view of the Architecture School perspective and select the REST schema type on the left. Here you see that RIT did create a schema when you attempted to create a test from the recorded events, but it needs some human intelligence applied to really make it useful.

Initial REST Schema for JKE User

Initial REST Schema for JKE User

First of all, the schema name is extracted from the hostname of the physical resource that was recorded.  That’s not entirely useful, so we will change that to “JKE Services”.

Next, let’s edit the template for the URL by selecting it and clicking the edit icon.

Initial template for the JKE User URL

Initial template for the JKE User URL

On the left side, you see the URL path segments.  On the right, you see any query segments.  The password part is pretty easy – it’s a pretty fair bet that anything that appears as a query parameter value is something you will want to parameterize.  That’s why you see the curly braces around the password value.

But since RIT has only seen one URL, it has to make some guesses on what the URL represents.  But the best guess RIT can make is that all elements of the URL are fixed. You can edit the schema a bit to make jbrown a parameter rather than a fixed element. You can also rename that parameter to something more descriptive of what it really represents, which is “username”.

Username parameter

Username parameter

The last thing you probably want to do is to change the template name from jbrown to something more appropriate like “user”.

Saving the test – Redux

With this schema in place, when you save the recorded events as a data-driven test, both the username and password are recognized as parameters and the operation name is identified as user.

Updated Data Driven Test

Updated Data Driven Test

jbrown will be placed into the test data file as a parameter along with the password.

Test Data Preview

Test Data Preview

The retrieve accounts example

Next, let’s look at the REST request that retrieves Julie’s account information:

http://services.jkebank.net/user/jbrown/accounts

If you record the request and its response then attempt to save the events as a data-driven test, you will find again that the username element of the URL will not be identified as a parametrized value.  I will use a slightly different procedure to create this template to demonstrate how you can import a URL template.

Creating the REST template for accounts

Copy the URL of the operation from the Header section of the Events View in Recording studio. In the Schema Library, use the Import URL Template tool and paste your URL into the dialog and click OK.

Initial Accounts Template

Initial Accounts Template

You can see here that RIT has done a rather curious thing.  In the absence of a query parameter, RIT makes the assumption that every element of the URL must be a parameter. That’s not what you wanted either but again, you can edit the schema such that the username is the only parameter.

Updated Accounts Template

Updated Accounts Template

Now what about that WADL…

Now, all that is good to know, but I’m one who likes to avoid extra work if I can. So let’s get back to WADL…

As I mentioned earlier, WADL is relatively new and I have found that, although there is a W3C Specification for WADL, people interpret and apply the spec in various ways.  Let’s take a look at ways we could represent the JKE interfaces in WADL.

Here’s how I think these services would be represented in WADL:

JKE Banking Fully Structured WADL

JKE Banking Fully Structured WADL

I mentioned some limitations in Rational Integration Tester’s WADL support at the beginning of this post.  One of the limitations is that RIT doesn’t support parameters at the resource level yet – that’s something we expect in a future release.  So I’ve reorganized the resource hierarchy a little in the following iteration of the WADL file:

Restructured JKE WADL

Restructured JKE WADL

Now go to the Synchronization view of the Architecture School perspective in RIT and add a WADL reference to the external WADL file.  This can be done with the Web > WADL toolbar action or the Add a new item to the view toolbar action.  When you synchronize, you will see the following elements.

Synchronized WADL

Synchronized WADL

Let’s browse the model artifacts to see what was created by going to the Schema Library.

Schema Library for WADL

Schema Library for WADL

RIT left the schema untitled and uses a default name for the schema template of “url name”.  This is something you should probably change to be more human friendly so name the schema JKE, the first template user and the second accounts.

Updated Schema Library for WADL

Updated Schema Library for WADL

In the Logical View, the endpoint and two operations were created.

Synchronized elements in the Logical View

Synchronized elements in the Logical View

That first operation name looks odd.  This is another limitation of the RIT support today.  If the last element of the resource URL is a parameter, RIT doesn’t really know what to do about a name for the operation.  You can rename the operation to something more appropriate like user.

Now open the user operation properties.

User operation properties

User operation properties

Several attributes such as the operation pattern and method were imported as well as the request schema.

One more limitation – My WADL had specified a mediaType of application/json but the schema for the Reply has been set as Text.  This should be changed by browsing to JSON > Object.

Summary

Rational Integration Tester has some pretty powerful support for REST testing and virtualization.  The nature of the beast of REST typically means you will need to do some coaching in the schema library to get RIT to understand the meaning of your application resources.  RIT 8.5.1 has introduced support for WADL file synchronization.  Although this support is evolving, there is a lot of value in using WADL to jump-start your model creation.

Automating the creation of the Rational Integration Tester model

In previous posts, I’ve looked at the Rational Integration Tester model and lightly discussed how you create the elements manually. You definitely need to understand how to do this, but it is also important to understand that you can oftentimes have RIT do much of the work for you. The amount of work that can be automated will depend on the messaging technology you are using and how thoroughly your interface specifications have been defined.

An external reference is a special type of Infrastructure component that enables you to synchronize your Rational Integration Tester project to external resources. WSDL, webMethods Integration Server, TIBCO BusinessWorks Project or Design Time Library, SAP System, and SCA Domain (Oracle Fusion) are all external resources that can be synchronized to your project.

Let’s use a WSDL file as an example. WSDL stands for Web Services Description Language. It is a special XML file that provides the description of the endpoints, operations and even data formats of a web service environment.

Portion of a WSDL file

Portion of a WSDL file

In the RIT Logical view, you can create a WSDL external resource from the toolbar.

Insert WSDL toolbar option

Insert WSDL toolbar option

You can synchronize to a WSDL file on your hard drive, to a WSDL served up by the web service itself or from a service registry.  If you are using a file, you can even just drag and drop your file onto the Logical view canvas. Once you have designated your WSDL, RIT will parse the structure and create logical components and physical resources defined in the file. So if your WSDL defines the operations and the format of the parameters, all those components will be created for you.

Components created in the Logical View by importing WSDL

Components in Logical View

There is another view in the Architecture School Perspective that probably needs to be introduced at this point and that is the Schema Library view. The schema library contains the definitions for all the message formats and schemas of the messages being passed back and forth through your operations. Synchronizing all these data formats from the service specification is not only a huge time saver, it greatly reduces the chances of human error.

Message schema imported into the Schema Library View

message schema

If you examine the details of the operations back in your Logical View, you will find that the schemas in the Schema Library are referenced by the operation’s message exchange pattern.

Operation Message Exchange Pattern reference to schemas

Operation Message Exchange Pattern reference to schemas

Not all schemas are defined in a service specification like a WSDL file. For example, consider a web service or a message bus that passes data in the format of a COBOL copybook. In this case, you would probably be creating the endpoints and operations manually, but you can still import the copybook file to define the message format to RIT.

Copybook Schema

Copybook Schema

Other examples of schemas that can be imported are XSD and DFDL files.

It is also possible to define your own data formats in the case where your data is not defined through any metadata. This is generally done with record layouts and file formats. This is very powerful and enables you to support proprietary or home-grown systems.

Custom Record Layout

Custom Record Layout

But what if your external resource changes? That certainly isn’t out of the question, right? As your web service evolves, you may add parameters, alter the types, add operations, etc. That’s what the Synchronization view of the Architecture school perspective does for you (or “Synchronisation” view, if you are in the UK as our Development team is). From the Synchronization view, you can see what elements of your model have been synchronized from external resources. You can check to see if your model is up to date or if something may have changed in the external resource. You can optionally update your model to correspond to the new state of the external resource.

Synchronizsation View

Synchronization View

Just a quick sidenote here… I mentioned that you have the option in the case of a WSDL to synchronize to a file or a URL or service. It is generally preferable to use the URL of the service or a service registry rather than a file. The reason is that file the Developer gave you last week has lost its connection to the real service as soon as you made that copy. You may do your best to keep RIT synchronized with the WSDL file, but you also need to keep that file in synch with the real world. By referencing the WSDL on the service or service registry, you are working with the version the live service is using.

Synchronizing to external resources is a very powerful way to ensure your model is valid and remains valid. It also can be a huge timesaver. I mean, your Architects and Developers have gone through all that work to define the system specifications, why not use them!