Agile Testing On The Rise – Boon or Bane?

Agile Testing has become a trend in IT. Currently, most of the projects are AGILE and the role of a tester is very significant. Let’s look at this concept in detail through this article.

Even before we touch on Agile Testing, let us understand the concept of “AGILE”.

Agile is a methodology that evolved from our Iterative or Incremental methodology of development, almost 2+ decades of Agile Manifesto. Over the past few decades, Agile has had a very comfortable place in the hearts of Developers, PM’s and Customers.

• PM’s are happy as they feel it is a transparent approach and they are able to deliver what is committed in small sprints/periods
• Customers are happy as they see their product growing in increments. They are able to change the requirements and develop what they desire to. It is flexible to allow for experimentation and faster time-to-market.
• Developers are happy as they estimate the stories they deliver with minimum monitoring

Let’s learn about it in detail.

Agile Testing

Recommended read => Getting Started with Agile Scrum Methodology – The Complete Guide

To better understand the pleasant and unpleasant side of Agile, let’s look at the following financial models in which Agile usually works:

• Variable price with fixed scope – This works well with Agile. Reason being, we can deliver the fixed scope in multiple sprints – but no customer would like it. 🙂
• Fixed price with variable scope – This works best if we prioritize the product backlog with business value and agree to get valuable delivery with fixed price.
• Fixed price, fixed scope – This is more towards the “Death-March project”.

Whether it is agreed or not, the bottom line is that it is always a fixed price project with Agile.

Let us now move on to the role of a tester in Agile:

The role of a tester in Agile is like “Expecting the Impossibilities”.

Traditionally, the target of a tester was to test the modules functionally in an independent phase provided exclusively to a tester. This was the time testers used to explore the product and determine its stability/problems in it. They were simpler times, even though there were a few challenges in some companies.

The tester needed the following things to succeed:

• Good interpersonal skills
• Able to collaboratively work with cross-functional teams
• Provide test results to make clear decisions
• Analytical and logical thinking

While these are common skills, Agile demands the following extra skills from a “TESTER”:

• Provide speedy response to changes without business impact or delivery delays
• Understand the user stories and their acceptance criteria

Also, it is evident that the TESTER terminology used in regular lifecycle models is totally different from AGILE.

Also with Agile, the role of developer and tester is all the same. Both play a role in SCRUM and they are treated as people with their own specialized skills who work together to deliver a quality product at the end of the sprint.

Tester’s role in Agile has evolved from traditional methods. She/he is no longer expected to write test cases and keep executing them.

They have to take on the additional tasks of being:

1) BA – Business Analyst or Requirements Analyst – Testers are expected to provide inputs to user stories. A detailed understanding of the domain/requirement is expected and the development team expects a brain-storming session by the tester.

2) Pair Programmer – Where the testers have to sit with the developers tests the story and discuss the impact of the change, if any. It is believed that the tester can add important inputs to the IA (Impact Analysis).

3) Part of the Test first approach – Sometimes testers are expected to wear the cap of a customer and start testing the stories even before it is developed.

4) Automation Tester – Instead of repeating tasks, automating test cases helps with speedy testing of repeating tasks. However, with Agile, automation teams are expected to test everything fast, not just the repeated ones. So, there is much more pressure on the QA and inefficiency to the process that might force an Agile automation tester to work with unstable system

5) Exploratory Testers – Even though testers understand the scope, working closely with developers and providing value-add to the product are all considered to be a boon in the modern IT world and without quick Automated Regression testing for the previous sprints Agile Testing never works.

Agile in itself has a chance for scope-creep in its methodology if testers fail to automate; the risks to the product’s quality are higher.

Agile testing would work best if: 

• Unit and component tests are done thoroughly
• GUI smoke tests are done in every sprint
• Respect the tests and testers feedback on the add-on to requirements

Recommended read => Groundwork For A Successful Agile Journey

Agile Testing Quadrant:

Apparently, Agile Testing would work in an effective manner if we adapt to the “Agile Testing Quadrant”.

Agile Testing – Boon or Bane

Is it a boon or a bane – Projects implementing Agile from 2000 are yet to get the metrics baselines to substantiate the same.

While we talk about the agile tester’s roles, we should also clarify on the “SCOPE of a Tester” in Agile.

In Agile, a tester is more like a developer.

He is expected to perform unit/story based testing. This demands knowledge about development/code practices. Without this knowledge, if the tester is to make suggestions, it would not help.

Over a period of time, the tester’s defects would not be considered. This is a challenge because most testers possess only domain knowledge. Currently, a tester can contribute to functional, regression or impact related testing activities. The expected code/unit/story based testing activity is too high an expectation and I am sure no tester would fit this perfectly.

