A big welcome to the 50th subscriber to my “new” blog (technically, one is me, but close enough). If this is the first post you’re reading, there’s some background on why I’m blogging again (and on a new platform) in my last post.
The Secret
Let’s start with a potentially awkward self-reflection. I’m known for software testing. I (still) know a lot about software testing. I have ideas and opinions.
Here’s where I share the facts that drops me below 50 subscribers again.
I don’t think I’ve done that much software testing. I mean - I’ve done a fair bit, and I think I was pretty good at it once, but I haven’t really done any hands-on dedicated software testing as a full time job in this century.
What the fuck?
Yeah, it’s worth a recap. It’s a bit long, but I’ll try to keep it readable. I started in tech in 1993 in a role where I did tech support and software testing. It was a small company, and I learn quickly, so within 18 months, I was writing our setup applications, some test automation, maintaining the network, and doing my generalist thing. Then, I joined Microsoft in 1995, and tested the shit out of just about everything to do with networking on Win95. That shipped and then I tested the shit out of Internet Explorer 3. I had no idea why I was a good tester (or why people thought I was), but I did my always-learning thing and kept at it. In 1996, I moved back to Windows, kept testing networking (mostly via API testing in C at this time), and worked a lot on app compatibility tests and debugging for Windows 98. Then I did the same for Windows 2000 a bit before moving back to work on Windows ME (marketing edition), where I worked almost exclusively on debugging and debugging tools. To be clear, I used those tools for testing and discovery (note: I should write a post sometime on exploratory testing in a debugger). Then I managed a test team on Windows CE for a few years, but I mostly managed people and worked on test tools (you can look at the system that I largely designed in my chapter from Beautiful Testing).
More Learning
Sometime around 2004, Microsoft created a new title for senior folks in test. Technically it was for ICs (individual contributors / non-managers), but I was doing so much IC work as a manager (I wasn’t a great manager back then) that my name was thrown in the ring, and at some point a half a dozen or so of us across the company were given the Test Architect title.
Which really meant nothing, since we all just did our own thing.
BUT - I now felt like a complete impostor, so I began to study the shit out of testing. I read a lot. A (true) story I’ve told often is that after I read my first book on testing, I thought I now knew a lot about testing. When I read a second book, I had questions. Once I read the third, fourth, and fifth books, I began to form my own opinions.
So I kept reading. And then I practiced what I learned. Not directly, at least, but since I still managed testers, I coached them on testing (years before I started coaching people on testing as a deliberate action). A year or two later, I joined a central organization at msft where the biggest part of my job was developing and offering training to testers. I began to speak at conferences about testing, and eventually wrote a book that took a snapshot of test and quality practices at Microsoft.
This is already longer than I planned, so I’ll wrap up.
I spent the next several years working on test systems, build systems, and tools to help testers and developers get their work done more quickly and with higher quality. I moved from reading testing books (mostly) to reading books about how teams can deliver software more quickly and with higher quality. I believe that quality and velocity are massively correlated, and my favorite roles (which includes my current role) is leading teams that focus on development velocity and productivity. I’ve managed testers in that time, but identifying as a tester is something I haven’t done in a long time.
These days, I care a lot about quality - and a lot less about testing.
The Big Controversy
If you have followed me or listened to the podcast, this isn't surprising, but worth calling out.
Most software teams do not need dedicated testers anymore.
As I wrote that, I worried slightly that the comments would blow up, but that’s not why I wrote it. A full explanation with examples is a post I could write, but probably won’t (it’s covered in depth on AB Testing), but the short story is that quality and velocity are highly connected. Yes, I hear you, not everyone works on a web service that can be shipped 30 times a day, but if Microsoft can call Windows 11 a service and update it nearly every day, you can do the same with your (relatively) tiny little app. Worth noting, of course, that Windows can do this because they have metrics in place to let them know if a new update is causing problems (or more problems than expected, at least) and roll back as needed. Oh - another non-secret secret that someone is bound to point out is that Windows still has contract testers, but not nearly as many as they used to.
Where was I?
It’s probably time for the TL;DR - which I’m putting at the end so you get the pleasure of reading through to this point. I think I know a lot about testing (I know of at least two people who would disagree, but whatever) - but the truth is that by now, I may have spend more time in non-testing - or at least non-direct testing than I have in test roles. I’m way ok with that, but it feels a bit weird for people to think of me as a tester.
I could have started with that, but the journey was important.
So, that’s who I am. In the context of my new blog, it means that this is likely the last post I write that has a lot to do with testing. I’ll probably write about quality a lot - along with how teams can deliver higher quality (and on time), and probably a lot about how to create a culture where teams can be engaged, deliver and have fun, and I’m looking forward to sharing those stories.
Thanks again to number 50, wherever you are, and I’ll write again to all of you in two weeks or so.
You know an amazing amount about testing. I can imagine the two individuals who might say you don’t, but if it’s who I think it is, they have their own very skewed agenda. You’ve contributed immense amount of great discussion, and I always enjoy what you put out. Thank you.
This seems so familiar. I became known as a test automation expert, though I probably spent more time telling clients why they shouldn't invest in automation than in actually implementing it. I haven't been a testing specialist for years, but I still have recruiters asking me about testing jobs.