Test Drive @ Agile Highway

Agile Development” is an umbrella term for several iterative and incremental software development methodologies. One of the great things about agile is that, it’s an approach that travels alongside our mind, rather than a set of uncompromisingly rigid rules that encourages us to modify the implementation as we practice.

I know what it’s like to be looking on at a practice/methodology like agile. It’s an established practice now, which clearly works for the software development teams. When you see that working, and you see how highly people value it, you obviously want to make use of it yourself.

But, I’ve got two peeves in particular, where I think many people misinterpret and mangle the spirit of what agile is all about. We’re trying to prevent this at Indium, and we’d love to hear from others who have ideas as to how to improve this even further!

Peeve #1: 100% Test Coverage & Efficiency!!! No Defects Leaked

Mostly, the mocks above are absolutely true. Yes, changes happen so adhoc in real time agile, that meeting 100% test coverage is a little difficult to achieve as there are time crunches to the Software Testing team;

• For the build to be available
• To document & execute test cases
• To measure test coverage / efficiency

So how do we handle this efficiently?

Well! We have a solution for such demanding situations, as we have seasoned ourselves with various permutations and combinations of approaches.

Majority of them assume that, application is tested thoroughly as there are only smaller chunks of work done in a Sprint and it saves a lot of time. The key things that people really miss out is how much of testing is actually done and how early are the testers in agile projects get involved.

We strongly recommend the shift left technique. The more early the testers get involved, the more efficient the application would be.

The quality of the development enhances when the testers are involved early, especially in Agile Projects.

The Test Driven development strategy makes the tester to document the test scenarios for each requirement in the user stories within the first couple of days of the Sprint plan.

The scenarios include positive, negative and corner cases. These are reviewed and approved by the business and passed on to the development team who in turn would validate their code against these scenarios.

This saves time of rework on coding and also provides sufficient time for the testers to quickly assess the feature against the requirements.

The testers work alongside the development team in their boxes or on any environment that is available. They run through the tests any number of times to verify and validate if it is built in the right way.

The approach recommended doesn’t guarantee Zero defects as the testers do not really have the time to validate the integrated piece but assess only at the unit level and helps in quantifying the completeness of the feature against its requirement. It is 100% tested for its own requirement as a unit and cleared.

Peeve #2: Overcoming Regression Rule

According to the agile manifesto:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

We had this issue when we first introduced the concept of Sprints in our team. The key objective of introducing Agile was with the intent to avoid burn outs of our engineers, by restricting scope and workload to manageable levels, so that, we consistently build and design better software.

The team started off with full excitement and enthusiasm for the first couple of Sprints and were completely exhausted by the end of the 2^nd Sprint, due to the intensity, and we realized that this is not a workable model

For us, it comes down to finding sustainable pace, always. To balance the pace, we adopt a strategy, which paves way for enhancing quality and also meeting the original intent of keeping our engineers happy.

As elaborated in our approach earlier of having the tester tagged with the development team, the key component to address the regression rue’s is to have a different pool of tester(s) who would pick up the unit level test scenarios documented identify the integration pieces, impact areas and create a regression test suite.

This team will always be a Sprint behind but how it value ads is by conducting a thorough line by line vetting of test cases and reporting critical integration / impact issues without the pressure of time factor.

The best aspect of this model is that, it provides flexibility and allows testers to identify gaps that are left uncovered (if any) by the other team.

It also provides sufficient time to have maximum coverage of test cases and uncover all the defects within the Sprint duration.

The defects logged by this team are resolved by a dedicated team of developers who then integrate these fixes along with user stories developed in the next Sprint and the QA regression continues to streamline the application across multiple iterations.

The two teams converge towards the end of the final Sprint and work alongside and ensures that the team meets up the acceptance criteria defined in the plan and signs off in style, driving away safely & securely in the Agile Highway.

Has anyone else found better ways to sleeve off the peeves, post it out in our blog page