Jazz Library Automated Test Deployment with the Rational solution for Collaborative Lifecycle Management – Part 2
Author name

clm,elm,test-management,workflow-management,rational-quality-manager,rational-requirements-composer,rational-team-concert

Mon, 26 Mar 2012
5 min read
0

Automated Test Deployment with the Rational solution for Collaborative Lifecycle Management – Part 2

Marc van Lint, IBM The Netherlands B.V.
Last updated: February 1, 2012
Build basis: Rational solution for Collaborative Lifecycle Management 3.0 and Rational Functional Tester 8.2

Things have changed in the Rational solution for Collaborative Lifecycle Management (CLM). The new architecture and new licenses of the release 3.0 software provides an even tighter integration across the disciplines. Teams can benefit from these changes.

This article describes how the test community can benefit from the development features provided by Rational Team Concert (RTC). Next to the planning and defect management, we can now utilize other features of RTC like code management and the build engine. This becomes especially important when customers go beyond the level of self contained scripts and use the power of object oriented programming and maximize code reuse. The technical tester will appreciate this approach.

A successful test depends on the deployed application and the deployed test. This approach gives full control over the deployment of test scripts. The development is done by the team sharing resources and code. Deployment of test ware is done via automation in a fully controlled way.

The chosen approach is described with Rational Functional Tester (RFT), but it’s equally valid for Rational Performance Tester (RPT), Rational Tester for SOA Quality or other Eclipse based products.

We assume basic knowledge of installation and usage of the CLM portfolio and RFT.

All of these are provided as examples and to give you a jump start. Things are often different in a production environment and this information has to be adapted to that environment.

Introduction

This article describes the technical steps to setup an environment for concurrent automated test development and delivery. These steps are examples and should be changed accordingly. After implementation of these steps there are two types of builds available:

  1. Personal Build – To validate the code written in the context of the project. (E.g. junit test can be implemented, code checkers and validation of dependencies)
  2. Integration Build – To integrate the code supplied into the build.

Both types of build are discussed at the end of this document.

  • Module 0 – General Preparation
    General preparations like project, environment, users and licenses, sandboxes, streams and components.
  • Module 1 – Build Engine
    Actions needed to define a Build Engine
  • Module 2 – Build Master
    Actions needed to define the working environment for the Build Master
  • Module 3 – Test Engineer
    Action needed to define the working environment for the test engineer.
  • Module 4 – Automation
    The hidden gem of the story.

Module 0 – General Preparation

Installation

For this scenario we install the following products:

  1. A Jazz server
    Rational Requirements Composer
    Rational Team Concert
    Rational Quality Manager
    Appropriate users and licenses
  2. A Build Engine
    Jazz Build Toolkit from RTC-full
    Rational Functional Tester
    RTC-client as a plug-in
  3. A client machine
    Rational Functional Tester
    RTC-client as a plug-in
    A supported browser e.g. Firefox or Internet Explorer
  4. A RFT agent machine
    Rational Functional Tester

For demonstration purposes this can be done on one machine, but for production these applications are deployed on various servers and clients.

It’s allowed to install Rational products on multiple computers. The usage is bound by an appropriate license and authorization. The licenses needed in our scenario are RQM Quality Professional and a RTC Developer license.

In some occasions organizations will not install products on the Build Engine. All needed software should be loaded from the (source) code server. That means that a serious number of (non-)binary files are loaded before actually starting the compilation. Because RTC manages all the needed code, an old situation can be re-created.
To keep it simple, we choose for the option to install RFT on the build server to overcome this problem. Clearly you have to administer which RFT releases are used.

Users and Roles

This process is collaboration of multiple roles. We’ve identified the following roles and users:

Role
User
Sandbox
Repository Workspace (Public)
Licenses
Comments
Build Master buildmaster C:AutoQbuildmastersandbox Build Master Workspace RTC Developer The person responcible for the build and build-scripts.
Build Engine build C:AutoQbuildsandbox Build Engine Workspace RTC Build System The userid which does the actual execution of the integration build.
Tester tanuj C:AutoQtanujsandbox Test Stream Workspace RQM Quality Professional, RTC Developer A tester using RQM, RFT and RTC to create test ware and automated tests

