LiveZilla Live Chat Software
Test Automation Tools | Test Management Tools | Automated Software Testing
T-PLAN AUTOMATION
Product Overview
Documentation
Tutorial
FAQ
Downloads
Plugins
 
FREE Trial
Click for FREE TrialT-Plan Robot | Test Automation ToolT-PLAN ROBOT FAQ

1. Releases
2. Licensing & Business
3. Project & Community
4. Plugins
5. Technical


1. Releases

Q: How often do you make a release?

We schedule a major point release every quarter, with a major release once a year. A breakdown of releases for example can be found in our T-Plan Robot Enterprise Downloads document.

We also have an OTA (over the air) update mechanism, where customers can get automatic upgrades & updates to bug fixes etc. When bugs are reported we are not beaten by anyone in our speed to get these turned around. Where applicable these fixes can be released as a 'point.point' release; to a specific customer, or the customer base as a whole.

Q: What are the difference between each major release project?

The main differences between the main projects can be viewed in our T-Plan Robot Enterprise Downloads document.

Q: What is the new version 4 project?

The vision behind version 4 was to create a new look & feel for the product, combined with world beating functionality in terms of a scheduler, detachable desktop viewer, and support for scaled components on the desktop.

Please view our T-Plan Robot Enterprise 4.0.x Change Log for more information.

Q: What was the version 3 project?

The main underlying principle of this release was to introduce full Java-API support. Java Test Scripts can now be compiled and run with no proprietary scripting language required. I.e. the version 2.x caveat for the proprietary scripting to support  the java capabilities, has been removed.

For a list of the changes please see our T-Plan Enterprise V3 Release New Feature Highlights document.

Q: I am on the 2.x version. How can I upgrade?

Please view our Update & Upgrade help topic, and also our detailed release notes section on Migration And Upgrade.

Additionally version 3 organises all Test Scripts, Test Data, Component Images and Test Results within a Project level structure. To migrate test scripts, template images and test data from a 2.x release or from a file layout outside of a Robot project, please view the Projects document or navigate straight to the Migration section.

Q: Which version of Java will be required by T-Plan Robot Enterprise?

Java 6 (formerly 1.6) or higher. If you want to take advantage of Java test scripts, you have to use the Java Development Kit 6 (JDK 6) instead of Java Runtime Environment 6 (JRE 6). The difference is that JDK contains compiler needed for runtime compilation of Java code. If you use just a JRE, the tool will run but it won't allow you to compile and execute Java source code (.java files). This limitation doesn't apply to already compiled Java test scripts (.class files). Java requirements are documented in the Release Notes document.


2. Licensing & Business

Q: How is T-Plan Robot Enterprise licensed?

T-Plan Robot Enterprise operates a "Per Seat" License type.

  • This type of license allows a specific number of users to use the software at one time.
  • Each license has a designated number of users.

I.e. this type of license equates to a developer license being required for each user that is creating scripts, and performing executions using the tool.

Whilst the license is not named to an individual, and also not tied to a particular MAC address or host id, we do require a license to be purchased for each developer who will use T-Plan Robot Enterprise.
For example: If the license purchased is set up with 5 users, only 5 users would be allowed to use T-Plan Robot Enterprise at any given time, even if there were 10 computers that had T-Plan Robot Enterprise installed on them.

There are two components to the Per Seat T-Plan Robot Enterprise licensing.

1) “Development License” (Development licenses are commonly used by users developing the test scripts for automation).

  • This license allows the user to operate T-Plan Robot Enterprise for test script development purposes, using the T-Plan Robot Enterprise UI, against the System Under Test.
  • This license also allows the user to operate T-Plan Robot Enterprise for test script execution against the System Under Test, if the license is NOT being used for development at that time.

Note: For existing customers using the 2.x releases, the purchased licenses are considered as “Development Licenses”, and the customer shall manage how the licenses are split between development and execution.

2) “Execution ONLY Licenses” (Execution licenses are commonly used for deployment of test scripts, for the purpose of unattended execution).

  • This license allows the user to operate T-Plan Robot Enterprise to execute the test scripts, against a single System Under Test at a time.

