First steps
testgrinder service will be discontinued on January 31, 2025
Thank you for giving testgrinder a try! We hope it will prove to be a valuable tool in automating your Maximo testing and other tasks.
Feel free to get in touch with us either with a question or a suggestion for how to make testgrinder work better for you. The easiest way of getting in touch with us is to click on the intercom icon in the right bottom corner and start a new conversation. Or send us an email to support@testgrinder.com.
We’ve created testgrinder to help automate user acceptance testing and other tasks in a way that is friendly both to those responsible for setting requirements for your system and the developers maintaining and improving it. You write testgrinder scripts in a language which reads like a natural language, yet is precise enough to allow for automation.
Being cloud based, testgrinder allows you to start running scripts on your system quickly and with minimal setup. Once you sign up for the testgrinder account, write a scenario, and tell testgrinder how to access your system, you can start running testgrinder scripts in your Maximo in minutes, granted that your system is accessible from the internet.
If your system is not accessible from the internet and you would like to use testgrinder to automate your tests, you may set up a testgrinder Agent on a Windows computer on the same network as your Maximo instance, which will open and manage a secure tunnel to allow testgrinder to connect.
Testgrinder supports automation of IBM Maximo. The currently supported versions of Maximo are 7.5 and 7.6 of various patch levels.
You organize your scripts into testgrinder projects. Each script is intended to test a specific feature of your system and automate a certain task, e.g. data load or generation of a training video. Within a script you write one or more test scenarios, each testing a specific aspect of the system or automating a certain task. For example, here’s a script testing the basic ability to log in to Maximo:
testgrinder refers to the system being tested as the target system. A typical enterprise system has several instances – production, test, and possibly several development instances.
To help us go through this guide let’s pick a simple, yet real-world example of a requirement that our system has to satisfy. We will go step by step setting up testgrinder, writing the test, and executing it on the target system.
Let’s pick the requirement to customize the List View tab of the Inventory application to have the Issue Unit column available for filtering records. The column should be positioned right after the Current Balance field on the tab.
In the spirit of Behavior-driven development, let’s write the test before the customization is implemented. We will write the automated test first, run it to observe that the requirement is not satisfied, and then we implement the requirement in the system, and rerun the test to confirm that the requirement is now satisfied. Having written the test once, we will be able to run it at any time in the future to confirm that the customization is still in place, e.g. after a Maximo upgrade.
Before we can write our test, we need to open a testgrinder account. Head to testgrinder.com and sign up:
Click the Get started button and you will be presented with the Sign Up form:
Fill out the form and click the Create account button. Congratulations! You've signed up to testgrinder and started your free 14 day trial with 5 users and 10 tgBots (concurrent scenario runners). Within the next few days, open the confirmation email and click on the link to confirm creation of the account. You may now create your first project and start writing tests.
testgrinder allows you to organize your tests into projects. If you have several systems that you intend to test, you may want to create a dedicated project for each. Or, if you work for a consulting company and work on several client systems, you might set up one project per client system. You create and access projects from the dropdown menu at the top labelled Projects (once you have created a project, this menu will be labelled with the last viewed project's name).
To start writing the test for the requirement we received, we need to create the project first. Click on the Projects in the top menu:
Click Create Project:
Enter project name and click OK. You should now see the empty project:
The screen is divided into two major areas. On the left side is the project tree view, which currently only shows the project itself, but will grow as we add more features. On the right is the detail view of the currently selected node in the tree, and at this point nothing is selected.
testgrinder allows you to create folders in the project to organize features. You may nest folders to the extent you find useful.
Time to create the feature for the requirement we are going to test. Right click on My Project in the project tree:
Select New > Script, give it a name, and hit Enter. The newly created script will appear in the tree. Select it and the script editor will appear on the right:
We are now ready to write our test!
Let’s start with writing the script and scenario declarations:
Script: Issue Unit on List tab in Inventory app Scenario: Make sure Issue Unit is present
Note that both Script: and Scenario: lines are optional. They are there to help document your script.
Here’s how it will appear in testgrinder:
Time to write the actual test steps. You may be wondering what steps are available in testgrinder for writing Maximo tests. We’ve compiled a reference guide that you can access to see what is available. To help you find the right step, testgrinder will offer you matching choices once you start typing the first few letters of a step.
Let’s get to writing the first step.
Just as if the test were to be executed manually, first we need to log in to Maximo. For our test we will be logging in as an Administrator. Consulting the step guide we see that we can use this step for logging in to Maximo:
The parts of steps in the reference guide that are highlighted in orange are parameter parts that you substitute with actual values when adding the step to the scenario. In our case, we need to log in as an Administrator, so we will be substituting role with Administrator. Later we will map Administrator role to a specific Maximo user when we get to setting up the target system.
Each step has to be prefixed with Given, When, Then, or And keyword – you can choose any of these prefixes as the readability of the scenario demands.
We are now ready to write the first step as:
Given I login to Maximo as Administrator
Now that we’ve logged in, we need to navigate to the Inventory application, which is available in the Go To menu under the Inventory module. Consulting the step guide we find the appropriate step:
When I go to the Inventory / Inventory application
For this step, if you need to click through a series of submenus to get to the application, you separate each step with a ‘/’ (slash).
Now that we are in the application and the List tab is automatically selected, let’s test if Issue Unit column is present and appears where we expect it – after Current Balance column:
Then I see that the 'Issue Unit' column appears immediately to the right of the 'Current Balance' column in the Inventory table
When replacing a step parameter with a value that has a space in it you generally need to surround this value with single quotes. Note that Issue Unit and Current Balance are surrounded with single quotes here, but Inventory isn’t (but could be if you prefer).
We should also test for the value selection icon to be present next to the Issue Unit column. In testgrinder terms the icon next to a field or a column is referred to as the detail menu:
And I see a detail menu for the 'Issue Unit' column in the Inventory table
To be certain that the column is mapped to the right object attribute and not just having the correct label, let’s test for that:
And I see columns in the 'Inventory' table: | column | attribute | | Issue Unit | INVENTORY.ISSUEUNIT |
This step looks a bit different from others – it has a parameter table. Steps that require parameter tables end with a ‘:’ (colon). For this step the parameter table is expected to have two columns – column name and MBO attribute name. If you wonder how testgrinder determines which object and attribute a column maps to, it relies on the same mechanism available to Maximo users – it requests Maximo to show a column’s help dialog box and reads the object/attribute from there. You will later see this happen when you review the video of the test run.
Now that we’ve tested everything we needed to test in order to know that the requirement is satisfied, we can conclude the scenario by logging out of Maximo:
And I logout
Here’s how the feature we just wrote looks in testgrinder:
The test is now ready. Next step is to tell testgrinder about the Maximo instance in which the test should be run.
In order to run the test we need to tell testgrinder about the Maximo instance in which we want the test to run, or in testgrinder terms, we need to configure the target system.
Target systems are configured as part of the testgrinder account, which you can access by expanding the menu under your name:
Once you select Account in the menu, one of the tabs is for managing target systems:
Let’s configure our target system. Click Add MAXIMO target system to start:
There are many other parameters that can be specified under the Settings tab, but for now you only need to fill out the 2 required fields:
Label – the label by which the target system will be referred to throughout testgrinder
Maximo URL – URL by which your Maximo instance can be accessed from the internet
Scroll down to the bottom of the form and click the Add button to add the target system:
Remember when we were writing the login step we replaced the role parameter in the step with Administrator?
Given I login to Maximo as Administrator
We need to tell testgrinder how the Administrator role maps to a Maximo user. The mapping is done as part of the target system setup. At the bottom of the target system form there is a Roles tab that you may have noticed when we were adding the target system:
You may create roles by clicking on this tab while adding the target system, and you can also add, remove, and edit roles after the target system is added by clicking the Edit button in the target system's row:
To add a new role you click the [+] button. This will add a row where you can enter a Maximo username and password, and a name for the role. This name is how you will refer to this Maximo username/password in testgrinder scripts (case-sensitive); we will create the Administrator role that we referred to while creating our script:
With the target system and the role setup completed, we are ready to run the test on our Maximo instance!
Now that all setup is done, let’s run our test for the first time. We know it is going to fail as the actual customization has not been finished in Maximo yet, but that’s okay. Running the test and seeing it fail for the right reason will confirm that our test is properly written.
Once there, right click on the project and choose Run (you may also create runs of folders or individual features as necessary):
This opens the Run Configuration dialog, where you can name the run, choose the target system on which to run, and choose screenshot and video settings:
Choose your target system, name the run if desired, select recording options, and click Run to launch:
Now that the run is running, let’s watch it. Click the View Run button to be taken directly to the Run Report:
Alternately, you can navigate to the Review page and see a list of runs:
The progress bar at the top can have up to four sections:
Green – successfully completed scenarios
Red – failed scenarios
Blue – currently executing scenarios
Gray – scenarios yet to be executed
Below the header you will see one row per scenario in the run. Here there is only one. The scenarios will be colored according to their state. Here our sole scenario is blue as it is currently being executed. Clicking on a scenario's row will toggle showing/hiding that scenario's individual steps. If a run contains only one scenario, the list of individual steps will automatically be expanded when the run is opened:
Here you can see that the first step has executed successfully since it is green. The step started 0 seconds after the scenario initiated and it took 8.9 seconds to finish.
The report is updated live as the run is being executed. Very soon you will see the scenario complete in a failure (as expected):
It may be hard to see the details on the small screenshot. Right click on it and choose View Image (or similar on your browser) to see it full screen.
Also note that testgrinder recorded the video for the scenario. The link appears on the scenario row on the report. If you click the link and the video does not play, your browser may not support the video format. Try a different browser. You should have no problem watching the video in Chrome.
Time to customize Maximo to satisfy the requirement. Without going into details of how to implement the change, the column is added and the List tab of the Inventory application looks like this now:
Now that the customization is complete, let’s rerun the test to confirm it. Following the same steps as earlier, we launch the run and after a few seconds, it is done:
Success! The test is green!
Last updated