Agile Testing On The Rise – Boon or Bane?

Agile is the new buzzword in IT. Today, most projects utilise the AGILE method, where the tester’s role is of great importance.

Before we dive into Agile Testing, let us familiarise ourselves with ‘AGILE’.

Agile is a method emerging from our Iterative or Incremental development approach – it has been in existence for over 20 years since the Agile Manifesto’s inception. Over the years, Agile has gained favour among Developers, Project Coordinators, and Clients.

• Project Coordinators are content because they perceive it as an open approach and can deliver what was pledged in small cycles or timeframes.
• Clients are content because they observe their product evolving step by step. They possess the freedom to modify requirements and create what they aspire. It enables experimentation and quicker time-to-market.
• Developers are content because they predict a story and deliver it with minimal surveillance.

Suggested reading => A Comprehensive Guide to Getting Started with Agile Scrum Methodology

To enhance the understanding of Agile’s pros and cons, let’s assess the subsequent financial models in which Agile is widely implemented:

• Variable cost with set scope – Agile succeeds in this scenario. We can accomplish the set scope in numerous cycles; although, clients might not appreciate this 🙂
• Set cost with variable scope – This model is most effective if we organise the product backlog by business value and agree to deliver valuable attributes at a set cost.
• Set cost, set scope – This frequently results in a “Death-March project.”

Whether it’s recognised or not, the reality is that Agile projects always have a fixed cost.

Let’s delve into the role of a tester in Agile:

The role of a tester in Agile can be equated to “Expecting the Impossible”.

Traditionally, the tester’s responsibility was to ensure the modules’ functionality in a phase dedicated solely to testing. During this phase, the tester had the chance to scrutinise the product extensively, identifying any instability issues or bugs. Although these times were simpler, some companies faced certain challenges.

A tester must have the following abilities to excel:

• Exceptional communication skills
• Capacity to cooperate effectively with multi-disciplinary teams
• Delivery of straightforward test results to facilitate decision-making
• Analytical and rational thinking

While these skills are universally required, Agile expects more abilities from a ‘TESTER’:

• Quick response to changes without hampering business or causing delivery lags
• Understanding of user stories and their acceptance criteria

It’s also noteworthy that the terminology for testers in traditional lifecycle models differs considerably from that in AGILE.

In Agile, Developers and Testers carry out similar functions as part of the SCRUM team. They are perceived as individuals possessing specialist abilities who cooperate to deliver a high-standard product at the completion of each cycle.

The Agile tester’s role has evolved from traditional methodologies. Testers are no longer solely responsible for drafting test cases and executing them.

They are now required to:

1) Act as a BA (Business Analyst) or Requirements Analyst – Testers are expected to contribute to user stories. They must have an in-depth comprehension of the domain and requirements, and the development team anticipates active engagement from the tester during brainstorming sessions.

2) Participate in Pair Programming – Testers are required to work closely with developers, test the story, and deliberate any impact the changes may induce. The tester’s valuable inputs can aid in Impact Analysis (IA).

3) Adopt the Test-First Approach – Occasionally, testers are expected to pretend to be a customer and begin testing the stories even before they are entirely developed.

4) Implement Automated Testing – Instead of executing repetitive tasks, testers are urged to automate test cases. This facilitates quicker testing for recurring tasks. However, Agile automation testers are expected to test everything promptly, not merely repeated tasks. Consequently, the load on QA increases, potentially resulting in inefficiencies in the process, forcing Agile automation testers to deal with an unstable system.

5) Carry out Exploratory Testing – Testers are expected to comprehend the scope, work intimately with developers, and add value to the product. However, without speedy Automated Regression Testing for former sprints, Agile Testing is doomed to fail.

Agile Testing is susceptible to scope-creep if testers don’t automate. This presents a higher risk to the product’s quality.

Agile testing can be triumphant if:

• Unit or component tests are thoroughly conducted
• GUI smoke tests are performed in each cycle
• Testers’ feedback is respected and integrated into the requirements

Suggested reading => Foundation For A Successful Agile Journey

Agile Testing Quadrant:

The effectiveness of Agile testing can be improved by embracing the ‘Agile Testing Quadrant’.

The Good and Bad of Agile Testing

Is Agile Testing a blessing or a curse? Projects that have applied Agile since 2000 have not yet provided concrete metrics to validate their benefits.

While discussing the roles of Agile testers, it’s crucial to define the “SCOPE of a Tester” in Agile.

In Agile, a tester is virtually identical to a developer.

They are expected to conduct unit or story-based coding, which necessitates proficiency in development and coding practices. Without these skills, a tester’s suggestions may not be useful.

