They want to hire good testers
Developers want to hire testers. Testers want to hire testers.
What common and what opposite would we find comparing their requirements?
Tester Side RequirementsRepresented by Eric Jacobson’s blog post “Who Is A Good Tester?” (original grammar and syntax retained)
|
Developer Side RequirementsRepresented by StackOverflow discussion “Tips for hiring good testers?” (original grammar and syntax retained) |
| Can log unambiguous bugs with clear repro steps that make the main problem obvious with few words. | At a minimum, here’s what I need as a developer to effectively do my job:
1) Software version (and build number) where the bug occurred 2) Description of the bug 3) Detailed list of steps to reproduce the bug. Bad QA people won’t even provide #3 or will give you such vague information that it’s not at all helpful and sometimes it’s so bad that you don’t even know what the hell they’re talking about. You almost always wind up talking to a bad QA person several times before you can even start working on the bug. Good QA people will provide adequate information so that the developer can reproduce the bug without having to even talk to the person who filed the bug report. Great QA people will go the extra mile and try to really nail down the bug for you by trying alternate paths to the bug until they come to a very specific cause of it. |
| 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. | Find the ones that want to know how things work. They will be willing to let their minds turn and come up with creative ways to break your stuff. If they can answer questions pertaining to how things work they are probably fit for such a task. |
| Has the capacity to understand the stakeholders’ business. | Get an understanding of the types of applications they’ve tested in the past and ask questions about the apps.
A tester that really gets into the apps s/he is testing will Probably do the same for you. If their experience is in testing desktop apps, and you’re producing web apps, or vice-versa, think about the nuances that are unique (web apps: back button, browser differences, font settings, etc., etc.; desktop apps: installation processes, hardware configs, etc.) and try to see if they understand the differences and are ready to adapt if necessary. |
| Is technical enough to see how one component of a system affects the entire system. | Technical knowledge is a good to have for a QA person. He has to understand the working of an application from a much wider prospective than a developer, who would most of the time be restricted to his own component. The ability to develop small hacks and a perceived sense of knowing what can go wrong in a given component. |
| Has keen problem solving skills. | |
| Is an expert communicator and listener who demands complete understanding. | Communication skills, testers spend much time communicating bugs |
| Is humble enough to ask all questions (even stupid ones) but cynical enough to seek answers from multiple sources (trust but verify). | A tester should have the ability to ask questions. He should be curious to know what and why and also get to the how.He should not assume things, as once he does start assuming things, his ability as a tester goes down. |
| 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. | Great testers provide relevant contextual information that helps developers fix the bug. Many bugs are trivial to fix once the developer knows where to look. A few minutes of diagnostic work by a competent tester can go a long way toward this.
E.g., if your team is building a web application, hire testers who are capable of using a Javascript debugger, know how to check web server logs, and can access the version control change set where the defect appeared, etc. In many cases the source of a defect will be transparent even to non-dev testers when they look at this info. Including the relevant bits in the defect report can save lots of time for a developer. |
| Respects fellow developers and BAs. Understands the harder the tester works, the better the developers/BAs look.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. | If you’ve worked with effective testers in the past, you have some idea of the personality attributes you are looking for.
Use your own judgment to evaluate this. Weight it more heavily than technical competency when making your hire decision.You can train for technical competency. Personality is another matter. You interview for this by asking the candidate a series of open-ended questions and giving him or her a chance to speak at length on some subject that they should be familiar with. Ask about interactions with former co-workers, bosses, customers, etc. |
| 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. | |
| Give the potential tester an application (user interface, command line, whatever you usually work with) and a test case. Now, not just any test case, take a badly written, vague, maybe partially incomprehensive test case.
Tell the potential tester to roll up the sleeves.What I would expect is constructive criticism towards the test case. For test report credibility the biggest holes in the test case should be filled with something (either offering to edit the test case, or describing the executed tests in a test report). The tester should also sport some creativity in steps that call for “try different variables”. |
|
| Experience with automation tools, and the judgment of when to use them. | |
| What tools have they used in the past to track bugs and communicate with programmers and/or management?Can they express how much of the testing job is complete, how much remains, and the risks to the plan? | |
| Ask him or her to propose tests but not for the application. Ask for possible tests for a ball pen (or something else, commonly known yet not related to software). Very simple, yet checks if she or he can be creative, how they approach the problem.
Can he or she show some constructive criticism in the way they think? Is candidate ready to jump on this level of abstraction? Do proposed test cases make sense? Good tester should think of at least 20 tests without big problems (unless they can’t handle stress of job interview). Additionally ask candidate to organize those tests in test suits. How he would group them? What tests should be performed more often than others? This way you will know if he can he bring some value regardless of technology he will need to face. |
Summary
Bug reports
Most developers agree very strongly with the importance of detailed bug reporting. Ideally, they would expect tester to perform an investigation in front-end and back-end to pinpoint the problem.
Domain knowledge
Domain knowledge is valuable but not considered critical. Ability to learn through communication and hands-on investigation is considered more important.
Technical knowledge
Technical knowledge is considered important in the context of investigation, exploration, troubleshooting, learning how systems work in order to find their weaknesses more effectively.
Communication
Communication abilities are considered critical. Developers welcome questioning testers, and glad to tell them how systems work. Developers also acknowledge stressful aspects of testing work and expect testers to be able to deal with it.
Organization
Organizational, planning and multitasking skills are slightly overlooked by developers. Probably, that’s why they wonder why testing takes so long time.
Emotions
Here is where developers did not mention anything. Although they expect testers to be very inquisitive and enjoy breaking programs, they didn’t express expectations about testers being emotional about missed bugs.
Critical thinking
Critical thinking, not strongly mentioned on testers’ side of expectations, is multiple times demanded from developers’ side.
What I want to add
First of all, Eric Jacobson did a great work putting it all together. More importantly, he avoided using such a formal definitions like “attention to detail”, “thinking outside of the box”, etc. – but provided detailed examples of desired behavior or skills. That’s where recruiters should do their matching.
2 responses to "They want to hire good testers"
Please send me interview questions
[Albert’s reply: Google? :) ]
This was a well thought documentation; you have covered a lot of points here.