The sandbox of the tanuj user is the workspace area created and used by Rational Functional Tester with the embedded Rational Team Concert plugin.

Jazz Project

We have created a sample Project area called AutoQ. This project area consist out of RRC, RTC and RQM. Add the various users to the AutoQ with sufficient rights and correct process roles.

When starting the Eclipse client with one of these users you have to connect to this Project Area – AutoQ.

Creation of Sandboxes

Create the directories: 

  C:AutoQbuildmastersandbox  C:AutoQbuildsandbox  C:AutoQtanujsandbox

Take care that you switch to the right workspaces when restarting the Eclipse client or RFT.

Define Shared Resource Location

Define a shared resource location for the test scripts to be executed.

Where: Rational Quality Manager
Userid: tanuj

  1. Access RQM via the browser, logon as tanuj
  2. Select Admin > Manage Project Properties
  3. Select Shared Resource Locations
  4. Select Add Resource Locations
    Use: C:RFTSHARED

Make sure you have the correct rights to read and write on these locations.

Shared Resource Locations
Figure 1: Definition of Shared Resource Location.

Initial Work Items

To deliver code you must have Work Items attached. This way you can ‘trace’ the change. Create two work-items for the current sprint.

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: buildmaster

  1. Start the Eclipse client using
    the C:AutoQbuildmastersandbox workspace,
    with the buildmaster user,
    connected to the AutoQ project.
  2. Create work item “Change Build Source” – assigned to buildmaster
  3. Create work item “Change Test Source” – assigned to tanuj

Work Item
Figure 2: Initial Work Items planned for current sprint

Creation of Test Stream and Components

The code we use will be part of the Test Stream. In this stream there will be two components:

  1. Build Sources Component – Containing all the sources for the build
  2. Test Sources Component – The actual test ware sources and files

The following steps are to define this structure:

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: buildmaster

  1. Start the Eclipse client using
    the C:AutoQbuildmastersandbox workspace,
    with the buildmaster user,
    connected to the AutoQ project.
  2. On Source Control use contextual Menu New > Stream
  3. Enter the name Test Stream
  4. At the Components pane New
  5. Enter the name Build Sources Component
  6. Select OK
  7. At the Components pane New
  8. Enter the name Test Sources Component
  9. Select OK
  10. Select Save

Module 1 – Build Engine

This module will focus on the creation of the Build Engine Workspace on the server.

Creation of Build Engine Workspace

The Build Engine Workspace is the repository workspace of the build user. This workspace will be used when running a integration build.

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: build

  1. Start the Eclipse client using
    the C:AutoQbuildsandbox workspace,
    with the build user,
    connected to the AutoQ project.
  2. Contextual Menu on My Repository Workspaces
  3. Select New > Repository Workspace…
  4. Expand AutoQ (flow with it)
  5. Select Test Stream
  6. Key in Build Engine Workspace
  7. Select Next
  8. Select Next
  9. Select Public
    You can always change the visibilty to Private when this is more applicable.
  10. Select Next
  11. Select Finish
  12. Select Finish to load

Module 2 – Build Master

The build environment is maintained by the Build Master. The definitions are done in RTC. The files needed for a build are maintained by RTC is a separate component.

  1. Build Engine – Build Engine definition in RTC.
  2. Build Definition – How the builds are run.
  3. Build.xml – The actual ANT build script.
  4. Properties file – Some definition of external variables.

Creation of Build Master Workspace

The Build Master Workspace is the repository workspace of the buildmaster user. This workspace will be used when running a integration build.

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: buildmaster

  1. Start the Eclipse client using
    the C:AutoQbuildmastersandbox workspace,
    with the buildmaster user,
    connected to the AutoQ project.
  2. Contextual Menu on My Repository Workspaces
  3. Select New > Repository Workspace…
  4. Expand AutoQ (flow with it)
  5. Select Test Stream
  6. Key in Build Master Workspace
  7. Select Next
  8. Select Next
  9. Select Public
    You can always change the visibilty to Private when this is more applicable.
  10. Select Next
  11. Select Finish
  12. Select Finish to load

