I may be the last person to learn about context-driven testing, but since I have recently, I felt compelled to share a few thoughts.
The concept of context-driven testing is described thoroughly by its creators, but at least part of it could be summed up quickly as “use the right tool for the job at hand.”
For many, CDT may be one of those frustratingly obvious learnings that’s been sitting in front of you all along, hidden behind tradition and “best practices”. We write test plans using the same template we’ve always used, hold the same meetings we’re used to holding, and assume that all new tests will simply plug into existing harnesses or test case managers. We get so used to “the way things are done around here” that we often forget to step back and just solve the problem at hand.
As I reflect back on the testers I’ve worked with over the years, I realized that while a significant number of them were brilliant when it came to testing software, many had not really tested their own processes. They thrived in the momentum of their environment, but over time as new challenges came up, they had a tough time creating different kinds of momentum that were more applicable to the problem at hand (and I could draw parallels to “kids today”, but I’ll hold off for now).
My call to action for testers today is to pick at least one regular process you follow and seriously think about whether it solves a problem you actually have. If you don’t know what problem it solves, ask a peer or your manager. There’s a good chance that much of what you do is actually necessary – and in those cases you should definitely understand why! But there’s also a good chance that at least some of what you do is just done because that’s the way it was done before you got there. You read a wiki, followed a template, check, check, check, and off you went. Be the person to spot one of these, and for bonus points, come up with a better way to do it – or cut it out altogether!