Exactly 10 years ago I started my first job as a software tester.
That doesn’t mean I started testing 10 years ago. Back when I was in high school and at university, I did spend some time doing testing and quality-related stuff for various open source projects - Debian, KDE, Kadu, LibreOffice, Cantata, and some more. I don’t remember any longer which was the first and when exactly that happened. I imagine my first contribution was pretty uneventful - perhaps a message on users forum, a response confirming this is a bug, and an encouragement to report it on bug tracking system or devs mailing list.
Nonetheless, “first job as software tester” is a good place to start counting. First, it’s easy - I have papers to prove the exact date. Second, from that day I have spent about eight hours a day, five days a week, every week, on testing-related things. That adds up to a lot of time, but it’s the consistency that sets it apart from any open source work I have done. Last but not least, the decision to start this specific job set me on a path to treat testing much more seriously, and which eventually led me to where I am today.
I’m not much of a job hopper. In these 10 years, I have only had two employers. But I did change teams and projects quite a lot - I’ve been on 4 projects in first company, and now I’m on my 5th project in second company. The longest time I’ve ever been in a single project is 2 years and 7 months. Details are on LinkedIn.
I came into testing after getting a degree in sociology. In my time at university, I had an opportunity to get my feet wet in empirical social research. I approached testing the same way I approached empirical sociology, even if only because I didn’t really know anything else - I assumed there’s a number of things the team would like to know and my job is to learn about them and report my findings. The hard part is that we don’t have direct access to some of the things we would like to know more about, so we need to depend on a number of proxies of uncertain reliability. X can be caused by Y, and we observed X, but is this because of Y, or some other factor Z? How can we rule out Z? Today, I can confidently say this is not the worst way to approach testing.
When I started my first job, I have been using Linux as my main operating system for about 7 years. During that time I learned how to use shell, I got familiar with the idea that things change and move around, I faced various breakages after updates. Often trying to fix them was frustrating, but I did learn how to search for information, I picked up few tricks and I learned how various components can interact in complex system. That was another major source of experiences that influenced my approach to testing.
I guess I also have certain character traits that helped me to become a decent tester. I tend to be stubborn, I don’t give up easily, I self-identify as perfectionist and I strive to actually understand the thing I am dealing with.
After a year and a half I decided that I want to know more about testing, especially established testing techniques and solutions. My work was praised, but it was all based on intuition and past experiences from other fields. I felt I was missing fundamentals and I feared I might be missing some obvious and elementary testing techniques or skills. I tried to fill these gaps by attending an ISTQB preparation course, but it did not deliver what I was looking for.
My manager knew about my disappointment and at one point presented me with the opportunity to attend a testing conference in another city. One of the talks given there was called “Context-Driven Testing: A New Hope”. This is a funny title, as Context-Driven Testing was already 15 years old at that time and “schools of testing” debate has long left community conciousness. I don’t remember many details of the talk itself, but I did left the conference with a feeling that I should learn more about CDT, as they might have at least some of the answers I was looking for.
I think I started by reading “Lessons Learned in Software Testing”, and what a book it was! It not only revolutionized the way I think about testing to this day, but also gave me much-needed confidence. I found I was already doing some of the things that book recommended, but now I knew why they were worth doing. This is the book that everyone who is serious about testing should read, and probably re-read thorough their career. I think I read it at very good moment, too - I had about three years of experience at the time. I feel I wouldn’t get that much from it if I read it earlier.
Later I have read “Perfect Software” by late Jerry Weinberg. I think this is a great book for people who just start in testing. It surely helped to establish some of my knowledge, but I don’t think it was as influential for me as “Lessons Learned”. It would have been if I read it earlier.
Finally, I have read the complete archives of James Bach and Michael Bolton blogs. This is not something I can recommend to anyone, as both are very prolific writers - each authored few hundreds articles. I think it took me well over a year to get through them all. Nonetheless, this allowed me to fully immerse myself in their thinking and I can confidently say I understand where they are coming from and where they are going to. This also allowed me to stumble upon few very valuable articles and resources that I still refer to.
There’s a lot that I learned from all these resources, but I would like to point out two overarching principles that I often come back to. One, my role as a tester is to show possibilities and broaden the view of the team. My job is to go beyond simple and quick answers. Two, every single day I need to ask myself: what is the most important, most impactful thing I can do right now? And then do this exact thing, even if it means putting aside earlier plans and ideas. Change is something to embrace, not to be afraid of.
About five years into my career, I began to slowly move into more software development-heavy role. To some extent, that was out of necessity - I saw many tasks that could be rectified with a tiny bit of programming. At the same time, I was in the environment where development was considered higher on organizational totem pole than “manual testing”, and showing programming skills was a clear way for more respectable assignments and higher salary. Similar to my testing journey, that was not the moment I started to learn programming - I have written my first shell scripts and perl programs back in high school. While I did struggle, I felt confident enough in my programming prowess to do some simple things.
The event that really helped me to take off to the next level happened about a year after I joined Red Hat. We had a UI test automation framework, which was recently rewritten by a couple of contractors. They worked in a silo and as a result most of the team was not familiar with that code. My job was to learn it, contribute to it and become one of the maintainers.
I think contractors felt threatened by my presence and thought their job security depended on them being the only people capable of working with the framework. As a result, they made code review a nightmare. They threw it all - passive-aggressive comments, unhelpful comments, misleading comments, requests to change code that was already approved in earlier review cycle, demands to explain almost every single line of code, replying anytime between a day and a week. That was all on top of working with unfamiliar, complex and barely documented libraries.
I don’t look back at that time with fondness, but I have to admit it was an effective learning exercise. I was forced to understand things above my capabilities, and eventually I did understand them. This was very much the moment programming finally clicked for me. Also, I learned precisely what to avoid during code reviews and when teaching others.
Since then, my interests started to move more in direction of software design and architecture. I know I can write good enough code that works. But I also want to write code that is maintainable in the long term and allows for adjustments in response to changing environment or requirements.
In these 10 years, I have primarily been an individual contributor. This is the role I feel comfortable in and which I think suits me well. However, I did act as a kind of team lead in two separate occasions. Both times I was not formally a manager for other people and I didn’t feel I have all the tools necessary to make them do the required work. The first time I was completely unprepared for a challenge in front of me. The second time went a little bit better, as I knew more about ways to informally influence people.
These would be the rough summary and most important highlights of my 10 years in testing. There’s no narrative closure, as I am still here and intend to stay for a while longer. I’m happy to talk about testing, open source, software engineering and related topics, so feel free to get in touch with me if this is something you find interesting, or if you would like to draw from my experience.
Comments