Agile Testing - Only for Agile Development methodology?

Before I introduce the new paradigm of the Agile Testing process for ALL development methodologies (including Agile), I am put across my thoughts over the traditional Agile Testing practice which exists in the realm of Agile development.

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)
• Crystal
• Adaptive Software Development (ASD)
• Scrum
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• XBreed
  

Now let us look at the basic role of testing any project irrespective of the underlying development methodology:

• 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
  

To focus on one of these, the common XP Practices are:

• Test-First Programming
• Pair Programming
• Short Iterations & ReleasesRefactoring
• “User Stories" Acceptance Testing
  

In Test-first programming:
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


Pair Programming
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.