“From day one, they were testing.” —Keith Klain, on the Per Scholas software testing training program.
Software testing is still an emerging profession. Where software development has been around long enough to have a clear career track—complete with college degrees and entry-level paychecks most anyone would pine after—the blueprint or DNA for software testing is still being determined. But like any new species, testers and their profession aren’t starting from scratch. Older models of production built its foundation and shaped its earliest form. The manufacturing model in particular has influenced the way we test software today—a business strategy as old as the industrial revolution.
I’ve written before about why the manufacturing model for software testing is no longer a viable solution for today’s complex performance quality needs. Especially given our growing dependency on software—from health care and security to the most practical and personal aspects of our day-to-day lives—we really need it to function as it was meant to.
So what would a new, more reliable software testing model look like? Well, I don’t really know what this new model is per se, but I have a strong hunch about where it is being formed, by whom, and some of the elements that herald it as a breakthrough in the way software testing is perceived and practiced.
Not surprisingly, it’s in the work of inspired teachers where the course of software testing’s future is being charted. But, because there isn’t a typical college degree route for software testing, those classrooms and those teachers aren’t typical either. They are scattered about in weekend seminars, mentor relationships, training programs, online tutorials and conferences. They are disguised as QA managers, consultants, keynote speakers and software evangelists. Still, many of them have come to similar conclusions about the path software testing education needs to take…and it starts with honoring two things: human intelligence and the ecosystem that intelligence must be applied within.
A Seemingly Random Metaphor….
For about 7 years during and after college, I was as a river guide and white water kayak instructor. It was an amazingly fun and endlessly inspiring vocation, filled with daily challenges that kept me on my toes. Not unlike working for SmartBear actually… But back to the white water metaphor, which I promise has a point related to teaching software testing.
When I first heard Keith Klain utter the words at the beginning of this blog during an interview with him a few weeks ago, it immediately reminded me of something I learned while teaching people to white water kayak. Like software testing, there are two schools of thought in kayaking—one old and unquestioned, and one that came out of the experience and innovation of instructors who were unusually observant, overly enthusiastic about river running, and really wanted as many people as possible to learn to kayak. Why? Because they loved the sport, the rivers, and the ecosystems that created them. And they saw meaning in teaching other people to love them as well.
The old way of teaching kayaking was all about developing skills by learning them on flat water, usually a lake or pool, with lots of repetition, flipping upside down on purpose and trying to roll back up, and some kind of skill test at the end of the course. These beginning students might see a river towards the end of the course, but only a very slow moving one, and they would usually be so intimidated by the idea of flipping upside down again that they often would stiffen up and loose any sense of intelligent, spontaneous response. For years, I thought that was the only way to teach. Learn the paddle moves, practice building stability and strength on the flat water, learn to role, then off to the slow moving beginner stuff.
Then I went to Nepal and met an English instructor who was doing something radical. He was taking people who had never been in a kayak before down class II/III white water on their first day out. Given, that kind of river isn’t something you would drown in if you flipped over and lost your boat. And, if you like to swim, it’s even the kind of thing you would enjoy on a beautiful sunny day floating down a crystal stream at the foot of the Himalayas. But, people thought you couldn’t possibly learn those beginner skills if you were actually on the river. Turns out they (we) were not only wrong, we were teaching people to both be afraid of the “real thing” and to mechanically approach it when they did finally hit some waves.
Before that first day in Nepal, I always thought it took years to develop the kind of natural physical response to the instability caused by currents and eddies and waves you see in elite kayakers. Experienced boaters allow the turbulence of the river to move through them without fighting it. Instead, they constantly work with the current, and use it to perfect their art and sport. Unlike most beginners I’d seen—with a fear and stiffness that stifles that kind of comfort—the newbies on that Nepalese river had none of that. Instead, with lessons taught while having to immediately deal with all a river may offer, they were actively developing the most vital skill of all—the capacity to respond intelligently to what was actually happening.
Intelligent Response is the Greatest Skill
That experience left me with a huge revelation about human psychology, skill development, and river running. And it’s the same issue for software testing. Most software testing programs are based on skill development outside of the actual testing environment. You learn about various ways of testing, what they measure and what they mean. Then you take a test on that knowledge, and are released into the wild of software production—often before ever actually testing any software. Like the white water kayak class taught on a lake, this old way separates the skills needed to do the job from the environment in which the skills will be performed, causing the most vital skill needed to master the art—intelligent response—to be completely left out.
It’s this kind of intelligence that’s prioritized in programs like Per Scholas. A phenomenal program for which Keith Klain teaches, and for which SmartBear provides free TestComplete licenses. The materials and approach for the immersion program at Per Scholas, called STEP, are based on the Rapid Software Testing course designed by James Bach and Michael Bolton and is aligned with the Context-Driven School of software testing. The students still learn all the needed facts and skills any tester should know, but they do it in a way that never separates those skills from the reality of an unpredictable, dynamic system. But the real proof is in the students who are becoming infected with a love of software testing. A few weeks ago, I got a new Twitter follower and found this great Tweet she’d recently sent out– not surprisingly, she turned out to be a Per Scholas student.
Testing involves not just the software, but assumptions about users you never even thought of. Open your mind to everything & push forward.
— Maria Cohen (@mariaicohen) September 9, 2013
Perhaps software used be much more straightforward, flat like a lake or a large, slow moving river. Not anymore. Today’s software is far more like a steep creek with holes and eddies and dynamic turns you can’t yet see right around the corner. So we’d better train our testers to be masters of their skills… and their environment.
- Don’t Fear The Code: How Learning Basic Coding Can Boost Your Testing Career
- Why Not Train Testers Early with Software Testing Degrees?
- Ingrained Biases in Software Testing That Work Against You