What came first, Context or Testability?
I’ve often viewed Testability as a mechanism for helping me understand the context of a project. Not really distinguishing between the two, or at least not explicitly. I formulate questions based on a model of Testability and seek answers to them.
E.g. Are there any APIs I can test against?
This is actually a comprehensive question. First we need to find out if there are any API’s. Then we need to determine if we can test against them. Who owns them? Us? 3rd Party? What are they written in? Do I understand that framework/language? Do I have access to them? I could go on.
By trying to answer testability questions like this one, I’m forced to also understand the context. Which means I learn something about the context, and then apply my testability assessment lenses to determine what that information means for my approach to testing. I’ve been doing all this in one motion, which I’ve learnt to do, but today I’ve been trying to break this down in order to teach it to others, and I’ve realised I could probably make life easier for my self.
The first part of this question is related to the context. Are there any APIs? Knowing this is enough to help me better understand the context. The answer to this question is concrete, yes or no. It’s fixed. It’s factual. It’s not an assessment.
Can I test against these APIs? This is a testability questions, an assessment. I’m forced to learn more about these APIs now, their context, and then I’m going to make judgements based on what I learn.
Let’s say these APIs were built, maintained and owned by a 3rd party development company. That could pose some challenges. I could then assess whether I have time for such challenges, or conclude that I’m going to forget about them for now.
But in trying to answer that question I learnt more about the overall context. My model of the context is now deeper than it was before asking that question. But I need to know enough in the first place, the fact that there are some APIs, to even be able to pose my testability question. Or pose it knowing it may be fruitful. If we just asked all the testability questions that come to mind, we’d be there for a very long time. We need some initial framing, a box, to help generate targeted testability questions, that are going to help us progress rapidly.
So I feel like I’ve concluded that, I’ve probably made my life harder by jumping straight to Testability and should split the two up. Do some initial recon about the context, then use that as the basis for digging into Testability, and expect and appreciate that by doing so, I’m going to learn a lot more about the context. Then rinse and repeat and maintain to models.
The context model is based on facts and observations.
The testability model based on assessments of those facts and observations.
Then obviously the two are in a constant state of flux.
As I’ve written this, I’ve been a in constant battle with myself, going duh! Obvious Richard. But I’ve pushed through this battle, because first thing this morning, I don’t think it was so obvious to me.
How do you view testability and context?