Simply put, it is the testing practice that follows the agile manifesto, treating development as the customer of testing. In this light the context-driven manifesto provides a set of principles for agile testing.
First let me list the Agile Development Methodologies that I a aware of:
- Extreme Programming (XP)
- Adaptive Software Development (ASD)
- Feature Driven Development (FDD)
- Dynamic Systems Development Method (DSDM)
- Testing is the headlights of the project- Where are you now? Where do you headed?
- Testing provides information to the team- This allows 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 “gotcha”- Find ways to set goals, rather than focus on mistakes
- Test-First Programming
- Pair Programming
- Short Iterations & ReleasesRefactoring
- “User Stories" Acceptance Testing
Developers write unit tests before coding. This
- Motivates coding
- Improves design (reducing coupling and improving cohesion)
- Supports refactoring (Refactorting --> “Changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”.) - Make the simplest design that will work. Add complexity only when needed. Refactor as necessary. Refactoring requires unit tests to ensure that design changes (refactorings) don’t break existing code.
Many open-source test tools have been developed to support this. for e.g. xUnit
All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.
Iterative Test-Driven Development
Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops.It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Now lets look at Acceptance Testing
User stories (same purpose as that of use cases but are not the same) are short descriptions of features that need to be coded. One or more automated acceptance tests must be created to verify the user story has been correctly implemented. Acceptance tests verify the completion of user stories. Ideally they are written before coding.
Should users go along with this?
Some say that XP is an invitation to poor quality and an excuse for hacking. I think that XP is exciting and will improve the practice of testing in the industry.
Even better if we can have an independent Agile Testing process (that is 'independently agile') irrespective of the underlying Development Methodology... please watch this space for more on this.