Agile Testing

Agile can be implemented incrementally, and can even be added to an existing waterfall project. The key to that is the use of hybrid systems – a mix of the most appropriate parts of traditional and Agile practices

Whether the end of the project is running to schedule or not, it’s going to need careful attention to testing. Agile experts will tell you that the release iteration is not a testing phase, and they’re right. The bulk of the real testing will have been done throughout development, as we’ve already discussed. Some more is still going to be needed though

You’re coming up to a non-negotiable delivery date and it’s taking longer to clear the bug list than you had expected. There are various reasons why the delivery date might be set in stone – the most likely is that it’s written into the contract and the buyer isn’t willing to extend. Most developers would much rather deliver solid software late than a buggy product on time, but either through inflexibility or urgent need the client may insist on delivery by the deadline

If the iterations have been properly planned the core functionality should have been produced first. Some clients may prefer to have the software delivered in a form that meets their most urgent requirements, then incrementally add more functionality as it’s developed. This usually depends on the client’s own corporate culture and structure, as well as the specific circumstances around this release. Larger organizations with a more formalized procurement system are likely to prefer a single, well documented handover than a series of upgrades

A key principle of Agile development is that each iteration should result in working software, even if it doesn’t yet have all the functionality of the final product

If UAT is done thoroughly throughout the project cycle you should reach the Stabilization Sprint with all major bugs, and features that don’t conform to user stories, already rectified

Early in the Sprint a developer will put together a minimal version of a possible solution and ask the customer, “Will something like this do?” If they say no, the developer will try something else and ask again. If they say yes, the team can get to work on developing the demonstrator into working software. That’s user acceptance testing and it can happen very early in the project – even during Iteration 0. Once the initial brainstorming session has come up with a proposed architecture, just ask the client if it matches their requirements

The Agile system of UAT seems, at first, a lot less intuitive – it kicks in right at the beginning of the project, long before there’s anything for the users to accept. In fact it makes a lot of sense to do it this way, because the risks at later stages will be massively reduced. Consider how much effort is wasted when the customer sees the finished software and says “No, I don’t want it to do it this way.” At best a user interface redesign might be needed; at worst the whole system will need a major overhaul. Doing it the Agile way avoids this scenario

User Acceptance Testing (UAT) is a process aimed at confirming the software meets the requirements mutually agreed on by developers and customers

If defects are found at such a late stage fixing them is likely to seriously delay delivery of the project; it’s much cheaper and faster to fix them earlier in the process