Thursday 13th December 2018,
SQA²

How To – Automate BBT Graph

Everett Khim April 29, 2015 BBT - How To No Comments
automation_2_w10241

Using Behavior Based Testing best practices and principles, in many ways than web applications, web services are relatively easy to describe as a behavior as they accept a well-defined sets of input parameters and return a well-defined result. So, they fit well into a simple or typical BBT-style of describing a behavior.

how-to-automation-web-service

 

Let’s take a look at a simple pixel tracking web service which fires off data into a queuing services and store data in a database. In this example, we first build our URL with the parameters located at the far left (our contexts and events) which will simulate an individual emitting from the Pixel Service Front End (PFE), then we validate the data successfully stored in our database (our outcome). A well-defined behavioral inputs returns a well-defined results. Simple enough!

The provided graph will generate the following positive and negative test cases:

how-to-automation-generated-test-case  

Now that we are familiar with the graph  provided, we will begin automating by identifying the scripts required to automate to handle all the positive and negative generated test cases above. Scripts is a sequence of instructions that is interpenetrated and called when executing our test steps.

Test Scripts:

  1. impression id
  2. session Id
  3. page type
  4. domain
  5. artist Id
  6. major category
  7. timestamp
  8. browser Id
  9. request
  10. artist stored in memcached by BID
  11. artist stored in memcached by PID

Creating a script in our BBT framework is relatively easy compared to learning a programming language allowing QA profressional with little to no programming experiance to quickly automate any requirements. Starting off, an empty script is needed for each listed test scripts provided above; these test scripts are related to the object (contexts, events, and outcomes) in our graph. By clicking on TEST CASES tab in the navigation menu and clicking on add new test case this will open a blank script  template.

how-to-automation-new-script

 

Under Test Cases, our title will match objects in our graph, scripts name provided in generated test cases as our automation will call the script name when executing postive and/or negative test cases.

how-to-automation-script-name

Under Keyword Script tab, we can provide conditions to handle both TRUE and FALSE states as we will need to determine the sequence of steps to execute when executing positive(TRUE) and negative(FALSE) test cases. The conditions below reads, IF our script state({ScriptState}) evaluate to TRUE (positive test case) then we execute the step(s) within the condition block ELSE IF our script state evaluate to FALSE (negative test case) then we execute the step(s) within that condition block. Similar to any programming logical conditions!

how-to-automation-keyword-script

To better understand the Keywords in our script, StoreParameter will store the key/value pair (key: {provided in ‘OnDemand’ Value}, value: {provided in ‘Expected Value’}) into a dictionary which is to be used in our Request script to build our test URL for pixel service. Now, our condition reads, if TRUE THEN StoreParameter aid=123456 in dictionary ELSE IF FALSE THEN StoreParameter aid= in dictionary. We can apply this same logic to the following test script provided below as it will be identical aside from the key/value pairs we will be storing.

Test Scripts:

  1. impression id
  2. session Id
  3. page type
  4. domain
  5. artist Id
  6. major category
  7. timestamp
  8. browser Id

Our outcome can be applied in a similar manner. We will first need to determine what is the positive state of our outcome and what is the negative state of our outcome. When a pixel tracking service is fired, we want to verify the data is stored properly in a database; this would be a positive assertion for when our script state. While the negative test is our data does not exist in the database as providing an invalid key/value pair will not allow the data to reach the database; this is our expected assertion for when pixel is fired with invalid data (For example, aid is empty).

how-to-automation-keyword-script-part2

We have within the condition block for a TRUE script state, a positive assertion for valid data, by querying (get bid:{dictionary value}:adp) database to validate the data is stored properly. The negative assertion is to validate by querying that the data does not exist in database as we would asserting it positively.

how-to-automation-keyword-script-request

Lastly, our request event will generate the test URL for us to fire. As events will always generate as TRUE, we will only need to provide the sequence of steps as providing conditions is not necessary. Our Request keyword will generate a test URL similar to the following:

  • http://<host>:<port>/api/pixel?imp=RTf435S2g&bid=epHFN8tglfS16JyBdhS0zGtJMKceLPIPHXoKLSP1WDJlqJQh1ml_nalUie0mI1mCZa5yZq49&pid=FS__1WMkWgvt7oIWJU2U_KgEBnqG9xmoMin6gQTMYCenz_HVqxVoLqELgvA&eid=4CloScmTCPehb0ry2Yj6L1HCJQHCymcN5Rkxh&pgt=checkout&dmn=us&aid=1724031&mct=10001&cfc=111&tqn=3&ort=11&tct=22&ftt=234&tsu=1683241022

As an overview, we simply provided scripts for each objects on a graph to handle positive and negative test cases, by modulizing our objects and/or scripts we provide an approach to better maintain our scripts/graph, quickly identify any abnormalities, and allow resuability within other graphs.

In the next blog, we will take a deeper look into automating BBT graphs.

Like this Article? Share it!

About The Author

Leave A Response

You must be logged in to post a comment.