The challenges of Agile testing

Agile principles allow for rapid changes in the development environment and project requirements. An Agile approach allows the application to undergo constant amendments. An Agile tester ought to evaluate client change requests and analyze their feasibility. An Agile tester should not be someone who is merely in the audience. It goes without saying that the tester will face rapidly moving changes and additions to the stories. Lets take a look at some of the challenges faced while testing on an Agile environment.

The race against time:

Considering the product is constantly evolving, it is difficult to keep pace with the incorporated changes, considering individual developers are doing them. Before a showcase, no matter how much you have planned, developers are constantly checking in their code till the last second. This makes it tough for the tester to ensure that the latest check-in has not caused an adverse effect on the entire application. Meticulous planning is the best way to solve this issue.

When is testing done?

In Agile, you’re invariably going to have stories that have dependencies on either other modules or stories, which are yet to be played. So, you never really know when it is the right time to start testing, because this means that you’re going to have a story which is constantly going to evolve and you find yourself testing the same module over and over again. Of course automation tools can come to your rescue then, but you’ll prefer using automation when you’re sure that the module is stable and won’t have constant UI and functional changes.

Constantly evolving requirements:

Let’s visualize a scenario wherein a customer is delivered a showcase for a designated module for the current iteration. Owing to human tendency, customers may point out changes in modules showcased at an earlier iteration. Although this is welcome, it sure has its set of repercussions. Let’s assume developers were to work on bug fixes/new changes for the given showcase will now end up working on not only the change requests of the current showcase but also the ones mentioned by the client for the earlier iterations’ module. This results in the entire team squeezing in their time, effort and energy via working weekends and late nights in order to not only complete developing the next iteration’s but also the previous change requests and changes. This reduces the time for testing, as the developers are still trying to work on the mentioned bugs and new stories.

Relatively less documentation:

Agile mainly focuses on working software over comprehensive documentation. I’m not saying that Agile principles don’t allow for documentation but it’s certainly relatively less than traditional waterfall. It’s important for the tester to understand the iteration’s intended scope and relevance. A QA can be completely ignorant about the most crucial aspects of a module, if the story is badly written. His test cases probably will not even touch those aspects and you may end up with a surprising reaction from your client during the showcase. So, it is essential for a QA to keep up with the evolving and quickly moving stories because for all you know the stories may not even be updated with the latest client requirements.

Inadequate unit testing:

When a developer performs a unit test, not only does he understand the basic navigation and relevance of the functionality of the module but also comes across with defects, which may have caused substantial refactoring. When a module comes before a QA for testing without a unit test, he may end up with blocking issues or quite a massive number of bugs which may even account to an exit criterion and in turn cause further delays in delivery. Most developers do not unit test their modules which accounts to a testing challenge for a tester.

Of course, the above-mentioned pointers may be touching upon the surface level of the challenges faced by a testing team in Agile. Nonetheless testing in an Agile environment can be challenging, yet fun! So don’t let anyone tell you otherwise!

Compassite’s Protractor: A Novel Solution

A recent development at Compassites has throttled the advancement of agile testing technology in the software world. The framework that was developed, known as Protractor, is a technique by which rich internet applications can be tested in a way that minimises redundant coupling between equivalent states of the server. As demonstrated in this recent whitepaper published by Compassites, this reduces the sluggish run-times that are commonly associated with agile testing methods and hence makes it a major breakthrough in the area.

Ankita Tiwari is a Computer Science student at Symbiosis Pune and currently working as a Quality Analyst with Compassites Software Solutions. She is an enthusiastic learner and absolutely loves gaining insights on the current trends of technology. The challenges involved with strategic decision making allures her. Stagnancy and monotony are the two things that drive her to strive for more out of life.

Leave a comment