The Dev manager scooted his chair over to my desk yesterday with that particular smile on his face that means he knows something I don’t know.
Dev: Got a question for you. [Grin]
QA: One of those questions with implications? [Grimace]
Dev: Hidden implications. [Toothpaste advert]
QA: Lots of hidden implications? [Frown]
Dev: I’m sitting on the tip of an iceberg of implications. [Cheshire cat]
Dev: We need to audit these components against specific criteria for a stakeholder. They’re used everywhere in the product. [Richard Branson]
Hmm. I can see what’s above the water for free; I can get an idea of what’s just below well enough; I could dive deep down but I have to get my gear ready and the currents and the winds and new snowfall will have shifted things by the time I resurface.
Dev: Now. [Rictus]
When I can’t see the scale of the berg yet and I don’t have time I’ll look for a cheap way to model or approximate it instead, then give a qualified answer. The kinds of things I might consider include
- a previous testing task in the same area
- an existing product with the same functionality
- gut feeling estimates from several people
- asking colleagues who’ve worked on similar things elsewhere
- web search for known solutions in the area
- estimated amount of code change compared to earlier projects with similar amounts
- the complexity of the spec against other features
- any existing estimate for this project and their accuracy to date
- some notional per-day figure for e.g. proof reading or code review vs number of pages to be read
- stability and code health of the product components being affected
- the experience of the developer and tester in this area of the product, this toolkit, this domain etc
We kick it around for a few minutes and decide to base our response on the documented behaviour of the platform we’re using for those components, with caveats according to the differences we can easily identify. We’ll postpone the need for more investigation until later, or not at all.