Here’s an idea that I think can be interesting in terms of how you view testing (as an activity) and tests (as an artifact).
A lot of people writing about testing draw the correlation between testing and experimenting. You’ll often hear something like “testing is evaluation through experimentation.” But, as advice to testers, this falls far short of helpful if the notion of what being a good experimenter entails is not covered. So let’s talk about that.
In his book The Black Swan, Nassim Taleb talks about “Platonicity,” which is defined as the desire to cut reality into crisp shapes. This is a form of dividing up a large domain into a smaller domain. This, by definition, means establishing certain boundaries. This is a key part of how people experiment and thus of how they model … and thus of how they ultimately explain things. So let’s talk about what this has to do with testing.
In my post on porting development lessons to testing I mentioned getting into the ideas of what makes the testing role something uniquely distinct from that of the development role. So let’s talk about this.
There’s often talk about how developers should think more like testers. But there’s often not as much discussion about the corollary: testers learning to think more like developers. So let’s talk about this.
I’ve talked about the notion of test description languages quite a bit. A lot of these discussions get into debates about being declarative versus imperative, or focusing on intent rather than implementation. All good things to consider. But such “versus” terminology tends to suggest there is a “right” and a “wrong” when often what you have is “What makes sense in your context.” And you may have to flexibly shift between different description levels. Let’s talk about this.
Recently I engaged in a fun exercise with a test team wherein each of us had to answer the following question: How do I describe my role? It’s always interesting to me to see how people answer this, particularly in the fields of testing and quality assurance. So here I’ll provide the answer I gave, along with a bit of context for it.
In this post I want to follow on a bit from the interactive exploration idea developed up to this point but also focus on the distinction of checking and testing that often gets debated. I also want to use this post to reinforce a few things I talked about last year.
This post follows on immediately from the last one, so let’s get started with the exploration!
Let’s continue our interactive exploration example. Here I’m going to provide a bit more of a complex scenario for you to consider. My hope is that you will take the time to engage with this idea, exploring the ideas around the central idea, and figure out how you would ultimately craft tests.