Being Anal About Developer Cover Letters and Resumes

Q: Why are you such a nitpicky jerk about typos and grammar errors on the cover letters and resumes of developer candidates?

A: Because they’ve had all the resources in the world to make them perfect, and they’re applying for a job where having even a single character wrong can mean a significant difference the correctness of their work.

Curiosity Killed the Cat, But It’s the Lifeblood of a Tester

My employer partners with a local university as part of an internship program; computer science students have an opportunity to participate in a series of six month paid internships with local software development groups. As a result, we’re now about three weeks into working with our latest intern. We’ve had two previous testing interns.

It’s interesting to see how they begin testing. With each of them I’ve set things up with an introduction to context driven testing and the ideas of software exploration and working with various heuristics to exercise the program.

It’s interesting to note if the new intern has an innate curiosity to explore.

Our current intern started at the beginning of the month. On her first day, as she began to explore one of our applications, she caught a bug that appeared when you altered a URL query string.

Curiosity: the lifeblood of a tester.

CAST Vancouver, BC: Coming Soon

I’m looking forward to attending CAST next month in Vancouver, BC, which will be my first time at this particular conference. I’ve heard lots of good things from past attendees, and I look forward to what seems like a very practical lineup of folks talking bout real-world testing issues in an interactive environment.

I’ll be arriving on Sunday and attending James Bach and Fiona Charles’ tutorials on Monday.

I may try to organize some sort of Sunday evening gathering for craft beer lovers – keep an eye on Twitter.

The Gatekeeper Must Own the Quality

The notion of the software tester as quality gatekeeper is generally seen as outdated; Jason B. Ogayon recently shared We Are Not Gatekeepers that does a great job of laying out the ideal scenario where the product owner is the one who makes the release decision and decides what level of quality is acceptable for the product.

In theory the team shares in the ownership of product quality; this isn’t a hard sell when things are going well. If the product is awesome, the team will generally own that and take pride in the quality, or as Jason noted:

We are not the authority about software quality, because the whole team is responsible for baking the quality into the product at every project phase.

Things get stickier when things aren’t great. If the product has a lot of defects, or is missing functionality that was previously expected, sharing the ownership for those shortcomings is often uncomfortable. It’s easy to blame the tester who raises the issues or reports on the poor quality.

But, much like the whole team being responsible for baking the quality into the product, the whole team, not just the testers, take responsibility for flaws in the quality recipe, and the individual who sets the quality bar assumes that gatekeeper role and responsibility.

Why I’ll Be Back at STARWEST

I’ll be returning to Anaheim next month to attend STARWEST1. I’ve been a couple times previously and have generally found it to be a useful, fun experience.

In looking at this year’s program, several topics/speakers stand out. I’ve found great value in the half- and full-day tutorials. One thing I like about STARWEST is that during the “regular” conference talks there are five or six tracks being offered, which generally means there will be something of value in each time slot.

Beyond the program (and this really applies to all conferences, not just this one) is the other key value in these events: the informal networking and conversations. Whether it’s over lunch at the event, in the hallway between sessions, or in the evening at a bar, I’ve made some great connections with folks from around the country who share similar (or dissimilar) testing experiences.

Nighttime at DCA

Looking towards Paradise Pier at Disneys California Adventure

Also: it doesn’t hurt that I’m a Disneyland fan.

Will you be at STARWEST? Let’s connect.


  1. I have no idea why STARWEST is in all capital letters. But it is. 

When Quality Loses

Context: agile development with prioritization and release decisions being made by a product owner.

There’s often a false understanding of software quality (and the responsibility for software quality) in our industry. This falsehood isn’t helped by the “Quality Assurance” job title. With modern development practices, it’s misleading to presume that software testers are responsible for the quality of the released software.

QA as a Quality Advocate

As a software tester, we identify potential changes to the software. Sometimes it might be an obvious bug, where the software is not producing the response that’s clearly expected. Other times we might find potential enhancements such as new features or usability improvements. Either of these categories provide opportunities for improving the software. As a software testing and quality professional, I feel that I have an obligation to suggest that the software could always be better. When quality wins, users will have a better experience, and data will be in a quantifiable better state.

As a tester, I advocate for quality.

Testing != Release Decisions

Ultimately while I advocate for quality in the software I test, the ultimate decision on when to release (given whatever is known – or not known – about the quality of the software) belongs to someone else. In the agile world that’s usually the Product Owner; in other environments it might be a project manager, release manager, or other similar role.

That person – the one making the release decision – is the one who ultimately decides what level of quality is acceptable for a software release. Testers can help inform, but testers can’t insist.

Sometimes, we’ll advocate and our voices will be heard and the quality threshold will be raised prior to release. Sometimes, our voices will fall on deaf ears, or be drowned out by other voices or pressures.

Parked Cars, San Bruno Gas Line Explosion, 2010

The Release Where Quality Loses

When the quality isn’t up to par but the software is released anyway, expected repercussions will possibly and predictably include:

  • increased number of bugs-found-after-release
  • increased number of user support tickets
  • increased number of data or application hotfixes to resolve problems
  • PR or perception problems

Nobody in the development and product teams should be surprised by these results.  Sometimes there’s value in having the software released, even in a state of lessened quality, rather than holding it back to resolve more bugs.  The quality factor is one of many factors weighed in the release decision.  Sometimes quality loses.

As testers, we have to be okay with this, with the caveat that it’s not okay for the product team to blame the testers for the quality level of the product.  While many of us have the misnomer of “quality assurance” in our job titles, we can’t assure the quality when the release and budget decisions are out of our hands.

image via Thomas Hawk; used under Creative Commons licensing