Agile Methodology - A Tester's Perspective
A test consultant's perspective of the impact to testing for projects based on Agile Methodology.
What is Agile Development?
"It's not the strongest..... Nor the most intelligent..... But the Ones most responsive to Change!" - Charles Darwin
If Charles Darwin was around today, he might summarise it as adaptability.
Adaptability is the primary principle underpinning Agile Development. The transfer of project control to the customer and a communal purpose shared by all to strive towards the customer's objectives and requirements is fundamental to Agile and why its claim to adaptability is strong, as it is responsive!
The core elements applied by Agile development to achieve adaptability and customer control may be summarised as:
- Well Designed Architecture: The system architecture is designed to allow variations to support changes in directions in which the customer may seek to take the project
- Customer Control: An iterative approach where the customer assesses progress, reaffirms the next phase of activity (iteration) and confirms the commitment to subsequent phases based on historical performance are key
- Evolutionary Delivery: Post architecture design the project schedule is typically split into stages of between 2-6 weeks. Each stage delivers releasable functionality. Delivery continues in stages until:
- number of planned deliveries completed
- customers seeks to stop, hopefully due to being satisfied with what is delivered
- the funding runs out.
- High Level Requirements: Like traditional waterfall projects after the software concept has been agreed the high level requirements are captured. Unlike traditional waterfall projects detailed requirements are not captured until a commitment has been made to deliver those requirements in the impending stage
- Cross Functional Team: The team consists of all the skills/knowledge necessary to complete the project's objectives
- Experienced Team: The practice to minimise documentation relies on relevant and inherent knowledge being held within the team. This is in keeping with the principle of LEAN (least waste) processing. Risk is in determining the scope of document minimisation
- Micro-Monitoring: Progress is tracked daily so any schedule issues should not be undetected for more than a day
- Continuous Testing: Testing is continuous from the capturing of high level requirements to the release of the final product.
Testing within an Agile environment is a refreshing difference to traditional (waterfall) based projects. On more traditional projects testers are generally viewed as a resource who is engaged to detect bugs. So the tester will often only be engaged towards the end of development as part of the "testing phases". Though industry best practice such as encapsulated in the V Model highlights this as not efficient or effective, it is still unfortunately common practice.
It is not uncommon for a tester to find the earlier phases of requirements, analysis and design, specification, program coding and programmer's testing have taken longer than originally scheduled and the common approach to realign the project is to shorten the testing phase(s). Further, a tester may find their purpose being to "certify" rather than quality assure - meaning the running of predefined scripts, data and outcomes which have already been applied by the development team. The tester finds their role to be little more than an automaton logging variance with little capacity to participate in the assurance of satisfying compliance to business requirements. Agile methodology recognises the commonality of this situation and seeks to resolve the risk of this occurring.
Extreme Programming (XP) has become common within the software industry. Test Driven Development (TDD) though technically not an Agile practice is very often used together with XP. With TDD, once the requirement has been agreed, each function is assigned to a build unit to develop. The build unit consists of a developer and a tester, jointly looking at the specific requirement and determining how to implement the feature. The developer wears a designer hat while the tester takes a compliance perspective. Team working is fundamental to success and an ability to accept and provide critique without offence, being given or taken, is vital.
TDD gives the tester a fantastic opportunity to contribute; spot issues before anyone has written a line of code. The opportunity to reduce waste from unnecessary or incorrect specifications, however minor is significant for all. Project managers like to manage risks, the earlier the better - TDD delivers this. Developers like to develop programs people want to use - TDD supports this. Customers want systems that recognise their business requirements and not processes and documents that baffle with focus on technical specification only - TDD brings this. Job satisfaction and recognition is something everyone wants - to the tester TDD makes this much more achievable.
From a tester's perspective, Agile management processes like SCRUM focus on hitting problems upstream rather than downstream in the functional testing phase. With SCRUM the development teams are cross-functional collaborative entities enabling any objective to be looked at from many different perspectives. Success and failure are a team responsibility, greatly reducing the "them and us" type of scenario common between business, development and test teams.
TDD has become firmly accepted and is reflected in tools aimed at supporting the concept of thinking about the tests before writing the code. One common example of this type of testing tool in the .NET arena is NUnit. Many a project that has sought to exploit the value of NUnit by using it to build up a catalogue of regression tests that can be run unattended whenever new code is added to the project, so ensuring subsequent development stages don't corrupt previous builds unnoticed - two steps forward, one step back.
The author's experience of Agile suggests it is a set of simple yet powerful development practices that are proven to support rapid development of software that is fit for purpose. There are no guarantees. Success is driven by many factors, not least consensual understanding and commitment of what is required, how it is to be delivered and who is responsible for what, coupled with a desire by the team to equally share in success and failure. The concept of walls between customer and project team, developer and tester, client and project manager, architect and developer and any other relation need to be put in the dustbin.
Agile project testing is a continuous process that runs all the way through the project time line. This increases the opportunity for interaction between the customer, project manager, developers and tester.
Software Project Survival Guide (1998) Steve McConnell
RAD Taming Wild Software Schedules (1996) Steve McConnell
Agile Project Management with SCRUM (2004) Ken Schwaber
Managing Successful Projects with PRINCE2 (2005) Office of Government Commerce
Agile Software Development.com
Agile Testing Video Link