Eric Pugh
Category: Conference
You know Agile is becoming prevalent when the keynote of a conference about testing in the more traditional sense of testing major applications used by airlines, banks, and other financial institutions.
Fran OHara from Insight Test Services is speaking about Agile Test Strategies and Experiences. He asked at the beginning of his presentation how many companies have embraced Agile, about a quarter of the ~250 people at the conference raised their hands (including me!). He asked how many are evaluating/thinking about it, and about 50% of the folks raised their hands. And then how many are not looking at Agile, and an oustounding 25% raised their hands! Id have thought that Agile had been the “next new thing” for long enough that everybody would have at least looked at it, and either decided to adopt it, or discard it as not strict enough.
He highlighted some of the types of tests that dont really fall into the purview of normal unit or iteration testing including:
- Performance testing
- Combination/feature interaction testing
- Business cycle testing such as End of Month processing
Weve seen these types of tests not be written while heavy development of the system is happening. Developers and testers are all focused on just churning out the next feature/solving the requirements and verifying they work properly. However, once youve had a couple of interations under your belt, then you start thinking more about those complex scenarios. We worked with a client that had a device that processed large amounts of data. The first 5 or 6 iterations were all focused on making the device work. But iterations 7 through 11 were all about writing analyses tools and complex tests that exercised the device and flushed out issues in the algorithems or verified complex interactions worked as expected. In these later sprints the developers and testers worked hand in hand to understand where the problems are and what the expected behavior should be. Writing those tests earlier would have been very difficult if not impossible, because often what the expected behavior should be cant be defined until the device was up and working!
Fran emphaized that by having the testers integrated directly into an Agile development team they can have a lot more input into the project. They can ensure that the customers needs are met, not just that the software is technically correct. And when you have a sepearate QA team, then that imples that Quality isnt something the developers need to be concerned with. Which is a recipe for disaster. By pushing the need for Quality down to every level, you end up with a better system. Think Honda and Toyota versus General Motors.
He also pointed out that one of the key reasons to have Testers invovled directly is becasue often Agile is introduced by the developers, which can lead to making mistakes such as using unit tests for accepetance tests. Or thinking that automated tests are sufficient!