Agile Testing Vs Traditional QA
Exploratory testing : Business requirements on an agile project may not be as concrete as requirements on a traditional project; agile methods accept that change is a healthy and real part of software development. This means that test case generation may not be as cut-and-dried as it was in the past. Exploratory testing is an essential skill to uncover additional considerations for the product owner to evaluate.
Agile emphasizes automating as much as possible, but many teams struggle with when, how much and what tools to use. While continuous integration (CI) is an accepted developer practice, agile testing takes the lead on incorporating automated acceptance tests and creating regression test plans as part of CI.
Traditional QA engineers tend to rely on documents. Agile testing QA engineers don’t get a big requirements document as a basis for test cases and don’t get three months to write test cases before they see a working piece of code. They jump into the communication stream, which may be verbal, written or virtual, and assimilate the information they need.
Challenges with Traditional QA:
· Significant delays between when software is written and development receives feedback
· Defects found late in the process can have major implications when changed
· Changing business requirements affect test cases that have already been developed
· Siloed communications create risk that different groups may have different expectations of the final product
· Quality suffers and many QA activities get left out when testing is the last activity before a fixed release date
Benefits of Agile Testing:
· On-going feedback to developers allows testers to ask the right questions at the right time.
· Early identification of dependencies, technical or testing challenges and roadblocks.
· Embraces change as a healthy and real part of software development.
· Team collaboration helps everyone work together toward a common goal.
· Quality comes first because final acceptance criteria are established prior to the work beginning.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)