Creation of Build Engine

The Build Engine is the machine doing the actual build. In this machine an ‘agent’ program is started. It listens to the RTC server if builds are requested. The actual execution of the build is done by the build user.

To create a Build Engine

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: buildmaster

  1. Start the Eclipse client using
    the C:AutoQbuildmastersandbox workspace,
    with the buildmaster user,
    connected to the AutoQ project.
  2. Contextual menu on Build Engines folder
  3. Select New Build Engine
  4. Select Next
  5. Key in for ID: AutoQ (Change Management) engine
  6. Select Finish
  7. Select Save

On the Build Engine a agent program must be started. This is defined in a small script. The goengine.bat is the file with the following contents. 

  set EngineName="AutoQ (Change Management) engine"  title Build Engine: %EngineName%  set PATH=%PATH%;"C:Program FilesIBMTeamConcertBuildbuildsystembuildengineeclipse";  color 0C  cls  jbe -vm "C:Program FilesIBMTeamConcertjdkbinjava" -repository https://<server>:9443/ccm -engineId %EngineName% -userId build -pass build -sleeptime 10
*NOTE1: I’m not using a encrypted password-file here. It’s possible.
*NOTE2: Replace <server> by your own fully qualified name.

Start the goengine.bat agent program in the directory C:AutoQbuildstart. By refreshing the Build Engine in the Eclipse client, the message The Build Engine process may not be running should disappear.

Build Engine Message
Figure 3: The Build Engine message that the machine may not be running.

Creation of Build Definition


Additionally a Build Engine Definition is created in RTC to make the external machine known in RTC.

A Build Definition in RTC defines how RTC will handle and initiate the build on the Build Engine.

Where: Eclipse Client Work Items perspective – Team Artifacts View
Userid: buildmaster

  1. Contextual menu on Builds folder
  2. Select New Buid Definition…
  3. Select Next
  4. Key in for ID: AutoQ (Change Management) build
    Keep the Ant – Jazz Build Engine selected.
  5. Select Next
  6. Select Jazz Source Control
  7. Select Next
  8. Select Next
  9. Select Finish

Complete the Build Definition with

  • In the Overview-tab:
    1. In the Supported Build Engines pane – Select Edit
    2. Select the AutoQ (Change Management) engine
    3. Select OK
  • In the Schedule-tab:

    If you wish you can repeatingly start a builds.

  • In the Jazz Source control-tab:
    1. In the Build Workspace pane – Select Select
    2. Key in *
    3. Select Build Engine Workspace (Build)
    4. Select OK
    5. Select OK to the useful warning message
    6. In the Load Options pane – Select Create
    7. Enter Load directory: C:AutoQbuildloaddir
    8. Select Delete directory before using
    9. In the Accept Options pane
    10. Select Accept latest changes …
      Important – accept newest changes.
    11. Select Build only if …
      Important – create only a build when changes are supplied.
  • In the ANT-tab:
    1. In the Build File and Targets pane – Create
    2. Enter Build file C:AutoQbuildloaddirBuild Projectbuild.xml
      We will create it later.
    3. In the Ant Configuration pane
    4. Ant arguments -verbose
      Maximize messages for debugging.
    5. Java home C:/Program Files/IBM/SDPRFT82/jdk
      Important! Use the right, if possible the same Java as supplied with RFT. RTC-java is probably an other level. Furthermore the pointed directory might be different for your installation.
    6. Select Save to the Build Definition

Creation of build.xml script

The build.xml (fixed filename) is the hart of the actual build process. It defines which ANT steps are executed.

Where: Eclipse Client – Java perspective
Userid: buildmaster

  1. Start the Eclipse client using
    the C:AutoQbuildmastersandbox workspace,
    with the buildmaster user,
    connected to the AutoQ project.
  2. When needed switch to the Java perspective.
  3. Create General Project Build Project
    The RTC-control will be added later.
  4. Create new file build.xml
    This file-name is important.
  5. Ctrl-Space
  6. Double click the build-template
  7. Insert the echo message line like 
          <target name="default" depends="depends" description="description">  		<echo message="Build Started" />      </target>
  8. Save the file

