Bloggo back to the blog
Article: Agile Thinking by Graham Parsons-->
The Agile Anomaly
As an avid advocate of Agile development processes, I am aware of a strange anomaly that surrounds testing within the Agile environment. While the purpose of Agile is to ensure that software is developed in a progressive way – with the focus on checking that an application works at every stage or iteration – in the majority of cases only functional or unit / acceptance testing is carried out throughout the Agile process. I don’t believe that I can be the only one who has thought about the conspicuous question…what about performance testing?
The norm within our industry is to check that an application will perform or scale at times of peak user traffic at the very last minute, when a project is nearing completion and an application is approaching launch date. Why is this considered acceptable? At the risk of pointing out the obvious, this approach has a clear and fundamental disadvantage: it runs the risk that a significant performance defect may only be discovered after months of development work and / or days from application launch. If this risk becomes a reality, it can be hugely detrimental from a commercial perspective:
• Wasted development time and resources – If the performance defect was implemented into the code base within the first iteration(s), yet not discovered until several months later, then the development time spent building on the defective code, and the budget that has enabled it, may have been to some extent wasted.
• Missed deadlines – The identification of a problem that needs to be resolved when a project is nearing completion, will undoubtedly result in unforeseen and unscheduled time required to put it right. Software or application launch deadlines might be missed and this can lead to adverse financial and reputational consequences.
• Overspend on budget – The extra development time and expertise required to resolve a performance issue may lead to original budgets being exceeded.
• Delayed receipt of software / application benefits – If the software or application was being developed to deliver increased revenue or lower business costs, a delayed launch date will result in a delay in an organisation receiving the associated benefits.
• Reputational damage – If the application launch was publicly anticipated on a certain date, thanks perhaps to a marketing campaign promoting its availability, the failure to launch on time could result in reputational damage, leading to reduced customer loyalty, negative brand perceptions and ultimately lost revenue.
Another disadvantage of performance testing at the end of an Agile project, is that the quality of testing may be compromised to suit diminishing budgets and a shorter-than-anticipated testing window, resulting from seemingly inevitable development over-runs. Testing shortcuts may lead to an application that appears to perform and scale under heavy user load, failing when it is launched in a real user environment.
So why is performance testing carried out in the latter stages of the Agile development process, rather than throughout it? The answer is, as we all know, surprisingly simple. It is common knowledge among the testing community that traditional performance testing tools, which require complex scripting, can add weeks to the development timeframe. I fully agree with my peers that to undertake the process of writing, testing, correcting and re-testing the script code for the test tool itself at the end of every Agile iteration would just not be commercially viable, both in terms of timescales and budget. But what if there was a new, much simpler solution…?
A New Era in Performance Testing in the Agile Environment
Recent progress in the evolution of performance testing tools is set to change testing capabilities within the Agile development community forever. The introduction of new zero-scripting tools has drastically cut the timescales required to configure, execute and analyse a performance test, from weeks to days. Using the new tools, test assets can be updated and tests repeated within a matter of hours for subsequent iterations.
These solutions can offer unprecedented performance testing timescales, while delivering the same standards of correct and realistic testing as complicated traditional tools. While vast sections of the Agile community are yet to become familiar with these zero-scripting testing solutions, they have already found a band of early adopters among some forward thinking Agile organisations. Early feedback is very positive and shows that these tools address a very real need within the Agile marketplace. Scriptless and easy to learn, they can be implemented by any member of the IT team, which negates the need for expensive specialist skills to be bought in. The result is that in some cases this generation of tools can deliver time and cost savings of up to 80% when compared with traditional test tools, which are based on complex script code.
For the first time, application software performance issues can be quickly and easily identified and resolved as they are implemented, rather than at the end of the Agile development process. The result? The Agile development community stands on the edge of a performance testing revolution; greater efficiencies in project management, timescales and costs are now within reach and closer than they have ever been before.
Graham Parsons is CEO of Reflective Solutions, a leading provider of performance testing and monitoring tools and services.