Test Automation
    • Dark
      Light

    Test Automation

    • Dark
      Light

    Article Summary

    5.1 Introduction to QuickStart Tutorials

    In this Test Modeller 101 Tutorial, you’ll get an overview of the QuickStart frameworks for test automation available in Test Modeller. The aim of providing these frameworks in the tool is to get you quickly up and running with your test automation journey. 

    So, in the clip you'll see an overview of the 5 main automation frameworks and associated applications including: Web, API, Mobile, Dynamics 365 and Mainframe. 

    To get started with the QuickStart Tutorials, sign up for a free trial of Test Modeller. You can access the QuickStart tutorials via this link.


    5.2 Overlaying Test Automation

    In this Test Modeller 101 Tutorial on Overlaying Test Automation, you'll learn where best to overlay automation and the techniques for getting the automation assets onto the Model and how this integrates with any automation framework. In this example, we are using QuickStart Web automation, based on Java Selenium. 

    In the example model, you’ll see that clicking on a waypoint ‘Open URL’ opens the Automation Reference. The block Enter Email you’ll notice this can take a Test Data Variable. The Test Data Variable comes from the model and is added as a parameter and parsed from the previous block with a Variable Assignment Invalid Email. 

    Building a model from scratch, the assets are best imported via the Project Explorer pane. It should be noted that these can be scanned objects, imported objects or pre-defined action packs in Test Modeller and can include automation such as AssertURL, Enter Email and Click Sign in Button etc. 

    Alternatively, overlaying the automation manually is used on models built out in advance prior to knowing the actual automation. This is done through the Automation pane, where you’ll Add an automation reference from a list. In the example this is from the Module titled WebGeneralActions from which the available functions at which point can also be defined by adding a parameter. To get a waypoint onto the canvas, simply drag it from the Actions area of the screen and drop it on the model canvas. 



    5.3 Code Templates

    In this Test Modeller 101 Tutorial on Code Templates, you'll learn about their relation to an automation framework, and how templates allow you to define any code based language you want inside Test Modeller. Before publishing to a Git repository, thus enabling you to publish the generated automation assets to a CI/CD pipeline.

    In the example, you’ll see the Project Configuration wizard of pre-defined frameworks, but alternatively there’s an option to get Test Modeller to create and set up your own code templates, which can be cloned from an existing repository, or if required you can also start from scratch. 

    A benefit in having Code Templates available in Test Modeller is that they are separated into Page Objects which generates classes, but also Test Case Templates which descriptively generates test scripts. Additionally, for easy navigate, keywords are displayed, and it’s worth reinforcing that these are all fully customisable to match any custom framework. In our example you see there’s C# Selenium, Cypress, Desktop Automation, Dynamics 365 and more. 



    5.4 Custom Code Snippets

    In this Test Modeller 101 Tutorial on Custom Code Snippets, you'll learn how to use importers in Test Modeller to quickly populate Test Modeller with automation and classes that may already exist. As with being Code Templates also being able to be directly imported from a Git repository, this is also the case for Custom Code Snippets. This pulls in any Objects and Functions from the connected repository and sets them up inside Test Modeller. Additionally, UFT, Ranorex and Swagger repositories are all available in Test Modeller.

    So, beyond importing Custom Code Snippets, and for instance if you have a requirement for a Sleep or Wait function it may be better created as a custom function. This gets added to your Workspace. In the tutorial you’ll see these can be attributed as Abstract, Page Object, Pending Automation, Embedded Code, Custom Code and Function Map.  

    In the example, a new Module Collection called Customer Code Snippets, using a pre-determined framework QuickStart Web Automation (remember this is based on Java Selenium). At this point you see New Functions are created, and remember at this point to add in the attributes including Object and Qualified Name and specific Function Type (listed above).

    Using the Function Custom Code the example demonstrates the use of the Code Editor, where you’ll be able to paste any code for embedding in any of the models. A series of importers including Swagger Specification can also be used to import and bring in specific code. And not forgetting the feature to import a zip file containing existing page objects, but also connecting to a Git repository.



    5.5 Code Generation and Execution

    In this Test Modeller 101 Tutorial on Code Generation and Execution, you'll learn how a pre-built Automation Model can be used to create and run automation scripts and use the Run button in the Scenarios pane, and you’ll use the Automation Code export in the Run wizard. At this point it’s notable to indicate this automation can be triggered by one of the QuickStart Automation frameworks available in Test Modeller or any framework you’ve chosen to set up yourself.

    In the example you’ll see an automation model for a HR system also referring to a couple of Subprocesses. Within the many blocks which compose the model, specific waypoints seen here include automation such as Go to page and Positive Enter username. In the Scenarios pane, on clicking the Run button a series of advanced settings give was of managing where and how to see the results of the automation.  

    The first two settings include Source Control which relates to whichever repository you’re committing to, then Test Data which is about deciding if you are fetching data from an external source like an SQL Server database or an Excel spreadsheet. The final two settings are more concerned with Executing and Publishing of the automation tests. Clicking Execute, you see Test Modeller runs a job to execute the web automation. Here you see what’s Passed and what’s Failed.  

    The benefit of using the QuickStart framework is the execution settings are already set up. Should you be using a custom framework, the three settings to consider are: Directory (target machine), Command (triggering a batch file) and Parameters. This is done under Workspace > Configuration. Once ready to configure the settings, you’ll need to choose the relevant Code Template related to the automation framework. Once there you can set up the Directory, Command and Parameters, as well as set up a source control. Basically, this is everything you need to come in and run automated tests in Test Modeller.   



    5.6 Test Plans and Scheduling

    In this Test Modeller 101 Tutorial on Test Plan and Scheduling, you'll see there are two places to review tests. This is at one time at a Model level in the Automation pane, but you can also the tests can be filtered and passed to the Test Modeller results portal for giving sequential oversight and summary of the Passed and Failed tests. And this is beneficial as part of a CI/CD pipeline, where you can set up Regression Suites to run on a schedule inside test Modeller. You’ll also see how to set up and name a test suite for publishing.

    In the previous clip on Code Generation and Execution we saw the Source Control, Test Data and Execution tabs. As part of that same palette is the Publish tab. This Publish tab is crucial for setting up Test Plans and Scheduling. So to Publish a test suite regularly, you’ll see it’s necessary to give the plan a name. This is done in the Test Plan tab.

    In the example you’ll access the Tests tab from the main menu and this reveals a Results Summary with further information can be traced to a specific model (with preview link), and specific run (with preview link). The benefit of having a regular test plan scheduled is the ease of analysis of the runs. Finally, you may want to run the test plan in isolation, but also there’s an option to just re-run the failed test.