Ten challenges QA have to face and solve
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 view-points.
- 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 will later be used as evidence in court.
- 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, but feel they cannot vary from the specification which they know will later be used as evidence in court.
But, for the QA professional an Agile approach causes 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 counterintuitive. 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!
For some, 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.
But this is only a limited view and is one of a number of misunderstandings that QA teams need to take on and address.
Misunderstandings over the respective roles of testing
There are several common misunderstandings regarding TDD and the QA function beginning to appear in articles on the internet by so-called specialists. 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.
1. "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 .
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.
Most agile projects include investigative testing efforts (black-box) which support rather than compete with white-box testing. Good investigative testing will reveal problems that the developer missed before they get too far downstream.
2. "You can reuse unit tests to build a regression test suite"
Some TDD proponents argue that conventional downstream testing is unnecessary because every line of application code has a corresponding test case; they suggest that by reassembling unit tests, everything from User Acceptance Tests to Regression Tests can