In software testing, we use a lot of words – some well known, others less so – to describe our testing activities. For as long as I’ve been in software (which is longer than most of you), we’ve debated and argued which descriptions, and which combinations of words best describe the various activities that fall into the world of testing.
Is that a smoke test, or an integration test? Is it a load test or a stress test? Is it automated testing, tool smithing, or computer-assisted software validation? Is it testing, or checking? Is it manual testing or human testing? I fully understand the debates – words, do indeed have meaning, and words can mean different things to different people. Some (including me) often call most of these debates “semantic bullshit”, but I admit I do see the reason for nuance and discussion. I will even openly admit that I was part of a working group at Microsoft once who tried to develop a taxonomy of testing terms.
My stance has changed.
The more I think about it, the less I care about what people call their testing activities. I’m increasingly becoming a fan of labeling tests “small”, “medium”, and “large” (and when necessary, “enormous”).
“Bu-bu-bu…but we need to know what the test does…!”
No you don’t. But you do need to know why you’re running the test.
In Start With Why, one of my heroes, Simon Sinek talks about how starting with the question, “Why?” (rather than “What?” or “How?”) is a better way for leaders to inspire the right actions from their team. It hit me recently that there’s a strong parallel with his leadership mantra and why I am caring less about the words we use in testing.
We don’t build software to beat our competition, or to satisfy our own intellectual curiosity. We create software to help our customers solve problems (customers don’t want software – they want their problems solved).
When testing software we should focus on why we’re testing the software. What are our quality goals and why are they important for the customer? I believe that if the software team is aligned on mission and purpose, that the words we use to describe activities toward those goals have far less meaning than if we focus on describing what we’re doing.
As I type the sentence in bold above, I realize that I feel even more strongly about that phrase. Yes, words have meaning, but mission and purpose carry far more weight in the journey towards software quality.
I also have tried to write a generic software testing taxonomy, and gave up. Now I only try to make sure that I understand what the words mean in the context of each conversation I’m in, and I’m careful to explain if I use a phrase that doesn’t have broad understanding of its meaning, like “integration test”.
Thanks for the pointer to Start with Why.