The current location of the build.xml is at 

  C:AutoQbuildmastersandboxBuild Projectbuild.xml

The provided script is a starting point and should be adapted to the needs of the organization by the Build Master.
Several things are done by this build:

  1. Get variables and general tasks
  2. Clears directories
  3. Loads latest and greatest source files
  4. Compiles
  5. ZIP the results
  6. Publish links and other related files
  7. IF it’s an succesful integration build
    1. It tags it “ready_for_use”
    2. Copies the workspace files to the final shared location

The complete example build.xml file can be found here.

Creation of Properties Script

In the similar manner we have to create the build-global.properties file. This enables to re-use the script with different properties (e.g. for a different release of RFT).

Where: Eclipse Client – Java perspective
Userid: buildmaster

  1. Create new file build-global.properties

A sample content can be: 

  ##  company=IBM Nederland  author=Marc    build.xml=build.xml  jazztasks.xml=C:/Program Files/IBM/TeamConcertBuild/buildsystem/buildtoolkit/BuildToolkitTaskDefs.xml  zipfile=rftoutput.zip    env.IBM_RATIONAL_RFT_ECLIPSE_DIR=C:/Program Files/IBM/SDPRFT82  env.IBM_RATIONAL_RFT_INSTALL_DIR=C:/Program Files/IBM/SDPRFT82/FunctionalTester/bin    jar.jdk=C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/vm.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/annotation.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/beans.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/java.util.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/jndi.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/logging.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/security.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/sql.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmorb.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmorbapi.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmcfw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/rt.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/charsets.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/resources.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmpkcs.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmcertpathfw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmjgssfw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmjssefw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmsaslfw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmjcefw.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmjgssprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmjsseprovider2.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmcertpathprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ibmxmlcrypto.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/management-agent.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/xml.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/jlm.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/javascript.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/CmpCrmf.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/dnsns.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/dtfj-interface.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/dtfj.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/gskikm.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/healthcenter.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmcmsprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmjcefips.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmjceprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmkeycert.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/IBMKeyManagementServer.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmpkcs11impl.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmsaslprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/ibmxmlencprovider.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/jaccess.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/JavaDiagnosticsCollector.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/JawBridge.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/jdmpview.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/localedata.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/rational_ft_bootstrap.jar;C:/Program Files/IBM/SDPRFT82/jdk/jre/lib/ext/xmlencfw.jar;  jar.rftmain=C:/Program Files/IBM/SDPRFT82/FunctionalTester/bin/rational_ft.jar  jar.rft=C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.corecomponents_8.1.1.v20110519_1709.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.autbase_8.1.1.v20110224_0707.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.playback_8.1.1.v20110526_1417.jar;C:/Program Files/IBM/IBMIMShared/plugins/org.eclipse.tptp.platform.models_4.6.100.v201005271112.jar;   jar.rftto=C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.domain_8.1.1.v20110531_1419.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.clientbase_8.1.1.v20110609_1200.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.domain.html.dojo.testobjects_8.1.1.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.domain.testobjects_8.1.1.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.html.sapwebportal.testobjects_8.1.1.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.ibm.rational.test.ft.sdk_8.2.0.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.rational.test.ft.sap_8.1.0.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.rational.test.ft.siebel_8.1.0.v20101014_1440.jar;C:/Program Files/IBM/IBMIMShared/plugins/com.rational.test.ft.wpf_8.1.0.v20101014_1440.jar;

The complete build-global.properties file can be found here. You can get the corresponding jar-files from the properties of the RFT project. Open Java Build Path, Libraries tab and open the hierarchy. You will note that the numbering V2011.. will change for every RFT release.

Share the Build Project

All test-build ware is brought under control of RTC. This enables to have multiple people improving these scripts and data.

You might have to add the Package Explorer to your Functional Test perspective.

Where: Eclipse Client – Java perspective
Userid: buildmaster

