Test management is a residue of the industrial complex.
I grew up in a small city that had two huge factories producing pulp for the paper industry. The entire economy of my hometown had its base on a century-old industrial complex where trucks transported timber in, and all kinds of paper were shipped out at the harbor.
How many crates of pulp did you process this week? How many could you have squeezed in if you really tried?
I grew up to become a software professional just to face those same questions.
How many test cases did you run this week? How many could you have squeezed in if you really tried? I remember it like it was yesterday — our test manager asking the questions.
Not more than a decade ago I was still involved in software projects that went by the V model. For every result we delivered, there needed to be a corresponding plan and an evidence document as well.
We had solved a part of the dilemma by deploying the HP Test Director in our project, and we had a total of 2500 test cases and counting. A typical day of a tester consisted of running 78 test cases on average. And the standard day of our manager consisted of building reports about progress and figuring out how to improve the throughput of our team.
The career path of testers was simple. Run your cases with efficiency and someday you might get a chance to become the test architect. Our architects were the ones who designed those test cases to run. What intrigued me the most in the setting was that our architects found most bugs. It seemed so from both ends of the organization chart. So these exceptional individuals must have been promoted as architects for a reason. They were good at hunting bugs I concluded. But it later turned out I was wrong.
The career path had its peak as well. A fraction of test architects in our business unit got promoted as test managers who planned out and shared the tasks to the team, monitored the progress and combined the reports up the ladders of the organization chart. It was a tall pyramid where key performance indicators stood at the center, and if they didn’t improve, an investigation ensued. Even the annual bonuses of the management depended on the KPIs.
It was inevitable that this kind of organization and process was, above all else, motivated to produce evidence of performance and efficiency first.
Building better software products was a secondary goal for us.
It struck me dumb to witness the same mindset in the world of then-modern software development that I had seen in my home town. The whole testing process seemed like it was an industrial assembly line. The organization chart was almost the same that we had had at the factories back home. And so were the methods of measurement and management. Throughput and efficiency were the numbers where we all focused the most. Hence came the questions.
So how many test cases did you run this week? How many could you have squeezed in, if you really tried?
The test manager once came to a colleague of mine to question why he had only run 20 test cases, and it was already the lunchtime?! Our test management system was excellent for monitoring the performance of individual testers even at the scope of a single morning.
To me, testing was all about finding the bugs that would threaten the success of our product. So I got curious. Why was it that the test architects excelled at this most critical task? Were they so far above the average in their technical skill? Or was there something else at play?
The journey of discovery was long for me. After having had the privilege of working as a test manager for some time, I quit with two of my colleagues. We decided to become entrepreneurs in testing and needed to jumpstart our career paths all over again from scratch.
Since we now were out on our own, we had to reinvent everything we knew. We had to figure out what was the most valuable outcome for the people we wanted to serve and even more we had to figure out how to sell the idea of testing to people who had yet to be awakened.
I would say that one of the biggest epiphanies for me was to realize that testing at its core is not about assuring others of the excellence of our product. It’s not a tool to reproduce evidence of what we already know. And it most certainly is not to serve the industrial complex with its age-old structures. Instead, testing is a tool that sheds light to things that have remained unseen. Testing tells the truth and pulls people out of the matrix.
To me, testing is an expedition, and the goal is to find things that would threaten the value of our products. And finding bugs is a far more important goal than to run more test cases in a day.
Eventually, it all boiled down to a single idea.
Testing is not about managing an industrial process.
Testing is about leading a creative process.
Suddenly the dots got connected, and it all made sense. Designing test cases is a creative process, and that is why our architects were the best bug hunters. Every single test case was a result of an expedition to either our specification or to the product itself. It was a journey of exploration and creation. A continuous creative process of designing and trying. And that is something I’d call a work of an artist.
Now it has become evident that we won’t be working in the industry of testing anymore. We testing professionals must transform into the craftsmen of our art, or we slowly and surely become obsolete parts of an age-old assembly line.
And guess what. Art is something that you don’t manage. Try to manage a factory worker, and he might stay. Try to manage an artist, and he will leave.
Testing is changing, and my proposal still stands. Test management is a residue of our industrial complex.
