Besides my daily job as CTO of PepperByte, I’m also working as CTO for our sister companies LoadGen and BlueParq (a really cool PowerShell tool where you can create PowerShell scripts visually). With LoadGen we are developing several software products which can measure the real user experience on Citrix, Microsoft Remote Desktop, VMware Horizon and Windows Fat Clients.
Because we want to release our software in short cycles there is a lot of pressure on our testers. Two years ago we decided to build our own functional test software, which allows us to add a functional test as the last step in our Build Automation process (Visual Studio Team Services but works on Jenkins and other Build Automation tools too). The result is a lot of extra spare time as we are running this tests, automatically at night, so our test team can focus on specific test-tasks. Besides that our developers directly see if a build is successful instead of waiting for the test team. We have decided to bring this product to market in our upcoming LoadGen 5.0 release which will be released in February this year. In this blog post, I will take you on a trip through this new product called LoadGen Functional | Automated Testing.
LoadGen Functional | Automated Testing tools
So when you buy LoadGen Functional | Automated Testing you will receive the following tools:
- The Studio, in which you can create your functional tests.
- The Recorder (part of the Studio) which let you record, build, replay and debug your functionals tests.
- The Launcher, it’s pretty much all in the name, but the Launcher can be integrated into your build automation process to run your functional test unattended.
Test repository, projects, testcases, testblocks, testactions, and reports
We think a logical approach in your functional test will help you setup your functional test or migrate from another functional test tool (like Ranorex) extremely. That’s why we came up with the following architecture of LoadGen Functional | Automated Testing:
- Test repository: LoadGen Functional | Automated Testing comes with a database (SQLite) which you can use as a repository for all of your functional tests. The repository stores pretty much anything you build within LoadGen Functional | Automated Testing.
- Test projects: holds your functional test, you can define multiple projects and run each on different Launchers to speed up the process.
- Testcases: the testcase will guide you through the steps (testblocks) of your functional test. You can think of a test case as a set of step-by-step instructions to verify if something behaves as it is required to behave. For example, create a testcase ‘Microsoft Word’ and add the testblocks as described in the next item as the steps to reach your goal.
- Testblocks: are the logical steps within a testcase and will hold your individual testactions. As an example, we use the testcase in my previous item:
- Microsoft Word (which holds the following testblocks):
- Start Microsoft Word,
- Create a new document,
- Type your text,
- Save the document,
- Close Microsoft Word,
- Microsoft Word (which holds the following testblocks):
- Testactions: withing the LoadGen Functional | Automated Testing Recorder we deliver you a Toolbox with the following actions for you to use. With these actions, you can build your functional test very fast. For example, Check if a specific file exists, after you have saved your Word document.
The most important item in the testactions are the validations. These validations validate a specific condition. We support the following validations:
- Caption of foreground window: like Notepad or a part of the captions like Word – Document.
- Control in foreground window: some applications like Chrome, SAP, and Java exposes their controls to the Operating System, even Microsoft Edge and Internet Explorer are exposing the controls, so this will definitely help you in web testing your business application from a user perspective. So with this validation, you can check if the control you are looking for is:
- …is found: if not you can add specific actions in this case, for example, restart the application.
- …is found and the property is matched: in this case, the control is found and the property matches, as an example you are looking for a specific checkbox where this checkbox state is checked.
- …is found but the property doesn’t match: in this case, the control is found but the property doesn’t matches, as an example you are looking for a specific checkbox where this checkbox state should be checked but the checkbox is unchecked. In this particular case, you can directly add a call to action (click mouse left on the control).
- Image: a very, very fast way to find a specific image within the whole or specific area in the desktop. In the case, you can’t validate on a control just use this validation.
- Single pixel: the same as an image but on a specific pixel somewhere in the whole or specific area desktop.
In this example, I will use the checkout page of LoadGen.com,
In this step, I will create a testcase named Microsoft Edge, with a testblock named Start Microsoft Edge. Within this testblock I will start the application Microsoft Edge and browse to my checkout page:
When I open the Start application action you can see that we just call a process:
After this action is called I have added a validation which will wait for the existence of the Next button:
In my next step I will add the testcase named Add Company information which consists of three testblocks: Add company, Add firstname and Add lastname. Within Add company, I will validate on the checkbox Click here if you are a business, if found I want to click it:
After clicking the checkbox an extra field will be displayed where I can add the company name, so again I will add a validation which will check if the Company textbox exists:
The last step is to send the Company name to the control, I have used a variable to store my company name. My testblock looks like this:
The last steps are adding the same routine for adding the first and last name. Of course, I can group multiple actions within one testblock, but I use different testblocks so I have a more transparent report when I run my functional test.
So now we are ready to run the functional test. I press play in the Studio and it will nicely run my different testcases, this will result in the following overview which can easily be exported to DocX or PDF:
Yes, one of the big issues in functional GUI testing is the constant change of the visual aspects of the application. Of course, we run into this issue as well, but because of the easy and intuitive way LoadGen Functional | Automated Testing works we can anticipate on changes very fast.
With the upcoming release we will first support Windows Fat Clients, in the 5.1 release, we will also support Citrix, Microsoft Remote Desktop, and VMware Horizon environments! We will release LoadGen Functional | Automated Testing in February 2018, if you are interested just contact me.