Agile Testing On The Rise – Boon or Bane?

Agile – has become the trend of IT. Most of the projects are AGILE nowadays and the role of a tester is very significant.

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 these decades, Agile has 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 a story, they deliver with minimum monitoring

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.

A 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 the 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.

A tester’s role in Agile has evolved from the 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 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 IA (Impact Analysis).

3) Part of 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 help with speedy testing of repeating tasks. But, 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 understanding 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 best work if:

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

Recommended read => Groundwork For A Successful Agile Journey

Agile Testing Quadrant:

Apparently, Agile Testing would work better 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, tester’s defects would not be considered. This is a challenge because most testers possess only domain knowledge. Currently, a tester can contribute on functional, regression or impact related testing activities. Expecting code/unit/story based testing activity is too much 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 acceptance testing the tester can enhance user stories like the product owner to make the product more likable in the market.

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 goes 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 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 number in which each number would be the sum of two preceding numbers – When we say this it is evident that Maths 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. But, 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 next and move the organization to next level. This is something that we tend to forget in AGILE.

Bottom line is, we are paying more attention to “I estimate I deliver” and not thinking about: “Can I do something beyond? Can I learn something beyond? 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; I have a tester to test my code? The developer accountability is missing.

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

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 project’s success. Else, efforts put in by the testers would go in vain.

Too many questions unanswered…

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

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

1. A tester is not good in white-box or glass box testing – But the expectations sometimes is that they should be.
2. The tester could contribute towards the product/project requirements. But 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 provided:

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 for services mode when it is pure development. Iterative development should be stopped till prototyping phase. Through this, Organizations can control projects better and hold its HISTORY.

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

So, this has been my most candid opinion about Agile. What do you think? Please comment below.