Agile testing is a software testing practice that follows the rules of the agile manifesto, treating software development as the customer of testing.
Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.
Since working increments of the software is released very often in agile software development there is also a need to test often. This is often done by using manual testing methods and automated testing to minimize the amount of manual labor. Most often it would not be possible to test the whole software manually before every release hence the use of Automated Testing is highly recommended for Agile.
Agile methods were developed as a response to the issues that the traditional V-Model and waterfall methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed.
A software tester’s role in traditional software development methodology, Waterfall & the V-model can be generally summarized as:
- Finding defects in development products, such as requirements and design documents
- Proving that the software meets these requirements
- Finding where the software under test breaks (whether that is through verification of requirements or validation that it is fit for purpose)
So, what are we really talking about when we use the term “agile” and what are the implications for a software tester?
A tester’s life in a V-Model or waterfall based software project world is, for most traditionally trained testers, the basic process they steps they perform are similar to the following:
- You receive a requirements document which you proceed to review
- You eventually get a requirements document that is considered baseline or signed-off
- You analyze these requirements to create test conditions and test cases
- You write your test procedures
- You then wait for a piece of software to miraculously appear in your test environment.
- You now start executing your tests
- Oh and now you begin re-executing some of these tests as you now start iterating through new builds which are released to fix bugs or they may even include new functionality
- You then reach the acceptable risk= enough testing point (or the fixed immovable deadline) and the software is released
Now, while all the above sounds logical and “easy” to do, the real world we live in makes it not quite so straight forward! Requirements are never complete and there are always ambiguities to deal with. The worst case is the software meets its specifications but doesn’t meet the user needs.
Wouldn’t it be better to build smaller parts of the system, have the business work with the developers and testers to confirm that what’s being built is indeed what they want and need? So lets build the system in small increments, increasing the systems functionality in each release, and potentially deliver a working system at the end of each increment that actually meets the end users needs?
Say hello to “agile”!
Testing from the beginning the project and continually testing throughout the project lifecycle, is the foundation on which agile testing is built. Every practice, technique or method is focused on this one clear goal.
So what does testing now need to know and do to work effectively within a team to deliver a system using an agile method?
The concept of “the team being responsible for quality” i.e. “the whole team concept” and not just the testing team, is a key value of agile methods.
Agile methods need the development team writing Unit tests and/or following Test First Design (TDD) practices (don’t confuse TDD as a test activity as in fact it is a mechanism to help with designing the code). The goal here is to get as much feedback on code and build quality as early as possible.
The desire for information earlier in the development phases is to monitor what the current code and build quality of the latest checked code are. This requirement leads to the use of continuous build and integration practices which provide feedback every time code I checked into the code repository and the system is built, usually on a daily basis.
- Testing is the headlights of the project – where are you now? Where are you headed?
- Testing provides information to the team – allowing the team to make informed decisions
- A “bug” is anything that could bug a user – testers don’t make the final call
- Testing does not assure quality – the team does (or doesn’t)
- Testing is not a game of “gatcha” – find ways to set goals, rather than focusing on mistakes
The article, “Agile testing – changing the role of testers” looks at the difference between a tester on an agile project, versus a tester on a traditional V-Model project.
The key challenges for a tester on an agile project are:
- No traditional style business requirements or functional specification documents. We have small documents (story cards developed from the 4×4 inch cards) which only detail one feature. Any additional details about the feature are captured via collaborative meetings and discussions.
- You will be testing as early as practical and continuously throughout the lifecycle so expect that the code won’t be complete and is probably still being written
- Your acceptance Test cases are part of the requirements analysis process as you are developing them before the software is developed
- The development team has a responsibility to create automated unit tests which can be run against the code every time a build is performed
- With multiple code deliveries during the iteration, your regression testing requirements have now significantly increased and without test automation support, your ability to maintain a consistent level of regression coverage will significantly decrease
The role of a tester in an Agile project requires a wider variety of skills:
- Domain knowledge about the system under test
- The ability to understanding the technology be used
- A level of technical competency to be able to interact effective with the development team
12 Principles of Agile Methods
- Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
- Welcome changing requirements, even late in the development. Agile processes harness the change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the short time scale.
- Business people are developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done – is essential.
- The best architecture, requirements and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjust behaviors accordingly.
Many of these practices we perform everyday in our projects actually align with a number of the principles listed in the 12 principles of Agile Methods.
Of all the roles in a project, testing has and needs to follow an iterative styled approach. Whether it is the requirements review and test design process which iterates over understanding and improving the requirements or it’s the iterative approach to test execution performed against different release versions of the system or simply the normal defect fix and test cycles.
Testing has a natural fit with an iterative based approach. But while being fully agile requires all parts of the development process to fundamentally change, testing has the opportunity to actually employ agile principles without necessarily needing the entire project to be actually following an agile process. The “leap” to agile is therefore not necessarily as large as you may think and can be implemented within the team to make some aspects of the testing process and tasks more effective and efficient within the context of the project.
While testing has the potential to use a number of agile techniques, it doesn’t exist in isolation from the rest of the project team or the business. Involving these groups in what your approach to testing will be is instrumentally to gaining their support with adopting these practices across your testing team.
No comments:
Post a Comment