If your peers request for a copy of your Rational Test Project, or you want to share Rational Test Project with the development teams, or you just wish to move your Rational Test Project to a higher specification machine, it's easy to get confused about what's the best way to accomplish this task. Moving Rational Test Projects could be very tricky and can become one of the most difficult tasks to perform if you get stuck. There are several techniques available for moving Rational Test Projects; each of them is meant for a specific situation. In this article we will try to explain the various techniques available for successfully moving Rational Test Projects, techniques which we have found very convenient and less error prone. Let's begin by defining some terms.
A Rational Project created by IBM® Rational Administrator is nothing more than a logical collection of datastores and other related work products targeted for use by developers, requirements managers, and testers. A Rational Project can contain multiple datastores such as a requirements project, change management (defect) database, test datastore, or a Rose model. It's a logical collection of databases and datastores that associates the data you use while working with the Rational product suite. It packages different Rational datastores used by Rational products into one single repository. These datastores are a collection of related assets, for example a test datastore contains test assets, which includes test scripts, suites, datapools, logs, reports, test plans, and build information.
Since a project is a logical breakdown of a similar set of functionality, there can only be one test datastore for each Rational Test Project. The same holds true for IBM Rational ClearQuest and Rational RequisitePro datastores associated with a Rational Project.
As mentioned above, IBM Rational Administrator is a tool used to create a Rational Project. It is a binding tool which helps to create a common project to host artifacts from IBM Rational RequisitePro®, IBM Rational TestManager, IBM Rational ClearQuest®, and IBM Rational Rose® models. All these datastores are linked to a particular Rational Project and thus cannot be referenced across projects. We will be specifically talk about only Rational Test Projects, which thus contain only a test datastore with only test assets produced by a team while working on IBM Rational test products.
Moving Rational Test Projects is not straightforward and requires a step-by-step process. There are techniques which are meant to be used in specific situations. If they are used in the wrong context, the process might not yield the desired results. We will discuss three techniques that our team has used successfully while working on reliability testing using Rational test tools. By sharing these techniques, we hope to help automation engineers who are required to move Rational Test Projects across different locations. This article assumes that you're an experienced software tester and are familiar with Rational test tools.
Technique one: Rational Project initialization
Initialization is a recommended technique for moving Rational Projects. It's the cleanest way to move project assets from one location to another. This technique requires access to the old project environment from the machine where the new project is to be created or transferred. This technique simply creates a new Rational Project from IBM Rational Administrator by initializing a new datastore from an old (original) datastore that already exists. Follow these steps:
- Open IBM Rational Administrator, and select File > New Project.
Figure 1. Selecting a New Project
- Provide the project name and location.
- Select Configure Project Now and click Finish.
Figure 2. Finishing the initialization
- Select Create Test Assets.
Figure 3. Creating test assets
- You can select any type of test datastore you wish to create for your new project.
Figure 4. Selecting the type of datastore
- Browse to the new test datastore path. By default, the path will point to a TestDatastore folder inside the new project created. Use the default values unless you have a specific reason to change the path.
- In this step, select the Initialization Options to initialize assets from a datastore. Browse to the datastore of the project from which you wish to initialize your new project. The TestDatastore folder usually lies at the <Path>RationalProject\TestDatastore level. Browse to the TestDatastore folder of an existing project and select the TestDatastore folder.
Figure 5. Browsing to the datastore
Once done, your new project will get initialized with all the test assets created on your old project. All the assets get transferred to this new project gracefully. This technique can be helpful in cases where your initial Rational Project has an UNC naming convention or in cases where you need to move projects from one domain to another. The pre-requisite is that you should have access to the original Rational Project environment.
In case you are unable to initialize the project successfully at first attempt, it's advisable to clean the target folder before you attempt the process again.
Technique two: Hard coded non-UNC project copy
This is the simplest method to transfer Rational Projects. We essentially zip up the entire project datastore from a particular drive (for example, C:\directory). The new project must explicitly be placed in the C:\ directory and must be copied to a machine with an identical path (C:\directory). Unzip the project onto an identical directory on a new machine. Once the extraction is complete, open the Rational Project .rsp file and ensure that the Location and Path of the original project matches with the new location and path where you have copied the project. Once verified, follow the steps below to register the Rational Project in IBM Rational Administrator.
- Open IBM Rational Administrator and select File > Register Project.
Figure 6. Registering the project
- Browse to the Location and Path specified in the .rsp file and select the .rsp file of the project you wish to register. Once completed, your project has been registered successfully. You can now select this new project and work on the project assets with IBM Rational TestManager or IBM Rational Robot now.
Note: This can only be done for Rational projects which do not follow the Rational recommended UNC naming convention. Non-UNC named Rational Projects thus cannot be shared and worked on parallely by multiple people. Important points to keep in mind about this technique are that it requires identical disk/directory tree and drive letters present on the new machine. This technique also requires the team to violate Rational's UNC name recommendation for projects.
While moving a project, the zip file usually becomes very large in size. In most cases, 90% of the data in the Rational Project would be the result logs in TMS_Builds folder. Therefore, before zipping a Rational Project, you can opt for not considering this folder (if it's not important for your new environment). You can cut this folder, zip rest of the contents, and later paste it back in for future reference. You can also remove the unwanted log files from the IBM Rational TestManager console. This new zip file would be smaller in size and faster to move as well. Also while making a zip file of the Rational Project; it should not be opened on IBM Rational TestManager and IBM Rational Robot console.
Technique three: Manual script move
The most laborious method of moving Rational Projects is to move scripts one at a time. This can be done by manually opening up each and every script on the original machine (from the old project), copying, and pasting it into a new script (GUI or VU) on the new project. You have to copy the scripts this way because just copying all the scripts to the directory at once will not work as all the Rational artifacts are tightly coupled to a specific path where the Rational project is created initially. If you just copy a bunch of scripts from one place to another, they will not show up through Rational TestManager or Robot, despite being present in the correct TMS_Scripts folder. Their XML link information does not get copied over. You have to copy the scripts one by one to create their linkages again. It needs to be done with all the header files and external library files used in your automation. This is the most time-consuming and painful method for large projects. You need to import all the datapools associated with these scripts one by one as well.
This method is only recommended when the project you wish to copy contains very few scripts and the techniques shown above are not working correctly. This option can be used in specific cases where you intend to move a limited set of scripts only. You will not be able to move other relevant artifacts like suites, datapools, or other coordination information using this technique. You will have to apply these changes again in the new environment.
This article should get you started with one of the trickiest problems you may encounter while using the Rational tool set. Once you get comfortable with these techniques, moving Rational Projects should become an easy task. Moving projects from one environment to another is one of the most common issues faced by geographically-distributed teams. We have been using these techniques quite often due to our geographically-distributed team. Most of the automation engineers work from different locations. We have been using these techniques to share the test automation with development teams and among ourselves as well. We hope this article helps you in moving Rational projects using the techniques detailed above.
- Visit the Rational products'
trial downloads area.
- In the Rational Robot resource area, the Rational Performance Tester resource area, the Rational Functional Tester resource area, and the Rational Robot TestManager resource area, you'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Check out developerWorks
blogs and get involved in the Rational discussion forums.
Vaibhav Telang is a system software engineer on the System Verification Test Reliability team for Workplace Collaborative Services in the IBM India Software Labs, Pune. His primary expertise is in system tests, and he has developed automation, initiated processes and tool workarounds for reliability test automation and problem determination. He holds a degree in computer science and several certifications, including Sun Certification for Java Developers, Certified Software Test Engineer (CSTE) and Quality Analyst (CSQA) from QAI and Rational TestManagement from IBM Rational.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
