Archive for January, 2010

QA Jobs: The Coverletter

Interviewing and resume review is in full swing now. This is the first time I’ve been on this side of the table. It is hard to review the applications and remember how much care and hope I put in to each application I send off when I am job hunting.  Rejection is hard to get, but it is hard to give, too. What I have been surprised by, though, is that it is fairly easy to tell who has put thought into their application and who hasn’t.

The first things I look at are (I assume) pretty standard, but in a field like quality assurance, a well edited resume demonstrates an important skill.

1. Proofread. Please. I mean really, this is a QA position. If you don’t take the time to catch issues in something as personally important as a resume and cover letter, how thorough will you be when it is late and you are tired and you’ve been testing for 3 days?

2. Research. If you don’t know if you are writing to a woman or a man, do not guess. Go search online. Is there a linked in profile, a company profile, any search results mentioning the person? You should probably be going through some of that anyway. If you really can’t figure it out, you can call the company and ask who to whom you should address the letter.

3. Know what position you are applying for. Yes, that’s right. Don’t try to pass off a generic cover letter. When you only have a few paragraphs, irrelevant experience, broad goals and interests, and a detached tone are not really impressive. Those are one thing though, but people who apply but forget to change the job title, copy and paste from the job posting with out adding any context to it, or seem to not know what the job entails are just a waste of everyone’s time.

4. Double check your attachments. Actually, triple check. I got resumes with the wrong cover letter attached, missing attachments, or including corrupted or hard to read files. It is also a good idea to think about what you name your attachments.

5. If you are interested, act interested. You took the time to respond to the job posting, but you should appear interested in the job. I love questions, but when the cover letter is more a list of questions about what the position can do for you, it makes me wonder what exactly you are excited about.


Documentation on Agile Developement Teams

Agile Teams are all about flexibility, right? Rules evolve with the project, people’s suggestions can taken on, deadlines can be adjusted internally – and within that one week sprint, the team is pretty much free to set their own pace and schedule. Its great. It allows for creativity, changes in plans and new ideas. But sometimes, it seems like documents lose some importance.

I know, I know. People get tired of hearing QA whine about documentation. But there is a reason.  In a world where you are free to find your own way, it is good to have some idea where you are finding your way too – so that you- and your teammates – all end up at the same destination. Documents provide that overview, that roadmap. They also help others to follow you- either when making revisions in the future, or when testing the final output. No matter which development style your team follows, the importance of good documentation should not be lost.

In waterfall development, documents are turn by turn directions -carefully planned and harder to change. Agile developement needs the same directions, but the exact path can be filled in as you go. By the end of the project (by the time QA starts testing), Agile teams should sh0uld have produced the same kind of documentation that waterfall teams have.

But what about QA teams? How do you go about designing your test plan when you don’t know exactly how things are going to work yet? The documents won’t be ready in advance, which means you have to keep your plan flexible… agile. You should have a good idea of the final product, so you can plan your approach, your general tests, your schedule etc very early on. As documents are updated, update the test plan. This was a big adjustment for me, as I was used to knowing in advance what all will be done. But really, the philosophy is the same- you just work in phases right behind the developers. They finish a piece of functionality, you finish your test plan and test that piece while they start filling in the documents on the next piece. QA defiantly has an important place here – and keeping an eye on the requirements, performing ambiguity review at each stage and applying those to an agile test plan are all part of it.

Because with out requirements, development really is like that old elephant story. (An awesome version of which is reposted below from this website)

It was six men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.

The First approach’d the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
“God bless me! but the Elephant
Is very like a wall!”

The Second, feeling of the tusk,
Cried, -“Ho! what have we here
So very round and smooth and sharp?
To me ’tis mighty clear
This wonder of an Elephant
Is very like a spear!”

The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
“I see,” quoth he, “the Elephant
Is very like a snake!”

The Fourth reached out his eager hand,
And felt about the knee.
“What most this wondrous beast is like
Is mighty plain,” quoth he,
“‘Tis clear enough the Elephant
Is very like a tree!”

The Fifth, who chanced to touch the ear,
Said: “E’en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Elephant
Is very like a fan!”

The Sixth no sooner had begun
About the beast to grope,
Then, seizing on the swinging tail
That fell within his scope,
“I see,” quoth he, “the Elephant
Is very like a rope!”

And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!


So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!

QA jobs: resumes and interviews

I am currently hiring for a part time QA position and have been doing some research on other people’s experience on the process of resume screening and interviewing.I recently read a great post by Eric Jacobson on what a good QA resume looks like.

Here is a snippet from his blog:

