In the last few years the software industry is abuzz with words around ‘Agile’. There are acronyms – DSDM, XP, ATDD and expressions like Kanban and Scrum.
What do these mean? and how are they different from traditional forms of management thinking and specifically, testing approaches?
Before all else, being Agile is a culture-mindset with clear management commitment given for the change not only from the delivery organization but with entire fleet of support systems getting fine-tuned by addressing the change in culture.
In terms of software development, how is Agile principally different from conventional approaches?
Agile methodologies value Individuals & interactions over process & tools, working software over comprehensive documentation; responding to change over contract negotiation; and finally values, customer collaboration over following a plan.
How does one inculcate an Agile Mindset?
Be it the Dynamic Systems development method (DSDM), Feature Driven Development (FDD), Extreme programming (XP), Kanban, Scrum, or Lean; the various Agile methodologies bring significant improvements when implemented.
Most practitioners advocate Agile adoption when product delivery acceleration or an enhanced ability to manage changing priorities is needed. Agile methods have impacted productivity, software quality improvements, and also increased delivery predictability.
Industry surveys over the past few years point out Agile adoption has direct bearings on uplifting team morale, reduced project risks, improved business – IT alignment, and quicker time to market.
In project planning and execution scenarios, how is Agile different from the traditional (or the waterfall)?
Simply put, the difference lies in how the three project variables – time, costs, scope – interplay.
Waterfall projects are flexible on time and costs but iron-clad on scope. They are plan driven.
Agile methodologies are ‘value driven’. They are flexible on scope but fixed on time and costs.
With general understanding of Agile methodology in place, let us for a moment examine how testing differs in “waterfall vs Agile” environments?
Before we comprehend Agile Testing Approaches in greater detail, let us discuss the widespread misconceptions in adopting Agile.
(Here are few verbatim challenge statements most Agile practitioners encounter)
“Agile means no documentation?!”
“Tight iteration- no time for manual regression.”
“How can offshore agile testing possibly work?”
“Traditional automation no longer sufficient.”
“Testers need to understand coding concepts & language?”
“Limited time for integration and performance testing”
One way to dispel the mentioned misconceptions is to step back and holistically understand how the various elements of Agile testing come together
The relationships between testers and everyone else on the project team is substantially different compared to traditional project environments. The critical need for Agile testing teams and the testers, is to work closely with the client, programmers, domain experts.
That is the reason why Agile has proven more effective for projects that constantly undergo changes in requirements; projects that need frequent checkpoints and monitoring, and are suitable for clients who already have mature relationships.
The need for constant collaboration and high degree of alignment is not difficult to understand when we see that Agile adoption frequently encounters the following concerns:
- Lack of up-front planning
- Lack of documentation
- Loss of management control
- Lack of predictability
- Lack of engineering discipline
- Inability to scale
This surfaces a vital question.
How does the role of a tester in Agile testing environments change. What are the new role requirements?
To meet the challenge of truly being embedded in agile teams, testers need to significantly increase technical and business domain knowledge and also tangibly increase interaction with coders, architects, developers, and business analysts. This calls for enhanced knowledge (business, technical, or both), understanding of automation usage, basic architectural know-how, and also unearthing non-functional requirements. The tester is expected to have a wide and complete understanding of the user stories. And exposure to end user product gives the tester a greater perception to provide a defect free product.
Having understood the broad principles, values, practices and major points of differences between traditional (waterfall) and Agile methodologies, the final focus of this article is on the topic of Defects (more accurately, how defects are spotted and managed)
Waterfall projects work in multiple phases to eventual delivery. And Agile projects manage working software in sprints and iterations. Agile presumes and welcomes change as it is considered an inevitability.
From the perspective of Agile working projects, defects are created in one of two ways.
- Observations are converted to Defects on the last day of the iteration
- Defects are discovered post-iteration
And once logged defects are treated in one of two ways,
- Bundle several small defects into one user story
- Map each major defect to one user story
For teams that are not so strict about working only on user stories, the following approaches are suggested:
- Allocate a “fix defects” story & task with a specific number of hours during iteration planning. Developers fix as many defects as possible within the hours associated with the story
- Allocate one day per iteration for the entire team to work only on fixing defects
Embracing the discipline of quality built into the release enables quicker rollouts, reduced turnaround time and faster time to market thereby ensuring that the business stays ahead of the curve. It also establishes a strong verification and validation process which is very essential in delivering high quality defect free product. Being in the financial sector the regulatory environment ensures strict compliance to the international standards which needs to be embedded, checked and verified before the product rollout to avoid legal and reputational risks. Thus, agile based testing approaches bring all the required pre-requisites for delivering a complete defect free product at a much faster pace.