Adventures in QA land
Over the last two months I have been doing nearly fulltime QA. That time is over now and I thought I would share a few thoughts. As always my thoughts are my own and not reflective of employer.
I won’t bury the lead and it also won’t come as a surprise. I wasn’t a fan of qa. Not because it is incredibly boring (it can be). Or because motivation is your biggest enemy (it was). But, because it is actually more difficult, and far less rewarding, than straight up development. The reward comes when nothing happens. You push your code to production, and best case scenario, after 3 weeks of busting your ass nothing happens. You breath out and look at next iterations stories.
At my company RideCharge, qa is much more than a click monkey. Manual testing is only 1/3 of the effort, it is the worst part but not difficult. The position is difficult because of the responsibilities. An ideal QA person is responsible for understanding all the stories in the iteration with little, or no, detail. Evaluating both the business and technical requirements. Running the release (”is everything checked into the branch?”). Being a bit of a hard ass about process. And juggling emergency-releases. Whew!
It seems like there is a trend in the industry to cut QA and let force the developers take that responsibility. I don’t know if this sucks or not. But I can definitely understand it. If it were just manual testing or release management, I think it would be easier to find someone for a price your company can justify. But these two roles are different, and I can’t tell you the personality traits you would need to enjoy both.
That being said, I don’t think I could do either job fulltime. I am a carer (one who cares about doing a great job) about software. I know I am capable of delivering quality software. But I even found myself becoming apathetic about the importance of bugs (”we can launch with that”). And you really have to force yourself to test something for the 4th time, even though you have opened and reopened the bug 3 times already (”it’s gotta work this time”).
There are some special challenges developers face when switching to QA. Especially when you are very familiar with the code base you are testing. It is tempting to look at the code and evaluate how much to test based on the relative size of the change. The problem with that approach is it completely breaks black box testing (I know more than I should). I am mixed on this, because when I did that I would find bugs quicker. But on the other hand some of the more subtle bugs would slip by. So, it makes sense to have someone familiar with the code look over every commit, right? Well, not really. That person is just an asshole and whether or not it is their job they will be despised.
At the end of it all I feel no closer to a solution I think will provide the higher quality code. So, what’s the point of the blog post? I guess, given my thoughts I wonder if anyone has any ideas or books that changed the way they thought about QA, I would love to hear them. Also, if this post hasn’t scared you away my company RideCharge is looking for a senior QA person. I think you know what the job entails if you read the post. I believe it can be very challenging and rewarding for the right personality type (I just don’t know who you are).