Testers can play the role of a product owner and accept the stories developed. While accepting testing, the tester can enhance user stories like the product owner to make the product more likeable in the market.

For example: When a tester is testing a form, he can suggest/enhance features like “I would want to select the end date in a calendar field. It should not be auto-generated”.

Challenges in Agile:

Expectations should be set right when it comes to Agile Testing, else there is a possibility that the testing effort will go for a toss. Some of the factors that help us understand the effectiveness for Agile for a project are:

Metrics – The phenomenal part of project management, “Measure Everything That Results In Customer Satisfaction”.

Customers are more focused on the productivity of resources deployed and the effort spent by them in order to settle their bills. When it comes to costing, customers would have a cost effective approach. Personally, I feel Agile Productivity is hard to measure.

Story Velocity – how many stories were planned and how much could be delivered.

Either it is poker based estimates or Fibonacci that calls for “equalization”.

• Poker based estimates – Every user estimates the stories to be developed based on his expertise. There is an ‘Expertise” factor attached to it and that is always risky.
• Fibonacci – This is a series of numbers in which each number would be the sum of two preceding numbers – When we say this it is evident that math can be fun but when it comes to productivity we cannot consider this to be fun as costing is involved.

Estimates cannot be considered accurate as in FP or Empirical methodology. It is all about AVERAGING there is where we will miss on “Effort spent vs stories completed” We cannot arrive at any concrete conclusion on productivity.

Also read => Automated Regression Testing Challenges in Agile Environment

To Conclude:

Agile is universally accepted and almost 2+ decade’s people have been using this terminology. However, I consider it to be a bane rather than a boon. I would rather do iterative development and give small deliverables to my customers.

The real questions that bother me are:

• I achieve Speed to market 🙂 – But, do I achieve the needed productivity?
• I deliver what the Customer agrees in bits and pieces – Do I achieve the intended purpose of the product?

The answer might mostly be YES with agile, but how do we measure it?

Also Read => How to Cultivate Agile In Your Organization – Issues and the Practical Solutions part 1 and part 2

To further back my point I want to present the following points:

PM’s in the industry feel that they have achieved iterative development and delivered what they have committed. The customer is happy. He is our boss no doubt. But shouldn’t the organization be benefited? We surely need HISTORY. We should be able to learn from our mistakes. We should be able to train the teams on what’s next and move the organization to the next level. This is something that we tend to forget in AGILE.

The bottom line is, we are paying more attention to “I estimate I deliver” and not thinking about: “Can I do something or learn something more? How much can I do?”

Read more => 4 Steps Towards Developing the Agile Testing Mindset for Successful Transition to Agile Process

In our proven models of Software Development life cycle, we always had the ownership – I develop, I unit test and see that there is no defect leakage to the next phase. This is totally missing in AGILE. I develop and I have a tester to test my code but developer accountability is missing.

Finally, a Tester’s life is pathetic in Agile. The tester associated with the developer to perform testing does only black box testing as this is his area of expertise. But there are many more expectations.

With all this in hand, it is the organization and its customers who have to decide on the adoption of this model and the entire UNDERSTANDING of AGILE TESTER to be clearly clarified for the project’s success. Else, efforts put in by the testers would go in vain.

There are a lot of unanswered questions.

Also read => How to Eliminate Flaws of Waterfall and Agile Development Processes 

To list down why Agile testing is a BANE for testers:

1. A tester is not good in white-box or glass box testing – But the expectation sometimes is that they should be.
2. The tester can contribute towards the product/project requirements. However, we cannot contribute towards best practices on coding standards
3. Pair programming – Two developers brainstorm have results – When a tester sees the code, it is always Greek and Latin – Where is the question of contributions?

To make this practice a BOON – It is still possible to provide:

1. Understanding the potential skills of a tester and defining his roles – This can take the project a very long way.
2. Treat tester only as a product owner – Let him first accept the stories developed. There is always a phase for Integration Testing where you will integrate all your stories and test – Let the developer play his/her role effectively by doing unit testing.
3. Organizations have to be clear on agile adoption. This can work better in service mode when it is pure development. Iterative development should be stopped till the prototyping phase. Through this, Organizations can control projects better and hold their HISTORY.

About the author: This is a guest post by Vasanthi B. She has 14 years of experience in QA and QC and is currently working as a quality manager.

So, this has been my most candid opinion about Agile. What do you think? Please provide your feedback/queries in the comments section below. We would love to hear from you.