As time progresses, the bugs identified by testers may become less noteworthy. This presents a problem as many testers are essentially domain specialists. At present, testers can participate in functional, regression, or impact-related test activities. The expectation for them to solely carry out code, unit, or story-based testing is an unreasonable expectation.

Testers can assume the role of a product proprietor and accept the developed stories, just like in acceptance testing, testers can give feedback akin to a product owner to improve the product’s marketability.

For instance: When testing a form, a tester may suggest or optimize features like “I would prefer the ability to choose the end date in a calendar field. It should not be auto-filled.”

Agile Hurdles:

It’s crucial to form realistic expectations for Agile Testing; else, the testing effort may falter. Some indicators of Agile’s effectiveness in a project comprise:

Metrics – “Quantify Everything That Contributes To Customer Satisfaction” is the primary principle of successful project management.

Clients mainly focus on the productivity of the deployed resources and the effort required to pay their bills. An economical approach is desired. However, gauging Agile productivity is challenging.

Story Velocity – the comparison of planned stories versus the stories delivered.

Whether these are poker-based estimates or Fibonacci, harmonisation is obligatory.

• Poker-based estimates – Each user estimates the complexity of stories based on their expertise. The “Expertise” factor brings inherent risks into the equation.
• Fibonacci – This refers to a number sequence where each number is the sum of the two preceding ones. Despite mathematics being fun, using it to measure productivity may not be the best fit due to costs.

Estimates cannot be as precise as in Fixed Price or Empirical methodologies. It’s all about AVERAGING, which complicates deriving definitive conclusions about productivity.

Also read => Challenges of Automated Regression Testing in Agile Environment

Wrapping Up:

Whilst Agile has garnered universal acceptance and has been a part of the industry for over two decades, I perceive it more as a curse than a benefit. The idea of iterative development and delivering small enhancements to my clients appeals more to me.

The real questions troubling me include:

• Does Agile ensure rapid market entry? But does it attain the desired productivity?
• Does delivering what the Customer consents to, in small parts, genuinely achieve the product’s intended objective?

While Agile may predominantly provide affirmative answers to these questions, how do we quantify this?

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

To further substantiate my viewpoint, I put forth the following arguments:

Industry PMs believe they have achieved iterative development and fulfilled their obligations. The client is content, and they unquestionably rule. But shouldn’t the organisation also gain? We should maintain a historical record. We ought to learn from our errors and prepare teams for the next stage. This is something we frequently forget in AGILE.

In conclusion, we stress on “I predict, I deliver” and ignore queries like: “Can I contribute more? Can I seize a new learning opportunity? How much can I achieve?”

Read more => 4 Stepping Stones to Develop a Successful Agile Testing Mindset for Agile Process Transition

In our established software development lifecycle models, we always took responsibility for what was developed, performed unit testing, and ensured no bugs leaked into the next phase. This sense of ownership is entirely lost in AGILE. Developers create, and testers examine their code. Developer accountability is lacking.

Ultimately, Agile testing can be a formidable task for testers. Test testers co-working with developers may only be equipped to conduct black box testing, as that is their area of expertise. However, the expectations levied upon them are significantly higher.

Taking all these factors into account, it is up to the organisation and its clients to decide on the Agile model’s adoption. The Agile tester’s understanding needs to be precisely defined for the project’s success. Else, the tester’s effort will have been wasted.

Numerous questions still remain unresolved…

Also read => How to Remedy Shortcomings of Agile and Waterfall Development Processes 

Reasons why Agile testing is a curse for testers:

1. Testers are not skilled in white-label or glass box testing – Nevertheless, these skills are often expected.
2. Testers can contribute to product/project requirements but cannot impart insight on coding best practices.
3. Pair coding – The results are evident when two developers collaborate. But for a tester, the code can seem indecipherable – so how can they add value?

Making Agile testing a Benefit – Potential conditions:

1. Identify individual tester’s strengths and delineate their roles precisely. This can significantly contribute to the project’s success.
2. Consider testers as product owners solely. Let them be the first to accept the developed stories. There exists an Integration Testing phase where all stories are integrated and tested. Developers should fulfil their roles effectively by conducting unit testing.
3. Organisations need to have a clear grasp of agile adoption. Agile is effective for service-centric projects focussing on pure development. Iterative development should be paused until the prototype phase. This empowers organisations to exercise better control over projects and maintain a historical log.

About the writer: This is a guest post by VasanthiB. She possesses 14 years of experience in QA and QC and presently serves as a Quality Manager.

So, that’s my candid opinion regarding Agile. What’s your viewpoint? I welcome your thoughts below.