I once attended a conference and listened to Michael Bolton (no, not the singer, and definitely not the guy from Office Space) untangle a thought stream on the validity of the QA profession as a whole. He talked about the difference between “Testing” and “Checking”. Consider that for a moment. Checking is the process of following a prescribed checklist and verifying certain data or function points, typically well after something has been delivered, reactively. Testing, by way of exclusion here, is then understanding what you are going to receive and then thoughtfully considering the actions of the client, and working on their behalf, proactively. This is a fundamental change in the mindset of the “traditional” tester.
In the same way, a mindset change is required for Testers to be successful in an Agile Environment. Consider the composition of an agile team- it is referred to as a Delivery Team, or more recently, a Development Team (Scrum Guide update 2011). All members of the team are charged with developing a product increment, as a team. This means that you can toss the traditional titles in the circular buffer- if you have the talent and can step up for the team, come on down! Testers, you are a part of this team! No more silos! Get over your degrees or lack thereof people!
Another agile change that testers should consider is how they can effectively jump in with the rest of the team at the front end of each sprint. This means that you are going to have to engage the team, have a voice, and be the Assurer of Quality, not just the Quality Assurance representative. How is this accomplished? Well, as a Development Team, (now, don’t panic!) your QA folks are going to have to learn to code, and learn to code well. Here comes the bucket of cold water: The days of the traditional, manual only tester are over. Take a minute and soak that in. (Consider it- Offshore resources can be hired for 1/3 your rate.) The thing that is going to bring value to your position as an Agile Tester is going to be your ability to communicate technically with the rest of the team, engage and develop solutions, as well as your ability to……Test Early, Test Often. I’m not sure who was credited with saying that first, but Good On You, whoever you are. This phrase has changed the landscape for a subject that wasn’t really broached head on since the signing of the Agile Manifesto- how does QA fit into Agile?
Test Early. This means engaging your developer teammates before and during the coding process, selectively working through the appropriate layers of test, providing direction in terms of Quality for the team, and prioritizing your work to test the increment.
Test Often. This means automating as many of your test scenarios as possible, engaging your developer teammates as co-developers, and approaching your test automation as a coded product. Make no mistake, the Testing Developer or Developing Tester or whatever you want to call it, just saw their stock go sky high recently, and there‟s no recession in sight.
In conclusion, as testers, to stay effective in this business, we need to work more proactively, get in the game earlier, and sharpen our development axes (and that doesn’t just mean blowing the dust off that VBA book or your “Command line for Dummies” book- C# is hugely valuable, uses modern techniques, and works as the underlying language for many tools [including Selenium, TestComplete, and M$ Coded UI]).
Stay Classy, San Diego.