Titles – They’re Still Useless

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.

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.



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.

The Lure of Testing

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.

The Myth of the Degree

There’s been s lot reported lately on the Equifax security breach. Equifax failed to apply a security patch for Apache Struts in a timely manner, and attackers took advantage of this to get at a whole lot of customer data.

What we don’t know at this time is whether this was a fluke due to a minor lack of process, a failed attempt at a patch…or whether Equifax has a complete lack of care regarding security. My educated hunch is that the mistake lies somewhere on the former side – although you’re welcome to speculate on whatever side you want. People want to find blame, I guess.

But I’m a little surprised irked mad pissed off on the attention the internet has given to the Music degree of the Equifax Chief Security Officer – and how it’s implied (or in some cases stated), that she is unqualified for the job due to her degree.

First off – while she is ultimately responsible for the security breach, it’s a long shot to assume that her own lack of action is what caused the breach. People still looking for blame but no one but Equifax are in a position for a true root cause analysis of this issue.

More importantly, I see little correlation between degrees and qualifications – especially when the degree is a decade or two in the rear-view mirror. Too many people (and frankly, too many universities) want to view a university like a vocational school – as if a university degree somehow trains you for a real job. While one may learn a good portion of knowledge relevant to a particular career, success in the real world depends much more on the work ethics and knowledge acquisition habits learned while pursuing a degree.

In fact, I’m on the alumni board at my university where I talk to teachers and students frequently about the value of a degree in Arts and Humanities. Once they figure out that I’m not a sell-out for leaving music to work for “the  man”, they realize that the critical thinking and collaboration skills they learn (whether it’s music ensembles, writer’s workshops, or art projects) prepares them for a variety of interesting and challenging jobs should they every find a calling beyond what they’ve studied for 4-years.

Like the Equifax CSO, I studied music at college. I have undergraduate degrees in music composition and music education (I taught music in the public school system for 4 years), as well as a masters degree in music composition. After grad school, I drifted into a job in software. I picked up things quickly, worked hard, and self-studied. I took advantage of opportunities that stretched me (less than 10 years into my tech career, I owned debugger development for windows 9x, and was making bug fixes in the windows kernel). I studied testing and leadership, and became Microsoft’s Director of Test Excellence where I talked to senior leaders across the company and the industry to help them solve their testing challenges. I’ve written shipping code in dozens of Microsoft products, and contributed heavily to the quality of many more. Few (if any) people doubt my ability to be successful at high levels in tech even though I “merely” have a music degree from a small state college.

Of course, it’s not an easy path – nor an immediate one for a liberal arts major to land a tech job. However, it’s ludicrous to imply that an arts major could not be successful in a technology job. I could elaborate to no end on how the skills I learned as a musician have helped me in my career, but that’s not the point of this post.

The point is, that beyond giving you the background and skills necessary for an entry level job, university degrees don’t matter. A university is not a vocational school – it’s not intended to prepare you for one career and one career only. It’s intended to enable you to specialize in one area that you find interesting. More importantly, it’s intended to teach you how to learn to learn (and those work ethics and habits I mentioned above). Thinking that a-particular-career requires a-particular-degree is short-sighted and just-plan-wrong.

As a hiring manager, I’ve insisted that CS degree requirements are removed from my job descriptions – or at the very least adding ” or equivalent” to the description (yes, even / especially at Microsoft). OTOH, I’ve interviewed software engineering candidates from top schools who failed to get jobs because they had a huge lack of critical thinking or couldn’t apply their knowledge in a practical manner.

I think a university education is extremely valuable – especially if you put extreme effort into getting as much as you can out of the experience. The degree (other than helping you find that first job), is much, much less important. Emphasize the journey (learning) over the outcome (a piece of paper), and never doubt someone’s ability to do a job based on their degree.

The Matrix Organization and the Future of Test Management

