Friday, October 15, 2021

But It Does Depend

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester, which aims to provide responses to common questions and statements about testing from a context-driven perspective.

It's being edited by Lee Hawkins who is posing questions on TwitterLinkedInSlack, and the AST mailing list and then collating the replies, focusing on practice over theory.

I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be.

Perhaps you'd like to join me?


“Stop saying 'it depends' when I ask you a question”

I'm sorry about that, I understand that it can be frustrating to not get a direct answer to what you perceive is a direct question.

My motivation is to give you a sense of the variables that can influence my response, not to avoid answering, or to piss you off. (Well, not very often.)

For example, when you ask about project end date I could reply with one of

  • two weeks
  • it depends on Team X delivering their piece. I asked but they won't say when it'll be ready. Given past history, I'd guess between one and three weeks.

At some granularity they are both two weeks. Which would you find most helpful?

Did you say ... it depends?


But you're right. Both are good answers in different circumstances, with different needs, of different audiences.

When I compose an answer to your question I am using experience and context to decide which variables matter to you at this time. I am making assumptions about how much time you have, how deep you want to go, how much you care, and what you will do with the data. I am likely biased towards the data I have and not the lack of data I don't, and maybe even which data I think will make me look good, or bad.

This reasoning is necessarily imprecise because I don't know what your need is, or what you plan to do with the answer. Sometimes I'll ask, but you have been impatient with clarifying questions in the past and I have learned to be sparing with them.

Often my compromise across all of these variables is to give you an answer at a depth I guess will be acceptable and explain something about how I arrived at it, and what the risks around it are.  You then get the choice to dig or not.

You could help me reduce the risk of an answer you'd consider unhelpful by filling in the context when you ask. For example:

  • I have to do another stupid management Powerpoint no-one will read. What's your best guess for expected delivery time, no error bars allowed?
  • I have to prepare a detailed roadmap. What dependencies are there on your delivery, and what do they do to the end date?

One last thing: my intention is to help you and so I do my best not to answer with just "it depends." If I do that — outside of us joking around — please call me out on it.

No comments:

Post a Comment