The SQA2 Blog: Automation, BBT - How To
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.
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:
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:
- impression id
- session Id
- page type
- domain
- artist Id
- major category
- timestamp
- browser Id
- request
- artist stored in memcached by BID
- artist stored in memcached by PID
Creating a script in our BBT framework is relatively easy compared to learning a programming language. Therefore it allows the QA professional with little to no programming experience to quickly automate any requirements. To begin, an empty script is needed for each listed test scripts provided above; because 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.
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 positive and/or negative test cases.
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!
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. It will be identical, aside from the key/value pairs we will be storing.
Test Scripts:
- impression id
- session Id
- page type
- domain
- artist Id
- major category
- timestamp
- browser Id
You can apply our outcome 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).
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. Then the negative assertion is to validate by querying that the data does not exist in database as we would asserting it positively.
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. 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
Overall, 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.
