.png)
Once in a while an idea comes that brings a paradigm shift in our thought process. It is this event where we talk what use to happen before it, and what happened after it. Such events bring a change of tide with themselves and breakthroughs old patterns, wipes them out and establish new ones to help us move forward.
In the world of software, we see this shift with AGILE (and recently Devops) coming into picture. Agile is changing for better the way systems are being built and tested. So lets understand what’s Agile and whats to different about testing the agile way.
What is Agile?
Agile methodology is a set of practices and principles in which requirements and their implementations evolve through a combined effort of self organizing functional teams. This encourages and creates space for a fast and flexible response to change, by ingraining feedback as a mandatory activity in every iterative phase involving various stakeholders. Agile has shifted the product creation cycles from being predictive to adaptive.
One of the most common implementations of agile is SCRUM.
As per the definition of Scrum, from the Scrum Alliance Org, it is an Agile framework for completing complex projects. The Scrum framework is deceptively simple. Note the usage of the word ‘deceptively’. Many organization claim to follow Scrum, but in reality they are not.
Following diagram depicts how a Scrum model looks like
Testing in Agile - Not a phase but an evergoing activity
One of the major differences in agile and waterfall model is the approach to quality and testing of the product. Testing is not a phase in agile, it is an activity to be done with every iterative phase, which is known as sprint. With every sprint a shippable part of the product is delivered to the end users who can use it, as it is developed as well as tested and integrated with the rest of the shippable product part.
The approach of the product development shifts to collaborative efforts amongst different members of varied roles, who actively participate from capturing requirements to the delivery of the product. We have to realize that the shorter sprint cycles forces us to adapt and implement automation of tasks wherever we could. And testing as well is an activity which is an ideal candidate for it.
With every sprint, we will have to test that phase of the product and in addition we need to perform regression test of the code. With every iteration, our code base is going to grow, whereas the time remains the same available to us to test it.
Automation a necessity in Agile
Test Automation is not a choice in agile. It is a necessity. We have to automate the testing, and do it right the first time. However test automation in agile is a double edge sword. Wield it right and it can help you win..Do it wrong and it’s gonna hurt u bad. Based on my experience of working with many complex agile automation projects over last few years, i am jotting down a few points to be careful about when implementing test automation in agile projects
- Our test automation code is not tightly coupled to the UI, as it changing, the object's definition can and will change with sprints.
- The authoring of test scripts shouldn’t be depended on the availability of the UI. Rather we should be able to build our automated test case even before the functionality is available (Yep..it is possible).
- Collaboration is the Key in Agile projects. We need information and we need it fast to adapt to the changing requirement, to fix the failure in time to ship the product. So integration of the test automation is required with ALM.
- The test automation should be available to the development team as well to check their builds for errors as they get built daily by using the platform of continuous integrations.
- The requirements have to created in a manner that every team member understand them clearly and these user stories can be mapped to a single test automation scenario. So an approach to capture requirements that allow all stakeholders to speak the same language definitely helps (yeah..I am talking about something like BDD approach to capture requirements).
So to summarize Testing in agile requires the following.
The question here is, how do we achieve all this, and what tools are available to make this possible? Read on to the next in the series to find out about the solution.
Author
Pallavi Sharma
.jpg)
