Avoid Zombie Attack!

December 10, 2008

This is mostly for testing purposes (I think I’ve done this before, actually). So, I’m using my testing blog to test something. Ha! How ab0ut that?

Great. Except it didn’t work. Annoying.

Let’s try again:


Fakes and Poseurs

October 27, 2008

While I’ve mostly given up posting regularly on QA (just too burned out at the moment), every now and then I see something that I just HAVE to share or respond to. This post on Pradeep Soundararajan’s blog, “Tester Tested!” was that thing for me today. It was posted at the end of August but the discussion, via the comments, has continued into this month. In short, it is enlightening, infuriating, and full of “ah-ha! been there, done that” moments.

God bless Pradeep. He seems to take a lot of flack from people who don’t see anything wrong with a person putting fake experience on their resume in an effort to get a job in QA. Seriously, what the hell is wrong with people like that? Pradeep alludes to the common misconception that testing is the “easy” job in IT, and if you don’t have any coding skills you can always get a ticket on the IT money train by becoming a tester. So, so false, as those of us working and practicing real software testing know. Whatever their reasons for choosing testing jobs in particular, I have seen the ugly fallout from poseurs like this infecting the workplace.

While the post deals with testers (or faux-testers) from India in particular, I have seen this “fake experience” disease in all manner of testers, whether they are immigrants or natural-born US citizens. Ignorance knows no nationality you see, and anyone can be an opportunistic, lying scumbag on a resume.

I’ve also dealt first-hand with more than one person who had someone else (fluent in English) write his resume and all of his follow-up correspondence when interviewing for a job. Once hired, and expected to compose test plans, short test cases, or even simple emails on his own, his writing was suddenly completely unintelligible. Or the person who sold herself as a “test manager,” inflating and fabricating experience on her resume, but once hired it turned out she not only didn’t know how to manage testers or the testing process, but she didn’t know the first thing about testing. Asked to create simple documents like a work breakdown structure or a test schedule, she was clueless. Given a straightforward set of test cases to follow, she was quickly lost and unable to complete them, much less to actually identify any defects. About the only thing she WAS good at was taking credit for the work of others, a skill she obviously put to good use on her (faked) resume and in (bluffed) interviews.

It does tend to make you angry and bitter, to see situations like this. Talk about agile testing or exploratory testing or new tools or methods all you want; this is one of the reasons I think hiring is the biggest challenge we face in the testing field today. In my personal opinion, I can teach a new tester how to use a tool, but I can’t teach a liar how to be honest.


Process What?

October 13, 2008

What is process improvement, and why should you care? Assuming you are a software tester, you’ll end up caring a lot. Especially when you get stuck on a job where there is no process and no improvement on the horizon! Ha ha, I can laugh now, but I’ve had that job too. Not for long – but I had it.

Here’s some purely anecdotal evidence for you, gleaned from my own experience. Most software developers think “process improvement” are dirty words and they dread being told that their shop is about to start going by this model or that process. Testers, on the other hand, tend to be much more open to the ideas of process improvement. Why is that?

I think it’s easy to figure out. Testers and other downstream folks like technical writers and even people who do implementations, customer service, and maintenance really feel the worst pain caused by a lack of process further upstream where the development actually takes place. That doesn’t mean that testers are going to thrive when forced to use big, heavy models with lots of documentation requirements. Remember, testers write a lot of documentation, and sometimes process can be as much of a drain on them as it is on developers.

The best process is one that solves a problem. For example: your requirements are unclear, which causes a problem for the developers (they aren’t sure exactly what to code) and the testers (they aren’t sure how to test what does get coded). Fuzzy requirements are causing problems. The solution is to elicit and document better requirements, and the best way to do that is to have a consistent requirements-gathering process that everyone is familiar with.

Here’s the key point, I think, on process improvement. Process models won’t tell you WHAT your requirements-gathering process should be, only that you need one. That leaves a lot of flexibility! Perfect! So in a large organization that’s developing some giant aerospace program, the process can look like: a team of people gathers requirements using a template, and they are vetted through another team, using certain organizational standards. Then they all get recorded and double-checked in a big tool, then perhaps modeled in some way, and so forth. On the other hand, a small team developing a lean web application have a process that looks like: one person always interviews the customer and gets the requirements. That person makes sure that any requirements given include certain essential information that’s needed for effective use (the requirements have their own requirements, if you will). If there’s any ambiguity, the requirements person goes back to the customer for clarification. Then the requirements get documented (perhaps in a spreadsheet) and reviewed with the team members regularly to make sure everyone understands them. Both processes have the same goal: clear, usable requirements. But they couldn’t be more different in scale and practice.

The whole point is having a process in the first place, instead of doing it differently for every project, or every customer, or every phase, or even every requirement. You can easily see where that lack of process will result in chaos, and that’s not fun for anyone.


The Horror…

October 8, 2008

Let me start by saying yes – it’s been over a month since I posted here. Frankly, I haven’t been feeling very inspired about QA lately. It’s possible I may give up this blog all together. (I still have a personal, non-QA blog and a “mommy blog” that I post to pretty regularly. Email me if you’d like links.) But I did see something yesterday that I had to mention.

I read a post yesterday about excuses that testers often use for not finding bugs. Frankly, I thought it was horrible, and I’m not going to even link to it here, but if you read Testing Reflections, you saw it. I’m not going to address the content of the post, really, though I will mention I thought it was mostly asinine. No, what horrified me most about this particular post was the atrocious grammar, spelling, and punctuation. Or perhaps I should say lack of grammar, spelling, and punctuation. It was, quite possibly, the most poorly written thing I’ve ever seen that was supposed to have been written by a professional in the field of quality. Do you see the irony?

