OCS Consulting Plc - IT Specialists
email link to info@ocs-consulting.com email link to info@ocs-consulting.com
image to represent OCS Consulting - IT Specialists
agile methodology - a tester's perspective

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:

back to top

Agile Testing

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.

back to top

In summary

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.

References

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 Manifesto

Agile Software Development.com

Agile Testing Video Link

XP Programming.com

Developer.com

NUnit.org

back to top