For example: An organization decides to implement a test automation project, where two engineers will be developing test scripts, which will be executed in an unattended mode on a test server. To shorten the automation time, the company decides to run full day testing of four test scripts, against four SUT’s in parallel. I.e. the test execution is happening at the same time of the development of the test scripts.
- This requires the organisation to purchase at least 2 development licenses, and 4 execution only licenses.
If the company decides to reduce the team to one developer later on, the free development license can be re-used to increase the execution pool of licenses, to 5 scripts in parallel.

It is possible to start multiple T-Plan Robot instances to perform testing in parallel on a number of test environments. It brings a significant added value in form of reduction of testing time. In this scenario we charge for each instance in terms of an execution license. Based on numbers required we may also offer volume discounts to let you further realize your added value and savings.

Lastly there is also a Java programming API, allowing you to create and run multiple automated testing threads within one Java Virtual Machine (JVM). Each single thread behaves as a standalone T-Plan Robot instance and it can also connect to one test server at a time. This set up is typically employed for load testing, or when the tool is integrated with a Java project. In this scenario we charge for each instance in terms of an execution license. Based on numbers required we may also offer volume discounts to let you further realize your added value and savings.

An important point is that we whilst we do not presently lock the license either to computer or user, you must make sure you don't exceed the number of licensed connections.

Should you have any further questions regarding pricing, or the license, please contact our Sales department through the T-Plan Contacts page.

Q: What Versions of T-Plan Robot Enterprise are available?

There are two editions:

  • T-Plan Robot Enterprise is provided as a paid for licensed product.
  • T-Plan Robot Open Source is a version with very limited functionality and available under GNU General Public License (GPL) on SourceForge. This project is not backed up by any professional support. It is maintained only in terms of major bug fixing, with NO new features being developed.

For a an overview of T-Plan Robot and T-Plan Robot Enterprise products see the Versions page.

Q: When should I prefer the T-Plan Robot Enterprise Edition to the GPL version?

A few reasons why you should consider to pay for the enterprise license:

  • GPL restrictions: GPL requires you to distribute any derivative work as open source under GPL. This is known as "copyleft".
    • The practical impact is that if you write a Java test script, plugin or enhancement, it is in terms of GPL considered to be a derivative work of T-Plan Robot, and therefore covered by GPL.
      I.e. If you decide to distribute your work to a 3rd party, you have to do so under GPL, and with the full source code.
    • The Enterprise license does not apply any "copyleft".
  • Integration with T-Plan Professional allowing you to report results of automated tests into the T-Plan test management framework.
  • A massive amount of additional functionality and vastly improved performance.
    • For a complete summary of advantages of T-Plan Robot Enterprise see the Versions page
  • Support and access to hot bug fixes (custom builds), new releases, forums, account management, and plugins etc.

For a complete summary of advantages of T-Plan Robot Enterprise see the Versions page.


3. Project & Community

Q: What do you mean when you talk about "community"?

Many existing features and improvements were actually suggested by active users who provided feedback. The T-Plan Robot community for us means the network of users who actively use the tool, and give us feedback. Whether it is a bug report, feature  suggestion or recommendation on the web (support@t-plan.com, contact details), our own T-Plan forums, in public QA forums (such as SQAForums.com), or our forums at SourceForge, we aim to address your wants and needs. We look forward to welcoming you to our family!

Q: Is there any forum where I could ask questions or provide feedback?

The T-Plan Robot forum is on the T-Plan forums. If you would like to know more about our Products or Services, then please contact us at sales@t-plan.com, leave your contact details, or contact you local representative.


4. Plugins

Q: Where do I find additional feature plugins?

Check out our Downloads page. Listed here are plugins which were developed by us. We will also link plugins provided by our community.

Q: I have downloaded a plugin JAR file. Do I have to add it to the Java class path?

No. The path to the plugin JAR file or class path gets saved to the user plugin configuration XML file. The Plugin Manager will load it dynamically upon the application start. If you however move the tool into another folder, you need to either add the plugin JAR to the Java class path or plug it in again.

Q: Can I uninstall a built-in plugin?

No. So called "built-in plugins" represent core classes from the product JAR binaries and they cannot be uninstalled. They can be however disabled through installation of a plugin which implements the same functionality.

Q: How do I add a new feature or replace an existing one with my own Java code?

Refer to the T-Plan Robot Plugin Framework document. It is linked to the Java code documentation.

Q: I want to translate the software messages and publish it. How do I do it?

Follow the steps in the localization guide. If you want us to endorse your translated message file, send us an email at support@t-plan.com and we will link it after a review, to our download site.

