Why the hell “Guerrilla QA”?
How many times has QA played the medic role at the end of a software release cycle?
Gaining great advantages due to its adaptivity, guerrilla warfare tactics closely resemble many of the same methods used by the QA organizations I’ve been involved with in that:
- We’ve never had all the resources we desperately needed
- We continually dealt with changing environments, requirements, and expectations
- Improvisation, creativity, and heightened sensitivities to change have all been at the core of QA
- QA has always been composed of many small, high-functioning, high-precision sub teams
- QA has always carried a slightly rebellious flag given the nature of their work
This has been my experience thus far on my 19+ year march in QA land. Though I’ve been part of many successful and innovative teams I have much to learn and will enjoy being a student the rest of my life.
Plus, it’s a bonus for me that students tend to get away with being more the rebellious sort, which suits me just fine.
Guerrilla QA seemed to encapsulate my experience very efficiently and conjures a less-than-center attitude.
I believe that every QA team, no matter what discipline or technology, have gone through or are currently going through some level of challenges that force them into guerrilla tactics.
Assume change, value adaptability and precision with the highest regard, reward your teams for self-sufficiency and creativity, and never ever assume you have found all the gotchas.
