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.
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:
Whether it is agreed or not, the bottom line is that it is always a fixed price project with Agile.
What You Will Learn:
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:
While these are the common skills, Agile demands the following extra skills from a ‘TESTER’:
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:
Recommended read => Groundwork For A Successful Agile Journey
Apparently, Agile Testing would work better if we adapt to the “Agile Testing Quadrant”.
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”.
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”.
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.
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:
The answer might mostly be YES with agile, but how do we measure it?
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?”
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…
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.