If you want to have a career in technology—and maybe even get beyond the day-to-day at the individual level, and improve the team or division—all you need to do is things no one else can.
I know that sounds difficult, but all I mean is learning to do things no one else has bothered to do before. I’d like to talk about what that looks like.
Parlor Tricks
Find me at a bar, put a beverage or two in me, and I’m likely to offer to empty a beer glass without touching it, make a playing card disappear, tell a joke, or some other “parlor trick.” These are easy to dismiss or laugh at, but they entertain. They are a performance, they need to be collected, and they need to be practiced.
In testing land, the parlor tricks might be configuration flags, the low-tech testing dashboard, exercises like ParkCalc, the palindrome problem, or the Abelian sandpile game.
Recently, I’ve helped teams move from a long text document that contained test cases to a mind map that contained pointers and links. When it’s time to run regression testing, the team can make a copy of the document, then mark coverage up on the mind map with color (red, green, and blue) and coverage (percentage of complete markers). The links provide detail on how to test or use a particular feature, ideally to a wiki, so anyone can edit the details on any node at any time.
These things are all pretty easy to dismiss. Two days after you taught the team to do the method, it looks trivial and easy to them. (That’s if you’re lucky. If you’re not lucky, you’ll get feedback like there is “nothing new here” or “a few tricks, mostly obvious.”)
Bear in mind that test automation is its own kind of parlor trick. Companies that don’t know how to do it generally have something in mind, spend a great deal of time and effort to hire one of the few people claiming to have done that style of work … then assume it’s easy and tell that person exactly how to do it. In the rare cases where that person is successful long-term, the knowledge of how to create tests is passed on to the team. Team members now think that test tooling is simple, obvious, and no big deal.
Remaining Relevant
The first and most serious way to remain relevant is to find something in testing that is more like a complex magic trick—something that will require skill, practice, and equipment. These things can’t be easily replicated, but instead take skill development. And skill development takes time.
So, for example, don’t just explain the technique. Instead, give the problem to the team or class, and let them flounder. Let them struggle. Let the audience fail to find important bugs. Then introduce your solution to the problem, and run them through the exercise again. Then again.
The important thing is to do a similar exercise, then another, and have some objective measure so you can watch scores improve over time. By actually doing better—perhaps finding more bugs, or in less time—it will be much harder for the audience to claim your solution is “obvious” or that “there is nothing new here.” When I started to do that in my training and consulting, those objections disappeared.
People don’t realize that, unlike a parlor trick, a testing technique has to solve a particular problem. In order to be effective, you’ll want to have a wide and deep set of options. The test coverage map, for example, works for teams that have a relatively small application domain where the user interface is changing rapidly. If there is no user interface, like if the application is entirely data transformation, then I might run the old version off the application and the new version side by side with the same source data, then do some sort of comparison of the differences.
No Rest for the Weary
Doing what no one else can, just like pulling the rabbit out of the hat, looks like a trick. It looks easy. Yet in order to do it, you need to genuinely understand the problem the organization is dealing with, have a dozen (or a hundred) possible solutions, select the best one, demonstrate it, overcome resistance, and encourage it for widespread adoption.
There are more hidden skills in there, including grabbing attention, teaching, understanding each person’s unique motivation, explaining a change without creating a threat, entertaining, and scoping the work so that it is challenging enough yet stays within the attention span.
If you want to have a long career in testing and not be an anonymous cog, then one option is to do what no one else can. That means staying ahead as the industry moves on, which takes an intense and continuous investment in learning and practicing new things.
Or you might count the cost and not want to do that. There are other ways.
What are some of yours?
