Why is everyone talking about Agile these days? What are the outcomes we get after we implement Agile practices? Do we want to increase productivity and efficiency? Do we want to deliver quicker? Do we want to decrease the time to market? Do we want to deliver more features to our customers?
It is none of the above. My friend Mazdak Abtin, one of the greatest Agile Coaches in Melbourne, uses a very intriguing metaphor to explain agility. Which one do you think is more Agile test cases at selenium online training – A kangaroo, a car, or a bullet train?
And the answer of course is the Kangaroo. Agility is not about speed, it is about changing direction. It’s about being nimble and light-footed. Of course the bullet train is the fastest of all, but it is the least agile.
The goal of agility in organizations is to make it easier to change direction. The environments that we are operating in are changing so fast that Agility today is not an option, it is required for survival.
When we want to change direction fast, especially when we have large scale and complex software solutions, the ability to automate testing becomes imperative.
We want to experiment fast, and implement changes fast. So we need to make sure not only regression testing can be done as quickly as possible, but also progression testing can be done quickly. In addition, we need to be able to maintain those automated tests with ease. At the end of the day, it’s all about being light-footed and nimble 😉
In Agile we talk about the concept of shift left in software testing. In this approach, we try to shift testing to as far left as possible. This shifting left is normally achieved via automation of testing and early collaboration.
The diagram below shows how the simplified V-Model of how software testing looks like when we apply the shift left mentality (as opposed to the shift right approach):
Agile takes test automation to the next level by merging the testing process with the requirements definition process. When we talk about shift left we are not only talking about writing our automated tests first and then writing code. We are actually talking about using tests to define the features that we are building.
We call this specification by example. selenium online training Hyderabad One of the methodologies we use to define specification by example is Acceptance Test Driven Development (ATDD).
In Acceptance Test Driven Development, our Agile team (which may include testers, developers and analysts) works closely and collaboratively with stakeholders or customers to define the requirements using acceptance tests. In this technique, numerous workshops are held before the coding starts, where the team writes acceptance tests for the features that are going to be built. Then these acceptance tests are going to be used as the requirements definitions to write code against it.
Then these acceptance tests are going to be automated while the code is being written or even perhaps before the code is written. So initially because there is no code yet, all the tests are going to be failing. As our features get built one by one, these tests start to pass. Until they are all green 🚦
This means we can use the percentage of the passing test also as a reporting metric to figure out what percentage of the features have been built.
If we simply follow the process of automating our acceptance tests first and then writing code, it does not mean we are doing Acceptance Test Driven Development. Acceptance Test Driven Development has the following four tenets as defined by Large Scale Scrum.
In Agile environments, we should be using some variation of ATDD process for all levels of testing. For example, we could use Test Driven Development (TDD) for our unit testing. And on the system level, we can use Behavior Driven Development (BDD) to write our automated system tests.
With BDD we could use given/when/then format to define our requirements and test cases on a system level. BDD helps us have conversations between developers, testers, customers, and other stakeholders using a common language and aligns us with our system behaviors. Tests written in this format can also be easily automated using various test automation tools that are available in the market.
As it was mentioned at the beginning of this article, to maximize agility, it is imperative to automate as much as possible. Automation is not only for unit tests, system tests, and acceptance tests.
Elisabeth Hendrickson, the author of the mini-book Exploratory Testing in an Agile Context, dares to state that: “I do think that if you can write a manual script for a test, you can automate it.”
We need to be automating on all levels for both regression and progression tests. We need to bring in the culture of automation and shift left to everything from Security testing, to PnV, QA, and Compliance testing.
This practice is also called “building quality in”. Testing done at the end will not ensure quality. selenium training and Testing at the end is an inspection process to prevent low quality products from being released. But it will not ensure our product is built with quality. By using the techniques we have defined here, we will be building quality in our product.