In the Package Explorer

  1. Contextual menu on root of the Build Project
  2. Select Team > Share Project
  3. Select Jazz Source Control
  4. Select Next
  5. Select Build Sources Component
  6. Select Next
  7. Select Finish

    Directly the pending changes are populated with the files from the project.

    Pending Changes for the Build Stream
    Figure 4: Initial Pending Changes for the Build Stream.

  8. Contextual menu on Share Project > Deliver
    This will work only for initial share. Follow on deliver actions must have associated work item.

Module 3 – Test Engineer

This scenario assumes that there are multiple test engineers working on code. Each test engineer has it’s own sandbox (local workspace). Works on his tasks as planned and assigned in RTC. Also the task for changes and updates to test scripts are processed in the same way as the ‘normal’ coding changes.
The test engineers are working independent from the Build Engineers.

In this case we use the user tanuj as used in the various Rational demonstrations. Make note that tanuj needs a RTC Developer license to do the development of code maintained by RTC.

Create Test Stream Workspace

This workspace is the server work area for the tester. It’s also the area where the build engine runs the personal build. This means this area must be PUBLIC!

Where: Eclipse Client Functional Test perspective – Functional Test Projects
Who: tanuj

  1. Start Rational Functional Tester
    the C:AutoQtanujrftsandbox workspace,
    with the tanuj user,
    In the Work Items Perspective, connected to the AutoQ project.
  2. Contextual Menu My Repository Workspaces
  3. Select New > Repository Workspace
  4. Expand AutoQ
  5. Select Test Stream
  6. Keyin name Test Stream Workspace
  7. Select Next
  8. Select Next
  9. Select Public
    Having the visibility set to pulic enables the build user to run a your private build in this workspace.
  10. Select Next
  11. Select Finish
  12. Select Finish to load

Share the Test Project

You might have to add the Package Explorer to your Functional Test perspective.

Where: Eclipse Client Functional Test perspective – Functional Test Projects
Who: tanuj

  1. Start Rational Functional Tester
    the C:AutoQtanujrftsandbox workspace,
    with the tanuj user,
    In the Work Items Perspective, connected to the AutoQ project.
  2. Create the TestProject project
    No space allowed in naming!
  3. Create your smoke test called Script1

Where: Eclipse Client Functional Test perspective – Package Explorer View
Who: tanuj

In the Package Explorer

  1. Add the Package Explorer view to the RFT Eclipse IDE
    Window > Show View > Package Explorer
  2. Contextual menu on root of the RFT project TestProject
  3. Select Team > Share Project
  4. Select Jazz Source Control
  5. Expand Test Workspace
  6. Select Test Sources Component
  7. Select Next
  8. Select Next
  9. Select Finish

    Directly the pending changes are populated with the files from the project.

    Pending changes
    Figure 5: The very important Pending Changes view in the Eclipse client. Here we can see which changes we have created and which incomming changes are done by others.

  10. Contextual menu on Share Projects Deliver

Usefull to know is that it’s normal to have RTC manage only code and not binaries of code like class files!

Check in the code

Check in the code means copy the code to your personal server side repository-workspace. This way you can initiate a private build request to validate the code.

Checking of the code in pending changes view
Figure 6: Checking of the code in pending changes view.

Complete the code

Completing means that you finalize and close a change-set. No new changes can be added to this set.

Run a Personal Build

A personal build is done on the server side with server side settings based on the users repository workspace. It will not impact the build status (e.g. on fail).

When code is checked-in we can request a personal build.

  1. Select Build Options twisty
  2. Select Personal Build
  3. Select your Repository Workspace
  4. Select Submit

Request for a personal build.
Figure 7: Request for a personal build.

Definition of a Test Case and Test Script

Where: Browser to RQM
Who: tanuj

When the Integration Builds are run the test scripts are available in the shared location. We can import the scripts from the shared location:

  1. Select Construction > Import Test Scripts
  2. Select Browse
  3. Double Click TestProject
  4. (Multi)Select the scripts
  5. Select Import

Now you can create Test Cases on the traditional way with these imported Test Scripts.

Scheduling a Test

The final piece of automation is the schedule running of automated tests. In RQM 3.0 we have the ability to schedule a test execution triggered by time of finishing of a build.

Where: RQM Web interface
Who: Testmanager

  1. Menu Execution
  2. Select Create Execution Schedule
  3. Fill in the appropriate values
  4. Select the test steps to be added to the schedule.