I stumbled across an article by Steven Sinofsky where he discusses the merits of the Functional vs. Product team (tl;dr – managers of a discipline – e.g. all testers vs. Feature teams). Although the article was published just a year ago, Steve is discussing an organizational change from a decade ago in Windows where development, test, and program management all reported to respective vice presidents of those roles. If my memory is correct, there were over 3000 testers reporting to a VP of Test. Of course, everyone interacted, but Steve was a huge proponent of BUFD and test-last approaches, and I think the product quality reflected that approach.

Reading the article about functional testing reminded me how much that model doesn’t work – but here I am in 2017, and I’m the manager of a QA team of almost 40 people…

But it’s not the same. I think a lot of QA/Test organizations today (mine included) are run as a matrix organization – meaning that people in my organization have two different reporting lines. They meet regularly (including 1:1s) with feature team leads, and meet with me (1:1s and informally) to help solve problems, brainstorm, or share stories.

In Agile Testing (Crispin, Gregory), there’s a line that captures my feelings about the manager role exactly.

Rather than keeping the testers separate as an independent team to test the application after coding, think about the team as a community of testers. Provide a learning organization to help your testers with career development and a place to share ideas and help each other. If the QA manager becomes a practice leader in the organization, that person will be able to teach the skills that testers need to become stronger and better able to cope with the ever-changing environment.

In this model, I’m responsible for making sure my team have the skills and knowledge to be successful. I like the idea of being a practice leader, and think it serves the team well.

Long time readers may recall that when I joined Microsoft Teams, I was the sole quality guy in charge of getting a bunch of developers to worry about writing quality code. That model (mostly) worked as well, but probably only because I have a chunk of experience both in testing, and in dealing with ornery developers. A main point is that I didn’t really have embedded testers on that team, and overall, the team was quite non-agile anyway – but I did a good job on that team making sure we had a quality product despite ourselves, and I’ll always be proud of that.

I bring up the Teams story, because I can see a path where I do not have a team (or not a large) team anymore. As I build a community of practice around test and quality, and as our development teams take on more and more responsibility for quality practices, I can see a world where (most of) my team reports only to feature team leads, and my role (if it’s worthy of employment) is purely a practice leader in quality and testing for my organization. It won’t happen next month, and not even next year…but it’s a path that makes sense to me (and one I’ve mentioned on the podcast a few times too).

And of course, if I can see this future, odds are that someone else has already gone through this exact transition, and more will follow.

And so begins the downward spiral of the Test and QA Manager. May we all survive the revolution.

The future of the automation engineer

Although I’ve tried to avoid writing about test automation since publishing The A Word four years ago, I suppose I should probably take some time soon to add a few more chapters before the book (like my last one) becomes largely obsolete.

Not too long ago, I posted some predictions. In those predictions, I said:

Testers writing automation will become a rarity. […]testers won’t write that much application automation. Unit and integration tests will be written by the developers on the team (w/ coaching from the test specialist on their team as needed). The test expert on the team who code will more likely write diagnostic tools, frameworks for “ilities” (perf, security / fuzzing, stress, etc.) – as well as other tools / processes / approaches that accelerate the achievement of shippable quality.

A few weeks ago, I spit out a small tweet storm about the same topic. The TL;DR version is that I have a strong opinion that the role of someone who solely writes automation for developer produced code will be gone soon. There’s just no good reason I can see anymore for developers to not write test automation for their own code.

For a longer, and really, really well annotated version of my tweet-barf, please check out Richard Bradshaw’s excellent post here. Richard was one of the people I thought I’d scare with my tweets. He’s been (as far as I know) in the role of a test automator for some time. But he agreed with me. He gets it. He sees it too, and he’s in the trenches doing this stuff, while I’m just a talking head most of the time.

That means something.

I know there are some readers who don’t follow me on twitter and may have missed this – but my tweets – and Richard’s further thoughts on the subject are important, and a “prediction” that I am absolutely confident will come to life.


Making it Easy to Do Good Work

