Behind the hyperbole of repeatedly saying that we don't know what we're doing in my talk at CEWT #7 a couple of weeks ago, my core message was that, for me:
In order to be a great tester you have to embrace that not knowing. You have to be able to work within uncertainty, without being confident that anything will stand still, taking into account that your lack of knowledge of something might be the key issue.The project without uncertainty never existed and will never exist.
You won't be sure you ran the experiment you thought you did, or generated the data you were hoping to, or analysed the results without imposing your own biases.
Stakeholders often won't know what they really want, developers often won't be sure they understood what the stakeholders said they wanted, you often won't be sure that the developer implemented the thing they intended to.
The company might appear confident that the bets it is laying this quarter will pay off, but they're probably based on numbers somebody plucked out of a hat and then didn't look at. In any case, half of the teams are still working to finish their work from the last quarter and won't even start building new stuff until it's too late to do anything other than destabilise.
So far, so standard, right?
Then I realised that I've written a lot over the years about adding to that uncertainty by finding ways to generate more ideas. More ideas means more better ideas (and needs a filtering strategy and a time box). But more ideas means more alternatives to manage in the already deep and wide pool of uncertainty. Boom!
A perspective I hadn't had before? Certainly! (And I love that feeling.)
Would I trade less uncertainty for fewer ideas? Certainly not! (At least, I think I wouldn't except in some circumstances perhaps ...)
Image: https://flic.kr/p/8ctRb
Comments
Post a Comment