Agile Testing Webinar

Questcon Technologies hosted an excellent webinar this morning about how testing in Agile is different than traditional development. Officially titled “Assessing Agile Test Teams: Adoption & Effectiveness, the material was presented by Shaun Bradshaw, Director of Quality Solutions. Shaun is very knowledgeable and has Agile certifications (sorry I didn’t write them down).

My top 10 tidbits from Shaun’s discussion:

1. QA vs. QC: Quality Assurance tries to prevent bugs and gets involved during inception of project; Quality Control only finds bugs and gets involved after coding – too late to be Agile
2. Testers want the requirements to build test plans, but Agile doesn’t start with firm requirements (no spec doc), minimal planning
3. Keep QA as a their own separate group, but view them as suppliers to the Scrum teams.
4. Testers need a higher level of technical skill because they are working so closely with developers and must be comfortable getting their hands dirty in some code (review)
5. Testing comes first, not last – there is no “test phase” of the project
6. Agile has integrated teams where, optimally, the testers are collocated with the developers, analysts, managers, and architects.
7. Bugs don’t go in a bug tracking system, put them on a whiteboard, developers fix them pronto (reduce technical debt)
8. Testers are equal participants with everyone
9. Testing is for the entire team, not just the testers

   And my absolute favorite:

10. Test automation is essential!

Shaun’s reasoning for stating “test automation is indispensable” for Agile Testing is because of the iterative cycles of development. In his experience, it is cost-prohibitive to assign enough team members that it would take to manually test over and over again. It would be illogical to manually execute tests that don’t change throughout the development process.

Shaun also recommended using light-weight automation tools rather than the fully-featured, complex suites provided by the traditional vendors (you know who they are). Shaun called it “little a” automation as compared to “big a” automation.

While I may be relatively new to Agile methodology, my 20 years’ experience in software makes me completely understand the need to be quick, nimble, easy, inexpensive, and flexible. Small iterations of development by an integrated Scrum team of talented people wearing multiple hats makes sense to me. It works. And in that environment, your tools better be lockstep with every aspect of your Agile Testing process. Know of any quick, nimble, easy, inexpensive load testing tools?

Will they work as Agile testing tools?