In an interview I gave I was confronted with the question “What did you want to become when you were in college and how much of that can be found in your current job?” Suddenly I remembered that I wrote a column about precisely this topic. Although it is a view years old, I like to share it with you as my weekend post I think it is a nice read that explains how testing adds value and what motivates me as a Tester.
Do you ever go back to the reasons why you have ever started in the field where you are working in now? Why are you an IT-professional, Tester, Business Analist, Project manager, or why did you become a programmer? A colleague asked me why I seem so fond of my profession. “You are always so excited when you talk about testing”, he said, “what makes it so special for you?” Suddenly an image came back to me. It was the future job that I envisioned at the time I was still a physics student and my world consisted out of tangible research equipment, material samples, helium columns. At that time, I had little affinity with IT. I’ll love to share that image with you:
It’s a Monday morning; the R&D team meets for their progress meeting. The low winter sun shines softly through the slats and puts the meeting room in a diffuse light. Some team members are already present. They exchange their weekend experiences while enjoying their first cup of coffee. The Industrial designer walks in, together with the project manager, who makes an inventory of the people present. He indicates that he wants to start. “Two weeks ago we discussed our new project,” he opens, and continues by once more summarizing the mission statement. “The sale of our current vacuum cleaner, the SZ10, is declining rapidly. Product Management has given us the task to develop a successor. This model should cost no more than $ 100 and has to be consistent with the latest trends. Last week I asked you for your expertise and to think about possible solutions. Today I am anxious to hear what you came up with.” At precisely that moment Henk enters the room. Under his arm he carries a heavy box, which he puts on the table while glancing round the room. He does it with a mysterious smile. “Don’t let me interrupt you all, please do go on”. Yasmin, the industrial designer takes the word. On the basis of an impressive trend analysis, she explains what the designer team thinks the SZ11 should look like. Applause, grandiose! All participants feel that this will set the standard for all vacuum cleaners, yet to come. Next Henk stands up from his chair, again that smile. He draws the box towards him and says with a hint of importance in his voice: “Last month the technical department had a major technical breakthrough. We can now make engines that are more quiet, use less power and have a significantly increased suction power.” He lifts a large metal object from the box. It is all wrapped with copper wires: “Meet the engine that will make the SZ11 a resounding success. Oehs and ahhs from the team. Wow! Then everyone notices the troubled face that Bernadette has. ” But”, she stammers, “That engine will never fit into the design of Yasmin.”
This is the ideal situation in which I saw myself working at that time. Being a part of a multidisciplinary team that has a clear purpose. Working in situations where the individual components seem fantastic, but combining them is a challenge. Together searching for the best solution, it seemed like a terrific job. I did not envision IT as domain, since I was used to a more physical environment. But during my very first job, I found myself in exactly this situation. We did not make vacuum cleaners but software, but the problems were the same. So was the goal: to achieve a solution. I was the software tester, and in this role I was critical to the customer requirements, technical documentation and communicated with all other disciplines. Like Bernadette, it was my job to look for potential problems. For example, inconsistencies in the design, errors in the interfaces, omissions in the state model or database validations. OK, these problems were not as tangible as vacuum cleaner motors, but not essentially different.
For me the specified memory holds an important lesson. At times there is a lot of debate about the purpose of testing. Do we test to find errors, to improve quality, to reduce the time-to-market or maybe to provide comfort to stakeholders? I think all the above are true. But thinking back to the vacuum cleaner project, it becomes clear to me what my primary driver is: “Working together towards a working product. A solution that excites us a team and that we believe in. And, of course, a solution that benefits the business.”
That was true for me in 2013 when I wrote this column, and still is today.
Derk-Jan de Grood 