Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

QA: A Hillbilly Love Story

The hillbilly turned forty last weekend! I’ve been anticipating this giddily because now, I can be crotchety and people will still find me adorable.

I hate QA. Hate, hate, hate, HATE, HATE, HATE it. I despise it so much, I think I might swear. Here goes….I f—, okay, I can’t do it but I still &*%$ hate it.

Side note: I know all QA people weren’t raised by trolls and/or gnomes but I’m going to generalize here. If you are a QA person and were raised by evil leprechauns, please don’t take offense.

As a hillbilly, I’m an innately optimistic and forgiving person. An ugly codebase to me is a sea of opportunity. Changing requirements? Ha! I can put my OCD up against any client. I can see the positive in almost anything. Except the emotional rollercoaster that is QA.

The end of an iteration is a time of celebration and relief for me. We’ve completed a significant piece of functionality on our application. We’ve followed best practices, left the code in a better state than when we started, and all our unit and UI tests are passing (more or less). Despite my past experience, I always feel great pride when I email our QA department:

Hey there, QA folkery! I come bearing tidings of great joy! We have a new version of the application for your revelry and astonishment! You will surely faint in awe at the sheer glory of it! I await your token sign-off. Acclaim and praise is optional (but recommended).

After that, I sit quietly for a few minutes to bask in my accomplishment of the last couple of weeks then dive into the next iteration, the previous one long since gone from the vestiges of my memory by that point.

The inevitable spartan response:

Please fix the following issues:

  • As per the spec, emails should be sent every hour, not daily
  • I got a 404 error when I went to the public booking URL
  • I know this wasn’t part of the iteration but we should display a message when someone confirms an appointment. Can you include this?
  • You spelled it “cancelled” in the settings screen but “canceled” on the calendar.

Let me know when a new version is up for testing.

By now you will not be surprised when I tell you that the QA process was invented by the Marquis de Sade.

QA goblins: surely you see my point, no? The iteration is over. Done. Finished. There’s no “D.S. al fine” at the end. In my head, I’ve moved on to new functionality. I’ve got tests written and prototypes completed. And you want me to forcibly re-enter the past?!? All the hard problems from that iteration have already been solved. I don’t care about your “cosmetics” or your “functionality”. That new feature you’ve requested? It’s KILLER! It’ll be a great asset to the app. When I get around to it. That 404 error? Just a configuration issue. It’ll be fixed when we deploy. And come on, spelling mistakes? Have you not been on Facebook lately?

In short: I. Don’t. Want. To. Do. It. Right. Now.

And I have to. Virtually everything brought up in a good QA process is valid from bugs to cosmetic issues to features that we need to include this iteration even though they weren’t in the list. Without them, we don’t have a usable product. Users will complain or worse, move on to something else. But my headspace is somewhere else. I’ve already compartmentalized the new features and have shifted my own personal Eye of Sauron on them. Now, there’s leakage that I thought I’d never have to deal with again.

Another psychological issue: I’ve poured everything I’ve got to deliver the best that I’ve got and it wasn’t good enough. It’s never good enough. I’ve just presented to you the end result of four years of university training and over a dozen years of experience as an “expert in the field”. And with a few phrases, you send me slinking back to my computer to do it over again.

It’s a little strange in some regard. I welcome criticism of my coding choices and style. I actively seek it out sometimes. Even code reviews can be made fun again. But something about the subtly adversarial nature of QA raises my dander. The fact that it’s so essential to quality and that I can’t think of an effective way around it doesn’t help…

So to sum up:

  • QA forces me to change my headspace. And I hate it for that.
  • QA points out my flaws as a developer. And I hate it for that.
  • QA is necessary and makes software better. And I hate it most of all for that.

To end on a more positive note, most QA people (including those that do it as part of other duties) I’ve worked with are extremely nice. There’s no accusatory tone in the responses, no blame on messing things up, and no sense of “you’ve *really* screwed things up this time.” In their minds, they’ve done what’s expected and like me, have made the product better for it.

But I still hate you.

Kyle the Unadulterated

This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    this hillbilly love story is quite funny and trust me its really somewhat interesting to teenagers like us 😉 funny facebook statuses

  • http://yourarticlewritingservice.com/prices.html seo article writing

    I have got some useful information from this site. Thanks for this type of blog. Want you will continue to post same in future.

  • smith farnandas

    effort and estimates would Real Estate Website be part of the iteration.

  • Brian

    *Love* the concepts of headspace and the shifting of the internal Eye of Sauron to the next phase…so true.

  • http://www.seolinksource.com/ SEO Plainfield

    !! great story, I also hate Question and Answer if you need to know about SEO Plainfield then search it through google. 😀

  • http://www.aspiredesigns.com.sg/ website design firm

    nice story u made

  • Dan

    love it,

     it’s so true!

  • http://kyle.baley.org Kyle Baley


    A new version of the post is available for your review. Please, please, *please* provide a detailed critique of every nuance and respond when it is least convenient for me to take action.


  • http://kyle.baley.org Kyle Baley

    Agreed. I was going to comment on this but it broke up the flow of the thing. Our reality is that we’re still a start-up and QA resources are *very* limited. A “continuous” QA person is an ideal we’re still striving for. At the moment, it’s my partner-in-crime/company founder doing the dirty work. And truth be told, I suspect having to change his mindset from high-level company planning to low-level “does the app still work?” every couple of weeks probably isn’t a piece o’ raccoon for him either. But we’re sticklers for user experience and as such place a great deal of emphasis on QA. So our compromise has been to do it in a more traditional sense, at the end of the iteration. 

  • http://twitter.com/davidadsit David Adsit

    +1 to Mike’s comment. When you make QA part of the current sprint rather than something for the next sprint, you can avoid most of these problems and release a better product each sprint.
    If you wonder what QA is supposed to do at the beginning of the sprint before you have any new features ready, there are always more tests to automate and if they are really sharp, the QA people and the BAs will work together to create automated acceptance tests that make your job oh so much easier. You will know you are done because the acceptance tests pass.

  • http://murrayon.net/ Mike Murray

    One mindshift we had to force ourselves through when switching to an interative dev cycle was to deliver to QA often throughout the iteration, and not just at the end. QA effort and estimates would be part of the iteration. QA sign-off and deployment was to happen before we could claim the iteration was finished. We quickly found that handing off dev work to QA at iteration end and wiping our hands of it was not going to work for very long.

    Great post, enjoyed the chuckles. Certainly been there before.

  • David Martin

    Please fix the following issues:
      * Verb tense in next to last sentence is incorrect –  “screwing” should be “screwed”.

    Let me know when a new version is up for reading.

    Nailed it.  Loved it.