Q: How do I install a translated message file?

Just copy it to the folder where you installed the tool to. It will pick it up after restart and make it available in the Language drop down of the Login Dialog.

Q: I want to write a plugin and publish it. How do I do it?

Follow steps described in the Plugin Framework manual. If you wish to make the plugin public to the community, email us at support@t-plan.com and we will link it after a review, to our download site.


5. Technical

Q: How do I verify actions in a test script?

Verification methods include (1) image comparison, (2) image updates, (3) bell character, (4) text transfer and (5) local system commands.

The most often used method is image comparison. The point is to save an image of the tested application, or better its small part, such as an icon, button or any unique component. The use one of the Compareto, Screenshot or Waitfor match/mismatch commands to verify that the remote desktop contains the image.

For a quick check you may just wait for a screen update. When an application window displays, it causes part of the display to refresh (update). The Waitfor update command may be used to hold the script execution until the desktop refreshes. An action may be specified to be invoked when the refresh doesn't come and the application window is likely to fail to open. Note that screen update is supported just by clients which actively refresh displays, such as for example RFB (VNC) or RDP.

Some clients (namely RFB/VNC) are able to detect when the desktop machine rings a bell (beeps). It is usually caused by the Bell character (ASCII 0x07) printed out to the console. This feature may be effectively used on Linux/Unix systems to detect that an OS command being executed in a console window finished. See the Waitfor bell command for more information and its example section for  sample code. Be aware that availability of bell events is also limited to certain protocols such as RFB (VNC), and it may not be supported by other clients.

Text transfer from the server to the client may be used to verify results where text plays a role. See one of the following FAQ for more information.

Last but not least you may employ the Exec command to execute an OS command from a test script. It becomes handy especially on Linux/Unix systems where there are many useful commands allowing you to perform string or file comparison or verify status of the remote machine through different technologies.

Q: How do I get text displayed on the remote desktop?

In general you may use the clipboard of the remote system. Simply select (highlight) the text and invoke the 'Copy' or 'Cut' action (Ctrl+C or Ctrl+X on most systems). The text should get transferred to the client and it will be available to the script in form of a variable. See the Var command specification, especially the _SERVER_CLIPBOARD_CONTENT implicit variable.

Availability of the text transfer and its parameters and limitations depend on the client used. The RFB client can only transfer Latin-1 characters (ISO 8859-1), and it requires an additional utility to run on the server.

Q: I copied text on the remote RFB desktop. The content of the remote clipboard however didn't make it to the client. How do I make it work?

The "vncconfig" utility has to run on your server to make the clipboard transfer working. As some VNC servers do not distribute it (for example, TightVNC), the feature may be switched off. If you plan on using clipboard changes to transfer text from server to client, get a VNC server which has it, such as UltraVNC.

On Linux/Unix, the autocutsel utility can be used instead of vncconfig. It must be executing on the server as "autocutsel -s PRIMARY". If you are running Debian or Ubuntu, you may find the tool in the package repository. Be however aware that client text transfer limitations apply both for vncconfig and autocutsel. For example, the RFB client can transfer only characters from the Latin-1 (ISO8859-1) character set. The Java client (v2.0 enterprise feature) is limited by characters which can typed on the local machine keyboard.

Q: Can I write libraries with test routines and share them among multiple scripts?

Yes. The Include and Run commands in conjunction with global variables and procedures are designed exactly for this purpose. Version 2.2 of the Enterprise product in addition allows to write parametrized routines in Java and call them from regular scripts. See the Interoperability of test scripts and Java code tutorial topic.

Q: The application window I am testing gets displayed in a different location each time I start it. How do I automate it?
There are many approaches. I suggest to stay away from mouse clicking and handle everything through keyboard. You may navigate to any window component using the Tab and Shift+Tab keys while Enter or Space can be then used to press buttons or follow links. There are a few other options:

  1. Use your OS specific key to maximize the window and work with it in full screen size.
  2. Many systems allow to move windows through the keyboard. For example, on Linux/GNOME it is Alt+F7 followed by arrow keys. Use it to move the window to one of the corners and automate at this location.
  3. Employ a utility which can move the window to the specified location and/or remember window size and position, such as WinSize2 on Windows.
  4. Use image search to locate the window on the screen, and specify coordinates of all location-depending commands as relative (x:{_SEARCH_X}+[relativeX],y:{_SEARCH_Y}+[relativeY]).