Time has flown, but it’s now been six months since I quit my job at Microsoft. That’s nothing compared to the 22 years I worked there, but still a minor accomplishment. I won’t rehash the differences between Microsoft and Unity – so I’ll just say it’s a different and (for me) pleasant experience. I spend a chunk of my time recruiting and hiring, and one thing I tell candidates about working at Unity is that “it’s easy to do good work here.” I emphasize that the work itself isn’t easy – the work is plenty difficult. It’s just that there are few obstacles (office politics, politics, micro management, etc. getting in the way of doing great work.

I’ve been here now just long enough that I have some idea of what I should be doing. Which, of course, means that I’m realizing how much work there is to do. But I’m up for it, it’s challenging, it’s fun, and it’s easy to do good work here. I still have a huge amount to learn, but it’s more exciting than the day I started.

The change of pace has also (apparently) been good for my health. My blood pressure  – which had been a solid 120/70 into my early 30s had slowly climbed over the years – peaking out at a pre-hypertension level of 138/80 in my last two years at Microsoft. Two weeks ago, I was pleasantly surprised to discover that my bp is almost back to my two decade old norm at 122/70. It’s a small victory, but one I’m proud of.

In the next six months here (and beyond) I’ll work a lot on moving our Services org to rely much more on monitoring, usage analytics and testing in production. There’s a ton of work to do, and really hard problems to solve, but we’ll get it done.

Of course, if you want to be part of this journey with me (no guarantees on improving your health), I have openings in Bellevue, San Francisco, and Helsinki.

A call to action: let’s fix the Wikipedia page on software testing

Today, I had a few minutes, and wanted to try, yet again, to make some positive change to the article on software testing on wikipedia

I failed. It’s a mess, and I don’t know where to start. It’s too long. It’s unorganized. Many / most of the citations are a decade or more old. Some blanket statements are un-cited (and arguably false). Other citations point to non-peer reviewed conference presentations. At best, some citations are from books 20 years old. Software testing has changed, but the entire article represents antiquated methods of testing. I recognize that many teams test this way, but the article fails to recognize many other testing approaches.

@noahsussman attempted to clean a large chunk of the article, but it was blindly (mostly blindly) rejected. He needs help, but I’m not sure how to help him by myself. I don’t know what the new article should look like, but I want to be a part of creating it.

My first challenge for you is to go read the article from beginning to end. If things don’t sit well, read the citations. Try to make sense of it. Then come back here and tell me if you’re as frustrated (or as embarrassed) as I am. Compare it with the article on software development if it helps.

My second challenge is for you to join the cause to fix it. Send me a DM on twitter (@alanpage) – or send me an email (this domain – alan), and I’ll add you to a slack group where we can discuss strategy, share thoughts, and figure out how to modify this article so it makes sense to all of us – and that it’s an article we all feel can represent the current definition and state of software testing.

To be clear, I think there’s some value buried in the current page, but I think it can be much, much better. If you agree, come help me (and if I can get him re-involved, help Noah as well).

Predictions and other stupid things

Between my talk at the online testing conference, and in discussions with Brent on AB Testing – and my day job thinking about service quality at Unity, I’ve spent a bunch of time lately pondering the role of the tester in modern software engineering, and what it means for today’s crowd of software testers.


Years ago, I gave a few presentations on the Future of Test. In hindsight, it was stupid of me to attempt to predict the future of testing, and I caution anyone thinking of going down this path (my hypocritical predictions are below). Years ago, I talked about “cutting edge” test ideas and claimed they were (or may be) the future, but few of those ideas are as interesting today as they were then. Today, I read an article on the Future of Testing that describes testing and software development practices from years ago. The future, it seems, is based a lot on context and point of view. That’s ok, and I ask  you to consider that before you disagree (or agree) with my own thoughts.


All that said, I think I can make a few claims about where testing is going – even if these changes are years (or decades) out for many testers. Consider these wild-assed guesses based on my own experience rather than predictions about the future.


1) Independent test teams are diminishing in favor of the test specialist. Many examples of this already in software. This ultimately means fewer testers, but good testers will remain in high demand.


