INTELLIGENT AUTOMATIONTEST DESIGNHow to Implement In-Sprint Test Automation Practices

Avatar Alyson HenryJune 15, 20185 min

In-Sprint Test Automation Practices in Motion

So, you’ve decided on adopting In-Sprint Test Automation practices. Now what? In a previous blog we saw the benefits of integrating test steps, automation and data into a singular model. We also saw how automated test scripts are created my integrating code snippets directly into a visual diagram. By creating a model at the beginning of a sprint cycle, testing can occur faster and earlier. But how does this work in practice? This post will go into more detail of how the tools given by the Model Based Testing methodology boost your In-Sprint Automation practices.

What is a Test Script?

Before diving into the specifics, it is important to define exactly what a test script consists of. A test script directly reflects the actions needed to complete a test case. For example, imagine clicking through a banking website. A test case might reflect logging in, checking your balance, then transferring money between accounts. A test script takes those individual code pieces required to complete those steps, and compiles them in sequential order. Both optimized test cases and test case scripts can be generated dynamically through a model to cover maximum application functionality. Once the model and all artifacts are integrated, test scripts can be pushed to an execution engine as a final step. Having your application represented in this way makes future changes to an application painless. Instead of managing an infinite number of test case scripts, the model is the only thing being managed.

Automate Your Automation

Test scripts can be created for whatever executes in the desired environment, regardless of what framework is being used. Whether trying to build a valid script, a keyword driven scenario, or a text file path, constructing automation with Model Based Testing is the same. The best way to simplify this process is by creating a configuration file that stores objects, actions, variables and more to be reused.

In-Sprint Test Automation Practices 1

Each stored artifact can be used to create code snippets to execute actions throughout an application. For example, instead of having to create code individually for all input boxes on a customer information form, just drop in the appropriate input action pulled from a configuration file.

This feature is especially useful if using a common language across multiple applications. A configuration file only has to be created once per language, not once per model. Meaning that this file is stored separately, and can be pulled in whenever necessary. Utilizing the artifacts stored in this file, the assigned block code pieces can be created, and subsequently the test scripts tied to each test case. Having this accelerator like this makes achieving In-Sprint Automation even more efficient.

Taking Scripting to the Next Level

There are many other features that can make integrating your automation scripts seamless. An Automation Layer is mutually exclusive script file for a programming language. Creating more than one layer of automation within your model can produce multiple script files in different languages for a singular test.

In-Sprint Test Automation Practices 1

This feature can be useful for scenarios, such as needing both a JavaScript file as well as a XML test data file in order to execute a test script. Whether you are creating code snippet libraries or test data variables, automation layers allow you to link the produced set of optimized test cases to your existing framework.

Some testing frameworks require wrapper code to execute test scripts. A Wrapper can be used at either the flow, test case or test step level to eliminate writing code that is consistent across processes. These pieces of code begin, end or adjoin individual test scripts. Headers and Footers designate these prefixes or suffixes and are completely customizable according to your needs.

In-Sprint Test Automation Practices 1

The Merged Scripts option is also a way to mechanically prepare scripts upon export. If scripts are merged, only one script file will be exported for a set of test cases, rather than an entire set of individual files. One example of how this feature could be helpful is if a Header opens an application in a web browser, test case scripts can be merged, and a Footer tied to the end to close the browser.

Where to Start

All of these features are easy to apply and available to make your In-Sprint Automation practices as painless as possible. However, delving through so much information at once can be overwhelming. The best place to start is to step back and prioritize what is the best area to concentrate on to achieve your long-term goals. Creating a configuration file or automation layers can exponentially accelerate script creation, but they do require a time commitment on the front end. With your In-Sprint Test Automation practices in full swing, then the result for the next release, and all future releases, is faster application delivery, increased application quality and reduced maintenance costs.

Your Next Step

Join this web seminar to learn how in-sprint test automation practices can help you:

  • Shift testing all the way to the left—to your business requirements design phase
  • Automatically generate test automation scripts for both open source and commercial frameworks
  • Achieve maximum coverage with the smallest set of test cases, directly from clearly modeled requirements

Start your Free Trial of CA Agile Requirements Designer today and fast track your In-Sprint Automation practices without delay.


Alyson Henry

Alyson Henry is a Technical Presales Consultant for CA Technologies based out of Plano, TX. Prior to CA, she worked as a sales engineer and graduated from Texas A&M University. Today, Alyson specializes in model-based testing as well as web-based performance testing.