Getting Real about Agile Testing

 

Chuck Blog Post Photo

Reality

I have suspected for some time that Agile Development is bragged about but rarely achieved. I confirmed this at StarEast when I spoke to over 200 testing professionals. Almost without exception, I was told that testing in Agile was being executed two ways:

  • At the end of The Sprint or in reality Mini Waterfall
  • In The Following Sprint or guaranteed production error mode

While this is not surprising, it is cause for alarm. Testing at the end of The Sprint carries all of the coverage issues and time constraints associated with The Waterfall SDLC and adds the compounding negative effects of biweekly or weekly iterative test crunches. The result is poor coverage and QA burnout. As a consequence, applications will suffer quality issues and delays. I can safely say that the QA professionals living under this regimen are miserable. Worse still, application quality is being assured by the developers’ unit testing instead of QA. Let's just give The Fox the Hen House.

Delaying testing until The Following Sprint is a recipe for disaster. In a small shop it guarantees production errors and rework. In Scaled Agile it's much worse. Not only are post release issues guaranteed but also one error can halt the work of multiple teams with shared dependencies. In a large organization with upwards of 50 teams the impact is devastating both in time and cost. In many cases errors are swept under the rug and dumped into production or passed on to The Next Sprint. The result is technical debt and spotty quality at best. This is clearly unsustainable.

Mini Waterfall and Post Sprint Testing are symptoms of relying on antiquated tools. Most of the tools on the market rely on API calls to existing code. This requires QA teams to wait for the code to exist before creating test cases. Theoretically, a test automation scripter could write test cases every time code is checked in but, as we all know, this is rare. Simply put, QA can't afford to wait for the code to be written. With API and DLL dependent tools QA is destined to fail.

Solution

At ZAPTEST our customers have been liberated from API based testing and have achieved Continuous Agile Testing. This is accomplished by scanning functional documents, mock ups or even hand drawn whiteboards to create test cases before code is written. We call this Mock Up Based Testing. In our model, Devs and QAs are given mock ups at the same time. The QA creates test cases before the code is written. When code is checked into the CI Hub (Jenkins, etc), test cases are executed automatically, checking quality immediately. Errors are caught Mid-Sprint and we shift from Quality Assurance to Quality Engineering. The nightmare of Mini Waterfall and the cascading disaster of Post Sprint Testing are eliminated by Mock Up Based Testing

With our approach QA is now an integral function of the Agile Process providing immediate value to both the application owners and the Agile Team. More importantly, QA is involved in every step of The Sprint as an independent verifier working for The Business. Eliminating the inherent conflict of interest of Devs checking their own work.

Conclusion

In summary, Agile Development is suffering from two major faults in QA- Mini Waterfall SDLC and Post Sprint Testing. Both activities result in poor application quality and wasted time. ZAPTEST eradicates these inefficient practices by Empowering QAs to work through 100% of The Sprint, as they create test cases in lockstep with Devs. Thus, uniquely achieving Continuous Agile Testing and Development with truly independent Quality Engineering.

Ask

Thank you for your time reading this article! Please download ZAPTEST and get started today!

Created by:  Chuck Moeller [ZAP]

Chuck Headshot 80x80

Contact Us

Tower Place 100

3340 Peachtree Rd NE #1800 

Atlanta, GA 30326 USA

(404) 814-5227