2) The industry infatuation with automation – especially UI automation will finally fade. I’ve been asking testers to stop writing automation for nearly a decade, and I’m beginning to see more and more examples of teams halting their UI automation efforts, and investing in unit and integration tests (and monitoring) more significantly.


3) Testers writing automation will become a rarity. Hand in hand with both points above, testers won’t write that much application automation. Unit and integration tests will be written by the developers on the team (w/ coaching from the test specialist on their team as needed). The test expert on the team who code will more likely write diagnostic tools, frameworks for “ilities” (perf, security / fuzzing, stress, etc.) – as well as other tools / processes / approaches that accelerate the achievement of shippable quality.


4) Huge amounts of testing will be done via monitoring real customer usage. I shouldn’t include this one, because it’s already true for many, many products already, but I see enough people disbelieve in this approach for their product, that I’m throwing it out here anyway. Given that it’s been 10 years since Keyes said that good monitoring is indistinguishable from testing, the disclaimer makes me feel icky, but still seems necessary.


I can’t wait to revisit this post in five years and see how irrelevant my claims are.

Technical Testing at the Online Testing Conference

In just under 5 days, I’m giving a presentation on Technical Testing at the Online Testing Conference – http://www.onlinetestconf.com/

If you’re wondering, “WTF is technical testing?” I’ll give you my opinions (as well as some examples) along with the usual angry weasel rants.

Here’s the twitter preview if you missed it.

Dear Weasel, What do you have against career growth?

The inevitable follow up to my last post is a discussion on career growth, and how to manage it effectively. For the record, I am not against career growth – in fact I think it’s one of the most important parts of my job. What I’m against, is employees making decisions based on growing their career over decisions based on making our customers lives better.

I’ve built “career guides” before to give employees examples of what growth looked like. At the time, I thought I was doing the right thing, but I don’t think so any longer. If an employee leaves your org / company because they didn’t feel like they had enough opportunity to grow, the problem is NOT a missing checklist of example tasks or competencies.

It’s a management problem.

Every manager must be deliberate and passionate about understanding what their team members are good at, and where they need to improve. Managers need to provide challenging opportunities for their employees, and provide a balance of tasks that stretch their employees and make them learn; and opportunities in their “wheelhouse” where they can excel and lead by example.

Managers who don’t do this should not be managers.

This is a point worth more discussion. Many people move into management, as a growth opportunity (or more directly, they view it as a promotion). They may like the perceived importance of more meetings and visibility, but that’s absolutely the wrong reason to be a manager. Of course, decision making, communication, etc. are important for managers, but the most important thing has to be managing the careers of your employees. If a manager is not vested in challenging and growing their teams, they are 1) not challenging themselves, and 2) managing a team that is not learning or growing. In my experience, this is a horrible way to manage a team.

So what does this have to do with career guides / ladder levels / whatever your company calls the checklist they use to describe career growth?

What I’ve seen (granted in one company directly), is that employees use the guides as a checklist. They look at the bullet point examples for the growth level above their own and write a sentence about every single one, and then go their manager and ask why they aren’t being promoted. The guide drives their work.

I much prefer a model where it’s the managers responsibility to make sure employees have a growth plan, and transparently and frequently communicate with them on types of tasks and challenges that are appropriate to their growth – but focus on the work that makes the business and the customers successful rather than on words on a page in some internal HR documentation. Create career development plans – write them down if you need to, but focus on improving the business, and assign tasks and responsibilities that stretch and grow your employees towards that goal.

I do see how transparency on career growth communication can help a company – and even why some companies may need it; but I think there’s a huge trap to fall in when going down this path that most companies do not consider. Do what you must, but, as with most initiatives, be very careful of driving wrong and damaging behavior.

%d bloggers like this: