Delivering quality & consistency with Automation Testing and living code
Having a web application requires thorough testing.
Typically there are many features interrelated and woven together to deliver a seamless solution to a complex business problem. But finding the time to test all these features when a new release is available is sometimes difficult. Taking the time to test all or most of the features is boring and not exciting at all.
Wouldn’t it be great if this could be automated?!
Indeed! That’s why wisnet chose to perform Automated Testing with their web applications– we’re able to test an application in minutes and obtain reports showing what was tested in plain english and also how much of the code was tested.
We use an approach called “Business Driven Development” (BDD). With this approach, we define the features of our system being tested in plain English and in terms that make it obvious to the casual user what is being tested. Let’s look at a sample Feature that has been defined:
The above Feature has one Scenario – that as a Visitor, I can access a campus. The Scenario has multiple Steps and each Step performs one action such as clicking a link, filling a field with a value and clicking a button. The Scenario is written with a few key words which include “Given”, “When” and “Then” plus “And” and “But”.
This little language is called Gherkin. It’s a precise way to communicate between Business, Development and Quality Assurance teams so all agree upon the expected behavior. The Features and Scenarios are defined in business terms, not with technical jargon.
And what is so beautiful about using this approach to testing is that we are testing the web application in the same manner as a human. We interact with the app as it “comes to the glass” – a.k.a. we are testing what we can see. The automated test interacts with the browser in the same manner a person would.
The following shows a running test.
In the above screenshot, the system under test is on the left. The Features are on the right. During the test, the Steps are actually executing code to perform the step. For example, one of the steps is this:
| And I fill the date “discount_Start_Date” with format “m/d/Y” for time “-5 day”
Looking at the screen we can see a “Start Date” of “3/18/2018” which was placed there by the execution of this one Step. So our BDD Features are living code: the code is not just some words in a text file – they are actually executable statements that interactively test a web application.
In the following picture we see the results of running all the tests in terms of “Code Coverage”. We can see that one area has been tested 91% (green), numerous areas over 50% (yellow) and some areas need more testing (pink).
We run this test everyday and review the results to confirm everything is working as designed.
These tests provides the Development additional confidence that if they are changing code with the inclusion of new features or fixing some bug, they don’t break something else.
We continually add additional tests to increase our code coverage. When we find a bug, we write a our test to replicate the bug and to confirm that it won’t happen again. The best part: this testing is done in plain English that everyone in our company can read and understand the intent.
The hours to test our applications manually would absolutely go through the roof. Using our Automated Testing scripts with this specific project, it takes close to 10 minutes to run 359 steps as shown below.
The takeaway: We’re geeking out over automation testing options and dedicated to delivering the very best and consistent application products for our clients.