Five for Friday – November 17

  • I’m heading back into a flurry of travel after taking it light for several months. This time, I plan to take Austin Kleon’s advice on Never pay for wi-fi to heart and take the travel time purely for reading, drawing, and reflecting.
  • I’m still reading Pragmatic Thinking and Learning and thinking a lot about the Dreyfus model of skill acquisition, and how “Advanced Beginners” due to the Dunning-Kruger effect, often overestimate their (our) skills. In knowledge work, we see this all the time, and it’s good to notice it and see how we can help with the inherent problems with this.
  • Marcus Purvis share this article from Pinterest on (more) Lessons from Scaling Pinterest. This is a follow up to some earlier points (link in article), but this one is a lot about leadership, and a lot of good lessons for those in leadership positions.
  • Last week at the (internal) test summit, one of my employees re-introduced me to the Software Testing Cupcake anti-pattern. It was relevant, funny, and worth reading for everyone.
  • If you want learn more about Unicode, get some new testing ideas, or just want to see some scary exploits, check out this article on Five things everyone should know about Unicode by Gojko Adzic.


The Worrisome World of Words

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.

Five for Friday – November 10

Had my entire team visit me in Seattle (Bellevue) this week, so I’m a little slow on this week’s share.

  • This quote about Agile is something I think I’ll repeat frequently – “Agile is worthless unless it serves as a catalyst for continuous improvement. ” The full article (here) is also worth the read.
  • Twitter appears to have rolled out double-length tweets for everyone. I’m not typically anti-change, and I usually know why I don’t like things – but I’m still pondering why I don’t like this.
  • I’m currently reading Pragmatic Thinking and Learning. It’s been on my about-to-read list for years, and I’m sorry I waited so long to get to it.
  • I found a few leadership gems in this article on – most importantly, “Culture comes from what you do, not what you say.
  • I used a Macbook for my last 6 months at Microsoft, but switched back to Windows when I joined Unity. After 9 months of really bad experiences with Windows, I gave up and moved back to a Macbook. It’s been an easy transition, with far fewer (so far) isues.

Me, elsewhere

I shared an article on rotten automation on the testproject blog here –

A was also part of of Engel Jones 12-minute podcast series. My interview (very little about testing) is here –


Five for Friday – November 3

Here are five things that caught my attention this week.

  • I created a mind-map for an article I have coming out next week. It reminded me how valuable mind-maps are for communicating information. I’ve had a lot of luck using them as test strategy docs, as the visual nature gets much more engagement and feedback than a more traditional word-only based plan.
  • I read Susan Caine’s book, Quiet years ago, and still put this quote in presentations from time to time.
    But the idea…is right. To innovate, we need environments that support imaginative thinking…heated discussion, even arguing

    It’s so important to not avoid conflict in order to create and innovate – but do it in a way where respect and trust are always part of the environment.

  • This article from HBR reminded me how important it is to balance purpose and strategy in an organization. I saw (and fought against) a lot of this at Microsoft, and do my best achieve this balance in my work organization as well as my family.
  • This week, I learned about the Motte and Bailey fallacy. I see this one pop up in the twitter-verse and in some aggregated blot sites a lot – it’s where someone treats a smaller part of the whole as the whole, and uses defense of the subset as a defense of the entirety. Look for it in writing and in your own decision making.
  • I fell away from inbox zero for a while. I was lazy and didn’t spend a lot of time mucking around with email. I adapted most of what I read in this article, and now I’m easily back to my Inbox-zero lifestyle.

Five for Friday – October 27

Five things floating through my head this week.

  • I’ve referred to a line from Leadership on the Line (Heifetz / Linsky) more than once this week (and hundreds of times over the years), but worth sharing again here. “Leadership is disappointing people at a level they can absorb”. I’ve frequently used “… at a level they can tolerate“, but the point is the same. No change == stagnancy. Too much change == anxiety. Find the balance of comfort that allows people to move through change.
  • I’ve been reading the latest Heath brothers book on The Power of Moments. I’ve liked all of their books, and this one hasn’t been disappointing. In short, the book is a deep dive into understanding what makes some events in life stand out in our memories (and how we can lead people toward those moments).
  • There’s a new podcast in town. I’m really enjoying the Testers’ Island Discs podcasts hosted by Neil Studd. It’s fun to hear tester stories, and as a music geek, wedging in eclectic and fun songs into the conversation is quite entertaining.
  • This week, I learned what Morton’s Neuroma is (it’s a nerve thing in the ball of the foot). After years of powering through pain, I finally got a proper diagnosis. While all that is exciting (not), the real win is that the treatment (a small pad behind the ball of the foot to push the bones forward) is both simple, and massively effective. As someone who wants to avoid surgery and chemical injections, I’m ecstatic that the treatment was this easy.
  • On a much sadder note, yesterday, I heard that Noel Nyman passed away earlier this week. I had the privilege of hanging out with Noel for many years at Microsoft, and give him a lot of credit for introducing me to the overall tester community. He was involved in presentations, peer reviews, and workshops long before I entered the testing scene. He’s been low-key for a while, but he’ll still be missed by the community.

Five for Friday – October 20

As promised, back again with five things I think are worth sharing this week.

  • First off, everyone needs to read this post from Cassandra Leung. It’s a well written and haunting view into sexual harassment. It’s something we all should read, reflect, and keep in mind as we grow any community we are part of.
  • This week’s WPA2 bug / exploit reminds me how much we all need to know about security (it’s not just a job for the experts). I ran into Feisty Duck this week, which  in addition to sounding like a cousin of Angry Weasel, has a ton of good information and training on software security.
  • Ministry of Testing are making a calendar to raise money for Linnea Nordström – the daughter of a member of the testing community. I bought two.
  • I just finished reading A Practical Guide to Testing in Devops by Katrina Clokie, and it’s really good. It’s a How We Test (internet connected) Software book that will answer a lot of questions I see testers ask about where software testing is going. It’s easy to read, balanced, and complete.
  • All of the desks at Unity can switch from seated to standing. As such, I’ve stood and worked a lot since I joined. I like standing when I work (like I am right now), but I just improved the experience 10x by buying a Topo from I can’t rave enough about it. It’s a little expensive ($100), but worth every penny.

Five for Friday – October 13

Inspired by Tim Ferris, and more recently, Marcus Purvis (Five Share Friday), I too am going to start sharing five interesting-to-me ideas or links every Friday.
Until/unless I forget. Here goes this week’s list.
  • I’ve been reading a lot (a LOT) of management books recently. Last week, I completed Debugging Teams, and recommend it. I found the earlier chapters to be interesting and valuable, especially concept of HRT – Humility, Respect, and Trust, and think it’s a good way to treat people in general.
  • One of our organizations at Unity uses peer bonuses. I have liked the idea ever since I heard of Google doing it years ago. Now, there are sites like to help orgs get this concept bootstrapped
  • The latest (oops, not latest  any more) Manager-Tools podcast is an interview with Wade Foster (CEO of Zapier). Zapier (which is just damn cool on its own) is a 100% remote company, and the interview shares a lot of ideas on how to combine good management with remote work.
  • My job is filled with random tasks, and my personal life isn’t any better. Many years ago, I began using to track everything I do in a personal kanban board. The two rules of kanban (visualize your work, limit your work in progress) help me keep things organized and get stuff done. I also attended a class once from Jim Benson and highly recommend his book on personal kanban
  • At this very moment, I’m listening to one of the best artists you’ve never heard of. Ben Union (also on spotify) is a Seattleite with some (I think) really interesting music.

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.

%d bloggers like this: