Testers and Developers at Fog Creek Software

Joel Spolsky is hiring a Tester.  See: http://www.fogcreek.com/Jobs/QA.html 

As he often does, he expounds a bit on his ideas behind the role on his terrific "Joel on Software" site (http://www.joelonsoftware.com/items/2010/01/26.html), before he leads the reader to the ad for that particular job.

Joel seems to believe that one part of a tester's role is to boost the morale of developers.  He says "Believe it or not, one of the most valuable features of a tester is providing positive reinforcement."  I have to say that I've never heard that expressed before, and I can't say that I agree.  While I do want my testers to be professional, and enthusiastic about the company and their job, I really don't want my testers concerned with programmer morale.  What if programmer morale starts to dip?  Should we blame the testers?

Joel also seems to see some sort of connection between liking puzzles and testing.  I hear this from lots of folks, mostly from those who aren't testers but also from some who are, and I remain skeptical.  I've never seen any real correlation between puzzle-playing affinity and testing.  I've seen great testers who dislike puzzles.  And I've seen fanatic puzzlers who make terrible testers.  I wonder if he asks Microsoft-style puzzles during interviews?

I also noticed that he is hiring a Software Developer as well.  See: http://www.fogcreek.com/Jobs/Dev.html

The two job ads make for an interesting contrast.

For the tester role

• no experience is necessary
• they require intelligence and curiosity
• they require a track record of success.  By that they mean "a bachelor's degree with top grades"
• they require a scientific approach and unusual attention to detail
• the applicant must love a good puzzle
• the applicant must like to think about things methodically
• the applicant must generally like working with software and computers

While for the developer role

• the applicant must be able to "master any technology, language, or development environment"
• they require incredible coding skills
• the applicant must be described by friends and coworkers as an "animal"
• the applicant must have a continuous string of successful projects

So testers don't need any experience, but they must love good puzzles?  And developers must have experience, but apparently don't need to love puzzles (good or bad)?  Seems odd to me.

Oh, and presumably Fog Creek Software wants to attract the kind of no-experience tester that likes to point out flaws in their corporate website.  The ad for the Tester is sprinkled with typos like

• no necessary, rather than not necessary
• you`ve
• and and
• moral, rather than morale
• ıt, instead of it
• va1uable
• etc.

Clearly this was intentional, since similar flaws are not present in the ad for the Developer.  While I suspect it would be rather off-putting for a professional QAer or Developer, perhaps this tactic is actually exciting to someone with no experience?

So, if you want to apply for this job - go solve some puzzles, proofread their website carefully, and study up on the best ways to improve someone else's morale.  I hear that a good backrub, a nice cup of hot tea and a pep talk can work wonders!  Experience is no necessary.

---

And if Fog Creek really wants to raise the morale of their programmers, perhaps they should just hire a consultant?
http://www.dilbert.com/fast/2010-02-01/

---

QA Q and A - Bug Triage

QA

Q&A

Question:  What is a Bug Triage?

Answer:  A meeting or discussion focused on an item-by-item review of every active bug reported against the system under test.  During this review, fix dates can be assigned, insignificant bugs can be deferred, and project management can assess the progress of the development process.  [R. Black]

In medicine, Triage is the process of prioritizing patients based on the severity of their condition, rationing patient treatment efficiently when there are insufficient resources for everyone to be treated immediately. 

The term dates back to World War I where French doctors treated battlefield wounded at stations near the front.  At its basic, triage aims to divide the wounded into three categories:

• Those who are likely to live, no matter what care they receive
• Those who are likely to die, no matter what care they receive
• Those for whom immediate care might make a positive difference in outcome

In software, Bug Triage is a way to allocate your scarce debugging, development, and testing resources among all open bugs so that your time is spent in ways that can most positively benefit the project.

During a Bug Triage Meeting, representatives from Project Management, Development, Testing, Support, and other areas gather and discuss the remaining open bugs.  Usually, the team attempts to:

• Note which bugs do not need to be fixed at all, perhaps because there will be no end-user impact
• Note which bugs can be fixed in at a later release (deferred)
• Note which bugs must be fixed immediately, perhaps because they are blocking further testing or demos
• Note which bugs must be fixed for this release, but not immediately

One of the key questions I like to ask about a bug during triage is "Would you be willing to delay the release until this bug is fixed?" copyrightjoestrazzere

To make a Bug Triage Meeting run effectively, the team should either come to the discussion with an understanding of the bugs which will be discussed, or a discussion about the bugs, their context, and associated risks should occur duing the meeting itself.

Often Bug Triage Meetings will only commence during that latter stages of a release, when all features have been delivered, and only bugs remain.  Depending on the nature of the release, the schedule, and the people involved, these meetings might take place weekly, or even daily.

Usually, the only topics open for discussion during a Bug Triage are:

• Should this bug be fixed at all?
• Should this bug be fixed now, or can it wait until later?
• If later, must the bug be fixed during this release, or can it wait until some future release?
• What is the relative priority of this bug versus other bugs?

Topics that should not be open for discussion during Bug Triage usually include:

• Blame for how the bug occurred, or why it wasn't discovered sooner
• Discussion of the overall architecture
• Debugging or redesigning
• Rescheduling of the release

Some teams consider it necessary to estimate in the Bug Triage Meeting how long it will take to fix a particular bug.  But some teams don't consider this estimate a valid discussion topic during the meeting itself.  I personally favor leaving this estimation out of the meeting.

Many teams will update the bug reports themselves either during the Bug Triage meeting, or immediately afterwards - adding the outcome of the Bug Triage decisions into the bug report, and chaning the bug's Status and Priority accordingly.

For other QA and Testing Terms, see: http://strazzere.blogspot.com/2010/04/glossary-of-testing-terms.html

---