Q: Which version does the RFB client support?

The client supports RFB version 3.8. It should work fine with most VNC products.

Q: Can I use the tool with RDP desktop (Windows Terminal Services)?

There is no direct RDP support at the moment. A few users reported that they had succeeded to make the tool work with Citrix/ICA using the RDP2VNC proxy. We are considering to provide an RDP client in one of the future versions. The client API is otherwise open to plugins for those who wish to implement their own protocol support, or plug in functionality of other projects.

Q: Does the tool work with Apple Remote Desktop (ARD)?

Yes, because Apple uses RFB protocol for the desktop access. Note that there were bugs up to 1.3.14 causing the tool to display incorrect colors. Version 1.3.15 and higher should work fine.

Q: Does the tool support MSRC4/NTLM RFB authentication?

No. Reasons are the same as in case of file transfers. MSRC4/NTLM are UltraVNC proprietary features which are not specified in RFB protocol.

Q: Can I use the tool to automate a mobile phone?

Yes, provided that there's a VNC server or any other supported desktop technology available for the mobile platform. Windows mobile phones may take advantage of PocketVNC (a workaround described in Release Notes is needed). For testing with VNCRobot 1.3 you will also need to set up your mobile to have a public IP address (instructions). This is not required for T-Plan Robot Enterprise v2 or v3, which supports reverse server-to-client connection through the RFB listen mode.

Q: Can I load test data from a file or database to the script?

Yes, in Java test scripts. There are many free Java libraries allowing you to access data from various sources, such as relational DB (via JDBC), Excel sheets and CSV files (via Java Excel API, JDBC Excel driver or jXLS) or XML (for example using JAXP or SAX parser). Text files or even CSVs can be also loaded easily through the core Java I/O functionality. Examples are provided in the tutorial.

For the T-Plan Robot Enterprise versions, the proprietary scripting language now supports an integration with MS Excel, providing the functionality to read in and write out, to and from MS Excel files.

Q: Can I record video from the test sessions?

There's no direct support in the tool at the moment. You may however set up an external tool for RFB (VNC) session recording. See an example of how to convert VNC sessions to Flash using pyvnc2swf.

Q: Can I record test scripts directly to Java?

Version 3 of T-Plan Robot Enterprise now supports recording and playback of test scripts directly to Java. Previous versions of Robot did not support this feature.

Q: Is there any way to convert a Java test script back to the proprietary language?

No this is not supported. As Java syntax is much more complicated, not every statement in Java can be translated into the proprietary scripting language.

Q: Can I customize the test script converter?

Yes. As the converter implements the Plugin interface, you may customize it and plug it back to the tool. You can also use methods of the converter interface to modify behavior of the existing implementation in a Java program.

Q: I have a test script which executes well against a VNC server. Can I execute it using another client/protocol, for example the Java native client?

In general yes. You should be however aware that each client applies certain protocol specific limitations which may impact compatibility, such as:

  • Client capabilities. T-Plan Robot is an open architecture and allows to plug in even clients which are not capable of all operations typical for desktop technologies. For example, some servers (such as the Java one) do not actively notify client of desktop image changes. The client is then forced to poll the image at scheduled intervals which makes it impossible to use the Waitfor update command. Such  compatibility failures are checked during both script compilation (doesn't apply to Java test scripts; it also must be clear which client will be used) as well as script execution. Any lack of client capability will be reported as script syntax error.
  • Ability to transfer certain characters. For example, the Java client allows to transfer any characters supported by the local client keyboard. The VNC client on the other hand can transfer only Latin-1 characters which is a limitation of the RFB protocol. Hence if you write a test scripts which types Russian characters on the remote desktop, it may work with the Java client provided that both the client and server use a Russian keyboard, but it will for sure not work with VNC. These differences may result in failures of Press, Type and TypeLine commands as well as transfers of text through the system clipboard during script executions (no syntax error is reported).

See documentation of the clients and the Waitfor client overview table for more information on individual limitations.

Q: Is T-Plan Robot Enterprise IPv6 enabled?

Though Java claims to support IPv6 transparently without any application code change, currently we do not support this. We are however considering IPv6 support for one of the future versions.

 

 
OUR CLIENTS
NEWSLETTER

FREE Product Trials

Name:
Email: