Our most complex AUT has no shortage of production bugs. They’re discovered almost daily and our support team forwards them to the rest of the team. These bugs get reported with little factual detail and it’s up to a BA, Dev, or Tester to figure out the repro steps.

Our informal process is, the first person to reply saying “I’m on it” owns the issue and gets to be the hero who figures it out. Determining the elusive repro steps combines many skills; interviewing oracles, listening to users, acting like users, pulling audit trails from the DB using SQL, examining artifacts like user screen captures and error log files, and tracking down user stories or requirements.

Last week one of my testers stopped by my cube, grinning ear-to-ear, and said “I’m so excited! I just figured out the repro steps!” (to a really really challenging prod bug). She sent her repro steps out to the team, they were correct, and within minutes she was thanked and declared a rock star by various team members.

Determining the exact minimum repro steps, is there anything more exciting for a tester?

…well, hopefully. But cracking repro steps is pretty darn exciting!

The above question was asked in response to my Do Developers Make Good Testers? post. Since I am in the process of hiring another tester I thought I would take a stab at it. These are qualities for a fairly generic software testing position.

A good software tester…

• Constantly asks, “What is the best test I can execute right now”.
• Can log unambiguous bugs with clear repro steps that make the main problem obvious with few words.
  
• Is not distracted by their understanding of developer decisions. Just because the tester may understand certain technology constraints motivating dev solutions, the tester’s mission is never to defend the AUT (see my post, What We Can Learn From Dumb Testers). It is to communicate how the AUT currently works, in areas that matter right now.
• Has the capacity to understand the stakeholders’ business.
• Is technical enough to see how one component of a system affects the entire system.
• Has keen problem solving skills. They can control multiple variables until locating the problematic variable. They have just enough persistence without having too much. They know when to quit and move on.
• Is an expert communicator and listener who demands complete understanding.
• Is humble enough to ask all questions (even stupid ones) but cynical enough to seek answers from multiple sources (trust but verify).
• Is organized enough to follow through with tasks, while at the same time noting potential future tasks.
• Is capable of isolating observed software behavior, within an ocean of dependencies and communicating those behaviors to the team. They can look at components of an incomplete system and determine actual pros and cons by imagining the complete system.
• Respects fellow developers and BAs. Understands the harder the tester works, the better the developers/BAs look.
  
• Is enthusiastic when finding pre-production bugs but depressed when users find post-production bugs.
• Can handle stressful deadlines, make quick decisions, and give up preferred processes for those that ultimately are in the stakeholders' best interest.
• Is an active participant in the software tester community, reads testing books/blogs, and participates in local test groups.
• Has good work ethic; can meet deadlines or communicate they will be missed, works more than 40 hour weeks when necessary, is organized and professional, cares about the team’s success, honest, follows mandatory work procedures, is SOX compliant, etc.
  

I have an open headcount for the highest level tester position at my company. We are hoping to get someone with test automation skills. Most of the candidates are making me yawn. Few are enthusiastic enough to have read anything about their own craft, and fewer are interested in deep discussions.

One resume that grabbed my interest was from a career developer that claims to want to try her hand at being a tester. She is mainly interested in writing test automation code...but she never has. Prior to an interview, my devs and I were enthusiastic. Afterwards, we realized this candidate had no testing experience (other than experimenting with unit tests) and most feared our team could end up with a good developer but a weak test automation stack instead of a good tester who could provide instant gratification via sapient UI tests.

A dev wanting to cross over... How rare of a thing is this? Am I missing a great opportunity by not hiring the dev? Or is this a dev that just couldn’t cut it as an application developer…hoping to cut it as a test automation developer?

I can’t help but wonder, is it easier to teach a developer how to be a good test automator or to teach a good manual tester how to be a good test automator?