Agile Testing – An Overview
EXTRACT >>
Introduction
Software testing can often be a slow procedure, especially when it’s carried out following traditional business principles. Scheduled meetings, deadlines for the next version to be discussed and the need for every department to sign off on results impose endless delays and make it hard to get a product deployed before it’s already obsolete. It’s very frustrating, which is why more and more developers are turning to methods that go by the promising name of Agile.
The word agile implies speed, flexibility and creative freedom, so it’s sometimes applied to any less structured way of doing things, but when it comes to software development it usually refers to a specific process outlined in the Agile Manifesto. This was put together in 2001 by a group of software engineers frustrated by the outdated procedures being followed. Seventeen people gathered in a ski lodge in Snowbird, Utah, to rewrite the rules of their industry. In the software community their conference has taken on an almost legendary status and their philosophy is widely followed.
The 68-page Agile Manifesto is a set of principles geared at improving the development process. Drawn from a variety of workflow systems – Scrum, Lean, XP and others – it filtered out the most valuable techniques and assembled them into a way of thinking that encourages fast, adaptable design. They summed it up in a brief statement:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
That statement sums up the basics of Agile – it’s focused on goals instead of processes. It aims at flexibility and responsiveness. It’s all about getting the software you want, not the software the process delivers.
Agile sounds like a great idea, but implementing it can put many people off. Traditional software design processes are based on tried and tested procedures imported from manufacturing industries. They’re not tailored for the very different processes involved in developing software, but they do work and their familiarity is reassuring. To do Agile properly means a radically different way of working and for many the step into the unknown is intimidating. It means breaking down the boundaries between developers and testers, forging new connections across teams and abandoning a lot of the documentation and checklists that usually go along with the design process. Instead of teams handing the product back and forth as it proceeds through a series of carefully laid out steps the workflow is far more collaborative and dynamic. To traditional engineers Agile seems to throw out most of the traditional quality safeguards, but in fact it replaces them with a whole new set that are far more likely to identify issues before they threaten the project.
If you want the benefits of Agile testing, but you’re unsure of how to go about implementing it in your own business, then this book is for you. Inside you’ll find a clear explanation of how Agile works, all you need to know about its principles and how to make it work for you. We give you real world examples plus information about some of the potential pitfalls and how to avoid them. By the time you’ve finished you’ll know how to get started, what to expect and how to keep everything efficient, trouble-free and above all Agile.
Agile isn’t something you do. It’s something you are.
How Does Agile Testing Work? – Understanding The System
Before implementing Agile testing it’s vital to know exactly what it is and how it works. Failure to understand this is the most frequent cause of unsuccessful experiments with Agile. It’s understandable because it is a radically different way of working, but you’re aiming for success and that means doing your homework before starting the switch.
The Linear Approach
As software companies grew in the late 1970s and early 80s most of them adopted the familiar development process used by traditional engineering companies. Often called the “waterfall,” this is a linear process with a number of clearly defined steps:
- Requirements – The customer submits their list of requirements for the software, outlining what they need it to do.
- Design – The software architecture is designed from the requirements.
- Implementation – At this stage the code is written.
- Verification – The software is tested to make sure it’s stable and does what the customer wants it to.
- Maintenance – Any issues with the software are corrected.
In practice the software often moves between the last three stages several times as issues are identified and resolved. Each time this happens delays can occur. The main reason for delays is that developers and testers are set up as separate groups at different stages of the production cycle; every time the software is changed, or an issue is identified, it moves between the groups. Because what should happen at each stage of the process is clearly defined the developers are always aiming to deliver a perfect piece of code to the testers. The testers, in turn, are looking to identity every bug in the software and generate a comprehensive fault list to send back.
The waterfall method is tried and tested and has been successfully used by engineers for decades. There are times when it will give good results. If your job fits the following criteria, it’s likely to be a suitable choice:
- Requirements are well known, clear and unlikely to change
- The product definition is stable
- The technology is understood
- All required resources are freely available
- The project is short
On the other hand, if those conditions aren’t met there are clear disadvantages. Here are the main ones:
- Once an application reaches the testing stage it is very difficult to go back and change anything that wasn’t well thought through at the concept stage
- No working software will be produced until late in the life cycle
- High levels of risk and uncertainty are involved
- Not suitable for complex and object-oriented projects
- Not a good option for long or ongoing projects
- Not suitable for projects where there is a moderate to high risk of changing requirements
Before beginning a project it’s vital to assess how you expect it to develop throughout its life cycle. If the criteria for waterfall development are met, it’s fine to proceed using that method. Otherwise it’s best to look for —