The definition of agile testing can be described as follows: "Testing practice for projects using agile technologies, treating development as the customer of testing and emphasizing a test-first design philosophy. In agile development, testing is integrated throughout the lifecycle, testing the software throughout its development."
Agile is a methodology that is seeing increasingly widespread adoption and it is easy to understand why—especially if you consider the developer and user point of view.
Users: Don't want to spend ages being quizzed in detail about the exact requirements and processes for the whole system, and then have to review a large specification, which they know could come back to haunt them.
Developers: Don't want to have to follow a tight specification, without any expression of their own imagination and creative talents, especially if they can see a better way.
Yet for the QA professional an Agile approach can cause discomfort–In the ideal world they would have a 'finished' product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counter intuitive. It means that the use of technology and automation are much more difficult, and it requires a new approach to testing, in the same way that it does for the users and the developers.
All the agile approaches have (at least) one characteristic in common in that they impact the role of the QA professional. This in itself is not a bad thing when the outcome is a step change for the better. However, when decisions are made on the basis of an invalid paradigm, change is not always analogous with progress. When a new paradigm is proposed for software development, by software developers, it is not a surprise that it is developer-centric. Abraham Maslow said that " He that is good with a hammer tends to think everything is a nail ." The responsibility of the QA profession is not to bury its head and pretend that agile development will go away, it is our responsibility to engage in discussion to ensure that someone with a hammer is not pounding on a screw!
With the emergence of Test Driven Development** some suggest the role of QA is now questionable citing Test Driven Development (TDD) as the key to testing. But, what is most important is that QA is directly involved in the agile scrums all the way through, to be an integral part of the team designing the tests, at the same time as the requirements and solutions evolve.
QA teams need to know the real impact of an Agile methodology, there are boundless myths circulating the industry. Here is our reply to ten of our favorite myths:
Ten QA Myths Regarding Agile Testing.
There are a number of comments and statements regarding TDD and the QA function beginning to appear in articles on the internet by so-called specialists, that are, at best, misguided. This article responds to some of these myths and highlights challenges that QA teams will need to face up to and address in order to be successful in an increasingly agile world.
Myth One: "You only need to unit test–TDD testing is sufficient"
For the vast majority of commercial developments this simply isn‘t true. Even strong proponents of agile development recognize the need for their armory to include a range of testing techniques. For example, Scott W. Ambler has a list of 21 different testing techniques as part of his FLOOT (Full Life Cycle Object-Oriented Testing) methodology, including white box, black box, regression testing, stress testing and UAT. ( http://www.ambysoft.com/essays/floot.html)
TDD programmers rely on these tests to verify their code is correct. If the requirements (test cases) are specified incorrectly, then you'll build robust code that fails to meet the objective.
Therefore, most agile projects include investigative testing efforts (black-box) which support rather than compete with white-box testing. Good investigative