Subscribe to this feed

Welcome back to our Blog series about GeNiEnd2End Scripting!

Today we will go through GUI based Front-End scripting and what you should do or avoid there.

Scripts which interact with the desktop of the robot are easier to build with AutoIt, but will then only run on Windows Platform.

 
The hardware of the robot should match the normal user hardware else you won´t get the same results as the user. 
A real hardware should be taken and no virtual machine.
Since the key is to find the problems a user would have and how much time it takes the user to wait for a transaction.
 
Every measurement which acts like a user should start with a click documentation, it includes all the steps which the script should make and you can set / find out the measurement points there. This will help you later identifying problems causes, if the script wont go through specific steps.
 

Example click documentation from one of our production scripts:

 
Best Practices:
  1. Write a Log, maybe with a debug flag which enables extensive logging if you need it.
    This can help you to quickly identify where it hangs, so you can see different results from a run in programming environment and a compiled version.
    The GeNiAgent will also search for a "error.log" and "detail.log" in the script folder and upload it to the GeNiEnd2End Server, so you can directly check that in the Web UI if there is any error.
     
  2. Does the application have a fast changing GUI (Will the GUI design change much)?
    If so you should try to take window text (titles, content) for this measurement so it will not be harmed as much if the design changes over time.
     
  3. If you have to use image search:
    When you have to take image search you should try to make as neutral screenshots as possible. 
    This means try to take a screenshot from a GUI element which will not underlie much changes or is somewhat clear to spot, even if the location changed a bit.
    The screenshot area should also be as little as possible, this will help a lot if the GUI changes since the chance to spot it even after a change is bigger.
    They should be taken on a robot so no color differences are there.
     
  4. If something goes wrong in this application will it throw display errors \ Error handling ?
    Maybe you have to check for an error after a timed out measurement or a problem occurred and the application didn't close correctly.
    So keep that in mind and script for that cases. Use "error.log" and "detail.log".
     
  5. Can you do the steps just with clicks or also with keyboard interactions?
    You can send keys and this is mostly the better way to interact with the desktop, just if it uses the same function as the click.
    If you have to use mouse clicks and the button location may change, do an image search for a part of the button and then click on it.
    So you don't click a false button because it moved over to another place.
    If your application doesn't lock the ids / captions of the design elements you can also track and directly click elements. (Check that with AutoIt Window Info)
     
  6. If you are doing many transactions after another or use Packet Trace / CNS Option be sure to use the 5 second pause before every transaction starts.
 
This Example script runs on a Robot, its a AutoIt script which interacts with IBM Notes 8.5 and 9.0 without many changes.
 
 
Next time we will go through Back-End scripting.