Figure 8: A Execution Schedule definition in RQM.

Because the initiation is done by the server, there is no need to keep the browser with the RQM access open. One can close and go home. Or continue working with other activities and when the dashboard is updated, one can interrogate the test results based on the latest updated automated tests.

Module 4 – Automation

Essential for the parallel development, scalability, gathering of metric and many other aspects is the level of automation Rational can provide across the disciplines. Again this is just a sample and can be seen as a starting platform. Other levels of automation can be obtained by utilizing Rational BuildForge technology combined with Rational Quality Manager Test Lab Manager.
A total different level of automation is the gathering of metrics or the generation of complete status documents based on the information available in the Jazz environment, covering all disciplines.

Let’s focus back on this first level of automation.

Run a Integration Build

The integration build is the build which integrates all the work of all testers and developers. The build will load all components, compile the sources and deploy these results to a shared location. The build will generate a log-file, which will be available via the RTC user interface.

One can start a build interactively or using a scheduled build.

  1. Interactive

    In the periode of developing the build code one can request an integration build by the “request build” icon in the Build view.

  2. Scheduled

    In the build definition, in the schedule-tab the Build Master can specify when the integration build has to start. This can be at a high frequency. An actual build will only be run when changes are supplied (when proposed settings are done in de build definition).


    Figure 9: The RTC Schedule of a build to start a build at certain moments in time.

Because the build script is nothing else than a simple echo it probably will work. Replace the build.xml with the provided example.

Where: Eclipse Client Work Items perspective – Team Artifacts View
Who: buildmaster

Creation of RQM-RTC link

A feature unique to the Rational tool set is the awareness of builds. A user or a process can act on the changing status of a build. Defects and logs can reference specific build.

RTC builds can be made visible in RQM. This is documented here. When a build has completed it can trigger consecutive builds for testing. When such a build is complete a test execution can be initiated.

For more information

Table of references

Various names, acronyms are used throughout these two articles. Here’s a quick list of them.

Name
What
Jazz Project The Jazz Project Name
Name: AutoQ
Stream An artifact that holds the master copy of a source file base; it is a server based object used for sharing files within a team.
Repository workspace A workspace that holds a developer’s private copy of the source file base; it is a server based personal space where local file changes are checked into, and changes from and to the target stream are accepted and delivered.
Component A grouping of related artifacts in a stream or repository workspace. A component can contain any number of folders and files. Streams and repository workspaces are partitioned in components.
Change set A repository object that collects a related group of file, folder, and component modifications so that they can be applied to a flow target (workspace or stream) in a single operation.
Sandbox An area on a file system where a developer can modify and test source code in isolation, before returning it to the source control component and sharing it with other developers. A sandbox can have one or more repository workspaces loaded at any time. It can be an eclipse workspace. An eclipse workspace can consist of componentns of several loaded repository workspaces. More…
Build Engine The machine running the build process
Name: AutoQ (Change Management) engine
Build Engine Workspace Repository workspace of the build user
Build Project Build Project in the Eclipse environment
Test Stream A stream is a repository object that includes one or more components.
Name: Test Stream
More…
Build Sources Component …
Name: Build Sources Components
More…
Test Sources Component The container where the Eclipse project is stored in
Personal Build A build which does not influence the build results. It runs on personal files on the repository workspace.
RRC Rational Requirements Composer
RTC Rational Team Concert
RQM Rational Quality Manager
RFT Rational Functional Tester

About the author

Marc van Lint started in 1986 at IBM as a schoolar. He was active for 18 years in the Product Lifecyle Management branch of IBM. In 2005 he continued his career at IBM Rational. His prime focus was to achief Quality in the software delivery process at the various customers. He presents his visions to customers and help them to implement their improvements. He contribues frequently to the community by publishing and maintaining his own website. He’s co-author of the IBM Press book “Software Test Engineering with IBM Rational Functional Tester – The Definitive Resource”.
He can be contacted at marc_van_lint@nl.ibm.com.

Copyright © 2012 IBM Corporation

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Mon, 26 Mar 2012