“However, the candidate would have probably gotten an instant interview if they had included any of these:

  • My approach to testing is as follows…
  • See my software testing blog for my opinions on how to test.
  • My favorite testing books and blogs are…
  • I enjoy testing because…”
  • I think he makes a great point. It would be great to see some passion and originality come through in a resume. Even if people had  different philosophies on testing, it would be great to see someone who is thoughtful and interested in their work. Maybe the place for that is not in the resume, but in the cover letter? Coverletters are hard. Trying to be direct, knowledgeable about the company and passionate about your field in a few short paragraphs takes a lot of revision and editing. It is worth it though. Where better to get an idea of yourself as an employee and a person across to your potential employers?

    There is the interview- perhaps the best way to get a sense of someone’s interest in the work as well as their skill in it. Programs and languages can be learned, but the right thought process should be there in the first place. I have answered a lot of QA interview questions – good and bad and some just plain unoriginal. In my opinion, anyone can search for “top Microsoft interview questions”  or “Google interview questions” etc and come up with a list – but that doesn’t make them good. They aren’t all bad. I am not even saying you shouldn’t use some of them. I do advocate taking a moment to decide if they are right for your company, for the position you are interviewing for and for the specific interview you are doing before launching into a predetermined list of logic questions. “Why are manhole covers round?”  or “How many piano tuners are there in the US?” seema little cliche to me, at this point.  I’d kind of hope that the person I was interviewing had heard of it before. Some of those logic questions are fantastic though, and very well suited to QA.

    The best interview questions I’ve ever gotten?

    “Pretend you are writing a test plan for a vending machine. Describe what you would test, where your risk areas would be and who you would consider as your users.” It is relevant. It is just difficult enough to throw someone off in an interview, but not too difficult that they shouldn’t be able to recover. The answer will tell you a lot about how a person will approach testing and how they will problem solve.

    “Write reproduction steps for how to make an omlet.” – Want to know how someone will write bug repro steps? Ask this question. Are they detailed? Helpful? Easy to follow? It also lets you know how organized their mind is when pulling out reproduction steps on something they are very familiar with doing.

    “What is the best bug you have ever found?” (this seems to be fairly well known in the QA world and I have defiantly gotten it in an interview) They might not know one offhand. Thats fine. But can they talk to you about the types of bugs they find? Where do they look for bugs? Whats important to them when testing? Great question.

    “How much testing is enough?” Where do they draw the line between thorough testing and meeting deadlines?

    What do you guys think? What do you look for in a resume? What are the best interview questions you’ve ever gotten?

    Manual Testing Tips


    There are always more bugs to find.

    Don’t assume that you are trying to “break” the software- you aren’t. You are just trying to find out where it is already broken- and trust me, it is already broken, or you aren’t looking hard enough. You are literally hunting for bugs – so dont forget to be active in your pursuit of them.


    Consider what isn’t being tested elsewhere. What is the most common user flow? Where will people most likely run into problems or where would problems be the biggest deal?

    Test UI- really read through the text, even if you know what it should say. Is it clear? Edited? Understandable? Look at the pictures/images and alignment as though you were looking at them for the first time.

    What are your blind spots? Are there pieces of functionality that depend on other pieces? Could bugs be hidden one layer down in the functionality and simply be masked?


    Don’t test on autopilot. Really think about what you are doing. Really look, don’t just click around. Dont zone out while pages load or queries are returned, watch what is happening. Your eyes should always be evaluating the page.

    Limit Distractions – Turn off your music, Step away from the TV (if you are testing at home), Don’t chat with your coworker. Give your self concentrated bursts of time to really focus and test. (and take breaks between so that you don’t zone out).

    Test like a user. – You know how to work this page. You have read the documentation. Users haven’t (always). So assume you don’t know how to use it. In the end, you are responsible to the user- to ensure that they get a quality product.

    Litmus Review

    I’ve been using litmus app for about four months now. It allows you to view a web page on many different browsers/OS combination very easily. It also has some support for email viewing in different clients. Litmus helps to detect UI issues on configurations you don’t directly use for testing.

    The Good:

    support for email UI is nice- but limited

    You can be notified via IM or email when your tests are ready

    individual test cases can be rerun without waiting for all to execute again

    Simple and straightforward

    lots of browsers available for testing

    The Bad:

    no way to chose which version of the operating system you want to test on

    intermittent errors seem to occur because it doesnt wait for pages to load (even when you have selected allow extra time)

    emails sent automatically via a 3rd party cannot be checked, as you have to directly send an email to the address they provide.


    It is a good sanity check and reference for UI issues. It supports a lot of browsers and is very easy to use. Main browsers should defiantly still be checked manually, and Litmus needs to be reviewed (as with any automated test result) with a critical eye for tool failures. In all, a good app and an asset to the QA process.