It is probable that the author of that post is not a native speaker of English. NO EXCUSE! That is not, and has never been, a valid excuse for publishing a piece of writing that is so poorly executed it’s nearly unreadable. We’re not talking about an internal email among colleagues (although I personally would find that just as annoying), this was a published post on a blog about quality. If you don’t feel your grasp of English is sufficient, have someone proofread and copy edit for you. How can anyone take you seriously, writing on a topic related to quality, when the quality of your own effort is so obviously shoddy? When you apparently did not care enough to either look up the correct spellings, grammatical usage, etc. yourself; or get someone else to do it for you if you are not competent enough?

If you didn’t see the blog post in question, do yourself a favor – just take my word for it. It was truly a piece of crap. Don’t try to find it and read it yourself, because it will make you want to stab your own eyes out with a rusty fork. Reading it is like listening to fingernails on a chalkboard, with a migraine, and a hangover, while someone blows cigar smoke in your face. Please spare yourself the frustration.


Google Chrome

September 2, 2008

I just read through this very clever comic book explaining Google’s new browser, which they’re releasing tomorrow. I have to say, it was VERY effective – both in explaining to me what makes Chrome different, and in getting me excited about trying out Chrome! Sadly, my corporate overlords will probably prevent me from installing Chrome at work for the foreseeable future (they haven’t even approved Firefox 3 yet). But I can certainly beat the heck out of it at home!

Another reason I loved this comic book thing was all the great information that’s included for just about every tech audience. Specifically, there was some really interesting information about the QA efforts on Chrome, and how the team uses automated and manual testing, how they select their test data set, and what their goals are for testing Chrome.

Wow! I’m really getting geeked up for Google Chrome! Hmm…I better bring my Macbook Pro to work with me tomorrow…


Take The Survey

July 29, 2008

A List Apart is running their annual survey “for people who make websites.” Back when I started in software testing, very little of what I did had much to do with websites or web applications. Now it’s 99.99% of what I deal with on a daily basis. In fact, the only time in the past two years that I’ve worked on anything other than a website or web app, it was a mobile app on cell phones!

Anyway, if you’re involved in the web in just about any way at all (designer, developer, blogger, tester, manager), be sure to take the survey.


Let People Subscribe to Your Feed

July 17, 2008

RSS buttonThis post isn’t about QA in the strictest sense, though you could argue it touches on the ideas of usability and user experience, which are things I often have to test for. It also deals with one of my pet peeves, which makes it fair game for my own blog. That peeve is this: people who don’t make a subscribe option obvious for their own blogs. If you have a blog, there is one commandment you must, MUST follow: allow people to subscribe. I would even go so far as to say make it easy for them to subscribe. To take it even further, please syndicate your full content and not just lame two-sentence snippets or (God forbid) post titles only, but I understand that’s harder for people to come to grips with.

Back to allowing for easy subscription, let me point you to some examples. If you’re reading this blog through a feed reader – good for you. If you wouldn’t mind, click through (usually on the post title) to hit the actual website where this feed comes from. If you’re reading on the website already, keep going. Notice in the upper right corner of the page, there’s a button that looks much like the one at the beginning of this post. That’s the universal symbol for syndicated content. That means you can easily click on it and see the RSS (or atom, or whatever) feed for the blog, and then subscribe to it with your reader of choice. I went one step farther and even put a text link next to the button, which wasn’t strictly necessary, but I like to make things obvious.

Now, let’s look at some other sites that I really like, but unfortunately do not make it easy for the reader to subscribe, if she can subscribe at all.

What Liz Said. Here’s an awesome blog with an impressive amount of content, the kind of feed I’d LOVE to sink my teeth into. But look up and down the page. Go ahead – it’s long, but I’ll wait. Notice she’s got all kinds of awesome widgets going – recent posts, recent comments, tags, currently reading, etc., etc. What’s missing? Any kind of subscription option, that’s what! Luckily there’s a workaround. Most blogging software will automatically generate a feed for you, even if you choose not to publicize it (of course if you’re serious about this stuff then you want to use Feedburner, but that’s another post). When I can’t find a feed link anywhere on a blog’s front page (or supporting pages), I append one of the following to the URL: /feed, /rss, /rss.xml, /atom, /atom.xml. Eventually you an usually find a feed that way, and that’s how I was able to add the feed for “What Liz Said” to my Google Reader.

Why I Hate DC. A snarky local blog that I have enjoyed reading for over a year now, Why I Hate DC was recently turned over to a new editor/writer, after the previous one moved to Columbus, Ohio (ironically, I moved from here from Columbus). So far she hasn’t made many changes, which is unfortunate. I think the page design is kind of outdated, though I can live with it, but what annoys me most, of course, is the fact that the subscribe option is, again, hidden. No button or link is apparent, and you have to do the sneaky “append /atom.xml” trick to get it. Compounding the irritation, once you do subscribe to this feed, it’s one of those annoyingly truncated ones, so you still have to click through to the site to read a full post. But at least it lets me know if there’s anything up there I’m interested in on any given day.

The Art of the Title Sequence. “Art of the Title…” is a reformed candidate, because it now offers a feed! HURRAY! In fact, easy-to-find links to both web and iTunes feeds are now posted, right at the top of the page. This is one of my most favorite sites/blogs, and I could spend hours just browsing the archives. And now there’s a feed, so I don’t have to click back every few days to see if something new has been posted. WIN.

So remember: if you blog, syndicate. For more technical information about RSS, see this Wikipedia article.