Author: Alan Page

In software testing, we use a lot of words – some well known, others less so – to describe our testing activities. For as long as I’ve been in software (which is longer than most of you), we’ve debated and argued which descriptions, and which combinations of words best describe the various activities that fall into the world of testing.

Is that a smoke test, or an integration test? Is it a load test or a stress test? Is it automated testing, tool smithing, or computer-assisted software validation? Is it testing, or checking? Is it manual testing or human testing? I fully understand the debates – words, do indeed have meaning, and words can mean different things to different people. Some (including me) often call most of these debates “semantic bullshit”, but I admit I do see the reason for nuance and discussion. I will even openly admit that I was part of a working group at Microsoft once who tried to develop a taxonomy of testing terms.

My stance has changed.

The more I think about it, the less I care about what people call their testing activities. I’m increasingly becoming a fan of labeling tests “small”, “medium”, and “large” (and when necessary, “enormous”).

“Bu-bu-bu…but we need to know what the test does…!”

No you don’t. But you do need to know why you’re running the test.

In Start With Why, one of my heroes, Simon Sinek talks about how starting with the question, “Why?” (rather than “What?” or “How?”) is a better way for leaders to inspire the right actions from their team. It hit me recently that there’s a strong parallel with his leadership mantra and why I am caring less about the words we use in testing.

We don’t build software to beat our competition, or to satisfy our own intellectual curiosity. We create software to help our customers solve problems (customers don’t want software – they want their problems solved).

When testing software we should focus on why we’re testing the software. What are our quality goals and why are they important for the customer? I believe that if the software team is aligned on mission and purpose, that the words we use to describe activities toward those goals have far less meaning than if we focus on describing what we’re doing.

As I type the sentence in bold above, I realize that I feel even more strongly about that phrase. Yes, words have meaning, but mission and purpose carry far more weight in the journey towards software quality.

I shared an article on rotten automation on the testproject blog here – https://blog.testproject.io/2017/11/07/somethings-rotten-test-automation/

A was also part of of Engel Jones 12-minute podcast series. My interview (very little about testing) is here – https://twelveminuteconvos.com/alan-page/

In what seems like a lifetime ago (it’s been six years), I wrote about Titles for Testers (tl;dr – they don’t matter). My wordpress stats tell me that it’s one of my most popular posts with links from a crapload of sites.

The 2017 update is that titles still don’t matter. Well, they do in a way. Titles (especially for testers) are a distraction.

Last night on twitter, I saw this job advertisement tweet.

Blizzard Entertainment is looking for: Test Lead IIhttps://t.co/VoYZDhJtk3 #job

— Michael Gilmartin (@MHGilmartin) October 2, 2017

Totally cool (and worth it) to publish job postings on twitter, and Blizzard makes fantastic (your opinion may vary) games. I’ve played 1000’s of hours of Warcraft, Diablo, Starcraft and even some Hearthstone. I should have played Overwatch too, but couldn’t carve off the time.

Then, there’s the job title.

WTF is a Test Lead Eleven? Oh wait, those are Roman numerals – it’s a Test Lead 2.

Cool.

No.

WTF is a Test Lead II?

Wait, it’s worse. The job description describes the job as “Associate Test Lead”.

Again, WTF?

I’m sure A Test Lead II falls right between a Test Lead I and a Test Lead III – or maybe the former is called a Test Lead and the latter a Senior Test lead, but putting that title in that post isn’t going to help Blizzard (or anyone) find  the right candidate. In fact if I were looking for a mid-level test lead job, and I saw a posting with that title, my heeby-jeeby HR bureaucracy spidey sense may tell me to steer clear.

Short story is that it’s an exciting job for the right person. I’m not picking on Blizzard – they’re awesome. I’m picking (yet again) on job titles.

Now, it’s one thing if you’re recruiting internally. At the Big M, role moves were lateral, and job titles reflected the level of the role. If you’re advertising the job to people who know what the lingo means, you can use corporate dictated titles. That makes sense.

But when recruiting externally, you have to turn that shit off. If you want to exude an air of fun and excitement, why throw a bureaucratic title into the description? Sure, you’re going to have to give whoever you hire a title that matches the corporate structure, but that doesn’t mean you can’t troll for a Test Lead or Test Leader or Test Manager, or Quality Rockstar, or Badass Guild Master in your external job postings and social media.

Now I’m off to review job titles at my own company before the discoveries of hypocrisy roll in.

People talk a lot about how they got into testing (I was told I was a tester on my first day at a tech support job), but for those of us who have been in testing roles for a substantial amount of time, I think it’s equally important to think about why we have stayed in testing or in quality related roles. I think for some, it’s simply because they like it and haven’t seen a need to change. For others, including myself, there are moments from our career that anchored us in testing or quality roles.

I’ve told this story verbally a hundred times, but don’t know if I’ve shared it here – at least not explicitly. For me, there was a moment when I re-fell into testing; the time I knew where I’d always be in a quality focused role. Here’s my story.

I joined Microsoft as a tester – first as a contractor, and then as a full time employee. I tested, and wrote some automation and tools to help to help me test better. I also studied and practiced coding a lot. I read Maguire’s Solid Code, and I learned how to write safe and maintainable C code. By the time I’d been at Microsoft 5 years, my title was Software Development Engineer, and I was maintaining the windows debugger, debugging and fixing code in the windows 9x kernel and writing code more than I was testing. I still worked in the test organization, was still involved heavily in test strategy and test design, but I was a respected coder on the team.

About a year later, while running a large test team in embedded Windows, my manager volunteered me to take over a chunk of feature development. At the time, we both thought my growth path was apparent (software development), and I had a solid reputation, so I took over development responsibilities for an entire feature. We were several months away from shipping (it’s still weird recalling a time when we shipped every few years), and I was responsible for implementing half a dozen features and fixing ~20 or so bugs.

I. Love. Fixing. Bugs. I’ve always enjoyed digging and debugging and figuring out the exact reason why bugs occur, and then testing the crap out of fixes to make sure it’s the right fix. To this day, I really enjoy fixing bugs (I fixed at least 100 small bugs in XBox One networking and blu-ray), and have bug fixes in almost every product I ever worked on at Microsoft.

The features were another matter. I got them all done, and also wrote tests for all of my work. I practiced code craftsmanship, and think to this day, that the code I wrote would stand up (the product, Windows CE, is long forgotten). But, except for one feature (daylight-saving time clock update), I found feature implementation to be far less interesting than debugging an testing. While the features required some learning and some investigation, I found the feature work to be much more rote-like than the open ended-ness that I found in trying to solve testing problems.

We shipped the product, and I was offered a development lead position. I was flattered, but said no. It had never been more obvious to me that the challenges in testing were the types of challenges I wanted to be involved with directly. Feature development is not my strong point, and my interest in it pales to my interest in solving testing problems. Since then, I’ve continued to straddle the line between development and testing a lot (e.g. see the bug fixing comments above), but my focus of heavy study and practice since then has been software quality. It’s been 16 years since I made that choice, and I haven’t regretted it once.

Of course, testing today is much better than it was back then, and my role (QA Community Leader, or Agile Test Manager, or ????) is much different, the the essence is the same. The problems I am lucky enough to get to solve are some of the hardest problems in software engineering. I get to be creative, I get to be a leader, and I get to learn every single day. The industry has changed, customers have changed, and I have changed – but I’m happy with my career choices and fortunate to have made at least one good choice in my career.