The SQA2 Blog:
Data Driven Scripts
In our blog, How To – Automate BBT graph, we began to understand the simplicity of automating a BBT graph. We did so by creating scripts of an example behavior for each object. We also saw how to handle negative and positive states of a test scenario. In this blog, we will improve our scripts to be as effective and efficient as possible. We will do so by diving deeper into creating flexible scripts. Scripts that allows simple maintainability when requirements change in our application. Ultimately we only update our cause and effect graph.
Automating login behavior
Starting with a basic example of a login behavior. It requires a user to land on login page, enter username and password to successfully login to an application. We will focus on this example to simplify our understanding of data driven scripts. This is a very basic example to demonstrate the use of true states and false states as these functionality provides us the ability to handle conditions and/or entering data by storing and calling dictionaries key/values from our true/false states as seen below in our example:
Keys and Values
Each individual column, for example ‘username’ in Reporting Username context, are keys (column) for each values (row) we provide in the true and false state. Generating test cases for these contexts, events, and outcome will generate both negative and positive test cases by accounting true/false states in the permutations engine which provides us with better coverage for our functionality, in addition, provides the ability to create data driven scripts to increase the flexibility and maintainability of our scripts. To understand how we can utilized data tables in our objects (contexts, events, and outcome), we will need to understand how the data in our graph is being stored in the simplest form.
All data in an object is stored into a dictionary. See example below, where columns are the keys and the rows are the value.
To obtain the values within the dictionary for our script, we provide curly braces surrounding our key name. This returns the value to our script. In the example below, we are executing the keyword “ObjectSetValue”. A keyword used to enter a value in a text field in the login page. By providing a key surrounded in curly braces we avoid hard coding any values. Instead, we utilize the data table from the context “Reporting Username”. This passes the values allowing us to update these values in the graph level. Making maintenance and reusability simple.
Avoid hard code
As an overview, we avoided hard coding our scripts to allowing reusability. And by implementing this approach we have the benefit of maintaining automated scripts strictly within the cause and effect graph. Requirements change constantly. We can determine the benefit of creating a data driven script compared to a script with hard coded value by using BBT features to the fullest extent.