Iโm running a 28-day challenge throughout February where I post a daily testing question or prompt. The goal: get testers talking about the real stuff: how we work, what we struggle with, and what actually makes QA better. Anyone can join in. Hereโs Day 1.
A browser opened by itself. Input fields filled in. No human touching the keyboard.
I watched it happen and thought: I want to create these โbotsโ for the rest of my life.
But let me back up.
I trained as a system admin. Turns out I was terrible with hardware. Software was my thing. One department had me testing custom extensions against new Office versions. ๐ก๐ผ๐ฏ๐ผ๐ฑ๐ ๐ฐ๐ฎ๐น๐น๐ฒ๐ฑ ๐ถ๐ โ๐๐ฒ๐๐๐ถ๐ป๐ด.โ Nobody called me a โtester.โ I just liked breaking things and seeing what held up.
Later, a startup hired me as sysadmin. Again. But my CTO saw what I actually loved doing. He gave me a word for it: ๐๐ผ๐ณ๐๐๐ฎ๐ฟ๐ฒ ๐๐ฒ๐๐๐ฒ๐ฟ.
That moment changed everything.
For most of my career since, Iโve been the ๐ผ๐ป๐น๐ ๐ค๐ ๐ผ๐ป ๐๐ต๐ฒ ๐๐ฒ๐ฎ๐บ. No one to check my thinking. No one to say โyou missed this.โ I found communities eventually: Ministry of Testing,TestGuild and mentors like Daniel who gave me the chance to publish my first article.
But that took years. And a lot of figuring things out alone.
๐๐ฎ๐ ๐ญ. ๐ฌ๐ผ๐๐ฟ ๐๐๐ฟ๐ป. How did you end up in testing and are you the only one doing it on your team?
My falling into testing was pure accident. I worked somewhere doing written test cases for some financial software, and in my spare time I learned how to code my own automation tool, not just use one, with a page-object style DSL in Ruby (before page objects were cool). I began exploring, because Iโm not a great rule-follower when I donโt understand the rule. There I was on my own.
I took those skills to my next job, where I offered to build such a suite. But hooking into their weird proprietary code-making code was impossible - watir couldnโt get its teeth in anywhere. I took a look at their over-formalised test case suite and I knew I was damned if I was going to do that on the regular, so I began researching. Surely this wasnโt how testing was done? It didnโt sit right with me, I just knew that they must know more than I did. I found James Bach at an MoT event, where I won a book, and where I found a whole new approach to testing based on scientific fundamentals - basic precepts of scientific philosophy applied sensibly to testing. And thatโs where testing really began to excite me - that it could be done with respect to reality and situation, based on exploratory skill and not formulae and paperwork. I worked there as the only tester for most of my career there. For that Iโm grateful as it really gave me the opportunity to find my way and apply testing however I saw fit. I could define how testing was done, build tools, learn skills, take courses and make myself good at what I do. Not every tester is afforded that sort of freedom. MoT was a big part of the space I could use to explore new ideas, and for that Iโm also grateful.
After that came working with other testers. I was well-positioned to join groups because I had to prove to myself I could be a good tester (and Iโm a harsh judge of specifically me), and I could speak about it and answer questions on it and appear to be good at it - which is important when you want other people in a team to take you seriously. I tried to take comments like โyou could even be a developerโ as a step in the right direction.
I would never have stuck with testing if I couldnโt do it with respect to reality and context. Which did limit where I would work, but luckily I always found people brave enough to accept someone who wanted to improve processes and work their own way.
For some setup, it was my first internship, and I was doing some software dev when I was talking to the project manager (this was at a startup incubator that was partnered with my university) about a software testing course I had just taken.
I was excited about it, and thought there was more that could be done there for a lot of software projects.
Sometime after that, he asked me if I would be interested in working for a startup (that was partnering with the incubator) as their first tester. I interviewed and they hired me.
I visited the โC Bitโ trade fair in Hannover many years ago while I still worked in Oceanography at the University of Bremen. I saw many interesting booths there. At one of them I learned about object-oriented data bases. While there I grabbed a packet of peppermint they offered.
Quite a while late it became apparent that I wonโt last in academia much longer and I started applying for IT jobs. I bumped in to that box of peppermints and applied at that company, too.
I didnโt think theyโd even invite me: I fulled the application form, they sent me what I filled outโฆ and it looked terrible. Nevertheless, they did invite me to an interview - on the same day I applied.
This was one of the to most interesting, entertaining and, I admit, demanding interviews I had ever. They hired me as a software tester to work on their self-built test automation framework, to improve the framwork and the tests automated with it.
That was more than a ยผ century ago and Iโm still a tester. Was it an accident? Very much so.
But then, maybe not so much after all: I still think the the principles of physics (my original subject of study) and ocenaography (the physical part of it) are the same in testing: We have expectations of systems we examine, we run experiments, interpret the results and come up with conclusions about what part of the assumption/model/hypothesis did not match the experiment. โ To me, software testing is pretty much the physics of software development.
In my team, Iโm not the only tester. In fact, weโre all switching between testing, programming and some other roles every now and then.
Like many people I fell into testing, although my early career was around software and IT, so not too big a leap.
I studied Computer Science and Software engineering at university. I started as a junior consultant at a UK consultancy. During the part where they figure out what area suits you, I bounced around.
Initially earmarked for application support: I was technical and could communicate well with people to bridge the gap. Very soon a client wanted testers and automated testers, and I was pivoted into that instead.
Since then Iโve worked in different teams and organisations. Ranging from a tester in a separate test function, to operating as a test consultant across many, to coaching and supporting others in their testing skills.
A long and winding road. I started as a lab technician after school. Testing toothpaste, shampoo and the like for things such as component degradation at different temperatures but while we were doing that I got involved in the introduction oof computers to help analysis and reporting, ending up with me only doing that.
So, that lead me to go to uni at 24 and get a BA In Systems Analysis. For the placement year I built (designed, coded and tested) a DOS database to produce P11Ds! The only go live issue was that I hadnโt thought of timing how long it took to print them, so we delivered a day late but that was nearly a month better than a specialist company managed the year before.
My journey after graduation took me through IT Consultancy (Another DOS database, COBOL, Visual Basic amongst other things) to Business Analysis and finally into testing, where I found I felt right at home.
I gained insight and confidence over the years to lead others in delivering testing, always learning and discovering that testers are the nicest bunch of people in IT
