TLDR; I can fool myself into comfortable complacency about code when programming. I can use testing to banish this false glamor.
“Why might we be villainous? First, because we can be… that’s a big deal…”
Thus spoke Jordan Peterson in this Maps of Meaning Lecture:
youtu.be/I8Xc2_FtpHI?t=1h54m16s
One of the reasons for adopting a testing role on a project is to make sure we use this capability in a positive way on Software Development projects.
The act of writing code can fool us into thinking that we have explored the functionality of the system. We spend time with it, we see it runnning, either by debugging or through Unit Tests and we spend so much time with the code that we are familiar with it and we feel comfortable with it, and we might then believe that we have explored the code and its surrounding environment (The System) and its interaction within that system. We view it as an explored territory.
I fooled myself recently when developing an HTTP based REST application. I relied extensively on coding, reviews, Unit Testing and even my Automated Integration execution misled me into an overly comfortable sense of confidence because of assumptions that I had encoded into my test code.
You can see me explain the above in this YouTube video
Very often our exploration has not been detailed enough because we have been busy building it, creating the foundations, clearing the area around it, such that it can be used in The System, but we’ve generally explored it locally and over a short period of time - given the length of time this code will function in The System.
Our familiarity can fool us into believing we have explored it.
This is a risk.
We can mitigate some concerns by conducting the type of exploration that we believe users will use, or that the functionality has been coded to handle. This might well mean following paths that we have already walked i.e. we performed that test during code creation (even if no Unit Test exists to objectively demonstrate that).
Following paths that we’ve walked before can count as exploring territory if we are observing the territory in more depth or traversing it in a different order. It might not offer up as much information as the unexplored territory, but it might still be useful. But that is still a comfortable form of exploration.
This still leave risk.
Risk we might try to mitigate with a dash of malevolence, but it has to be aimed and focused, otherwise people will brush it off or disregard it as unnecessary.
We don’t always need to harness malevolence, sometimes simple exploration will do the job (as my video above demonstrates). But malevolence is an easy way for me to conceptualise pushing the system hard, exploring its edges, observing it in ways that support in depth examination rather than superficial observation.
The more that we learn to aim our malevolence effectively, to create an objective model of explored territory, the better our testing will become.
“We can Aim our Malevolence, and we’re really good at it” Jordan Peterson, at 1:55:40
