55 lines
5.9 KiB
Markdown
55 lines
5.9 KiB
Markdown
In last week's post, I covered the core thesis of Chapter 2, in *Lessons Learned In Software Testing*. But, in spite of how much there was to cover in that post, there was still a great deal more in the chapter that deserved attention. So, here we are.
|
|
|
|
This week, I want to cover lesson 21, in which the authors raised a very interesting point. Having a rational and empirical attitude toward your work is not enough, they say. To be an excellent tester, one must cultivate four different modes of thinking: Technical, Creative, Critical, and Practical.
|
|
|
|
### The Yin-Yang Of Testing
|
|
|
|
The authors did not elaborate much on the forms themselves, but offered enough detail that I believe they can be distilled into two simpler categories: analytic and synthetic (not to be confused with the Analytic-Synthetic Distinction in philosophical argumentation).
|
|
|
|
If we look closely, we can see that the Technical and Critical forms are fundamentally *analytical*. They describe Technical Thinking as:
|
|
|
|
> The ability to model technology, and understand causes and effects... and predict the behavior of systems.
|
|
|
|
...and Critical Thinking as:
|
|
|
|
> The ability to evaluate ideas and make inferences... the ability to detect and eliminate errors from your thinkin.
|
|
|
|
In other words, the ability to purposefully dissassemble something, whether it is an argument, or a watch. To understand it's component parts, how they all function, and how they interact with each other. And to see where the problems and flaws are.
|
|
|
|
This sort of skill is the bread and butter of the mechanic, the engineer, the philosopher, and the scientist. It is the fuel that powers the engine of curiosity and the acid that burns away the fog of ignorance. This form of thought is both destructive, and reparative. You have to kill the frog, to dissect it. But once you do, you know how every other frog works.
|
|
|
|
This is the kind of thinking that compels a tester to become a hacker. As we saw in my previous post, it is analytical thinking that challenges the tester to ask his team "what if we're wrong"? It is analytical thinking that gives him the tools to answer that question.
|
|
|
|
Similarly, the Creative and Practical forms of thinking are clearly *synthetic* forms, at their core. They offer this description of Creative Thinking:
|
|
|
|
> The ability to generate ideas, and see possibilities.
|
|
|
|
...and Practical Thinking is described as:
|
|
|
|
> The ability to put ideas into practice.
|
|
|
|
These descriptions are short, but packed with meaning. The kind of thinker they are describing here, is the *inventor*, the *architect*, the *artist*. The kind of thinker who is capable of taking the constraints of time, or physics, or budgets, or resources, and repurposing them into a sculptors chisel.
|
|
|
|
### Becoming A Better Artist
|
|
|
|
As a life-long lover of science and reason, and having made my career primarily in production operations, the analytical mindest is second-nature to me now. I suspect this is true for many in technical roles.
|
|
|
|
But over the years, I have also discovered that the analytical mindset is like myself as a small boy with a transistor radio and a screwdriver: After two hours of tinkering, my bedspread is covered in small parts, I can tell you where I got each part, how I found it, and with a reference book, I might even be able to describe its function for you. But if you gave me all the parts already disassembled, didn't tell me what it was, but gave me a reference book describing each part's function, I would be hard pressed to reassemble it, or even to give you a reason why you'd want to.
|
|
|
|
This is because (for reasons not relevant here) I lacked any practice at *synthesis*. And this is why I consider lesson 21 to be so important. Because it points out that, in order to be successful, testers must be capable of what the coder does, when he writes code. Namely, giving form to the nearly formless expression of a problem, by outlining it with a solution. The tester must be as capable of building things as he is of breaking them.
|
|
|
|
In a nutshell, synthetic thinkers are problem solvers. And I find several activities helpful at giving me good opportunities for building up my own synthesis muscles: building tools like automation frameworks, or writing utilities for use with testing activities, or pair programming when an opportunity arises. And, there is one other activity that is refreshingly eye-opening, albeit a little contraversial. If you have the stomach for it, a **coding challenge** of the variety you get in some job interviews, is a perfect tool for telling you how much you don't yet know, and for testing your synthetic mind (I'll discuss this more in a different post unrelated to this review).
|
|
|
|
### Outside The Box
|
|
|
|
But to really maximize our creative and practical modes of thinking, I think we need to challenge ourselves outside of the context of software. As the authors point out:
|
|
|
|
> ...when the test process fails in the most damaging ways, the root cause is most likely tunnel vision. In other words, its not that we ran 10,000 tests and should have run 10,001. It's that we failed to imagine an entire category of test; testing we wouldn't have performed even if we had twice the time and resources.
|
|
|
|
I think this tunnel vision is due in part to our over-dependence on analytical thinking in these situations. Employing lateral and creative forms of thinking will make those other "entire categories" accessible again.
|
|
|
|
The best opportunities for exercising these weaker mental muscles, in my view, are in creative hobbies. In addition to avid readers, testers should be inventors, artists, musicians, explorers, writers, and developers in their spare time. They should experience the pain and struggle of creation, the same as the creator experiences it. If for no other reason, then to better understand their own role in the creative process.
|
|
|
|
### Conclusion
|
|
|
|
Next week, I'll be covering some key industry myths about testers that were raised both by implication and explication in chapter two. |