Provided you are ready to hire your first (or next) QA team member, what are the key properties of a person you will pay attention to?
-
Well, it depends on tasks I'm going to assign to her or him. So there is no final answer for your question.– dzieciouCommented Dec 26, 2013 at 10:06
-
Someone who can precisely see and can express customer's concerns effectively over product quality.– Vishal AggarwalCommented Jan 25, 2018 at 1:42
-
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review– Bharat Mane ♦Commented Feb 15, 2018 at 7:07
16 Answers
- Testing aptitude
- Willingness to ask questions
- Ability to negotiate
- Technical ability (reading and writing code)
- Strong communication skills
- Curiosity
- Tenaciousness
-
Hehe... a bit goes a long way. It is important to be willing to dig in and fight for something important but if you end up doing it for everything it can be over done easily. ;) Commented May 3, 2011 at 20:29
-
3Am I the only one who sees "stubborn" as not necessarily a positive thing? Commented Jun 10, 2011 at 16:34
-
@Joe - true it can be overdone... but I do want someone that is willing to dig in a bit and fight for something if it needs to be done. It can be taken to the point of being obstinent and obnoxious. Commented Jun 10, 2011 at 18:26
-
2
-
3What about "attention to detail"? I think it's quite important. Commented Nov 30, 2013 at 1:35
The tl;dr:
- Technical Acumen
- Communication
- Diplomacy
- Curiosity
- Drive
I've always felt that technical skill was one of the more vastly overrated attributes of test engineers. Certainly having technical acumen is critical to executing tasks, working with product managers and software engineers but it's only a portion of the actual job. Again, I'm not saying that you want test engineers that can't be technical but I am saying that it's only a part of what I've always viewed as a successful tester.
In my experience communication skills and diplomacy are some of the most critical skills a test engineer can have. When a tester finds a bug the real trick isn't the replication, really it's being able to communicate the failure cases to the development team and the impact to the product team. If you can't communicate to either of those groups you're not getting the result that you were hired for.
The "works on my machine" statement is the primary reason you need to have a tester that is diplomatic when they find bugs, write up bugs and lobby for their correction. It's a daily challenge working with Software Engineers and the really effective testers know when to be diplomatic in their interactions.
If you aren't curious about your system then you're not going to find all the bugs. Curiosity is one of the critical attributes to being a tester. The more curious you are, the more likely you will be able to ferret out the edge cases that your uses are going to find anyway.
Lastly, I look for my test engineers to have a lot of independent drive. I want my test engineers to be interested in different languages, frameworks and approaches. In fact, I challenge them to challenge the status quo that they work within so that we can improve our culture and tools.
-
+1 for diplomacy. Nobody likes people pointing out what is wrong with what they have done. It also helps a healthy relationship with the developers, and someone who says "I see what I can do to help the developers" before "I found a mistake in the developers' work" will go further. Commented Jun 10, 2011 at 12:50
-
+1 for diplomacy ... a poisonous atmosphere can easily spread throughout an organisation due to an unecessarily combatative relationship between the dev team and the qa team. Commented Oct 26, 2011 at 1:17
Adding on to the above answers:
- Does not get bored easily.
I've found that some of the better testers were ones who didn't get bored clicking the same buttons over and over again in The Great Bug Hunt.
-
4Oh dear. I hate it when people say "doesn't get bored" as a key property for a tester. I know great testers who have an extremely low boredom threshold. Insatiably curious and stubborn as hell would be a better description, to my mind. Doesn't get bored easily implies that you should be getting bored - if you think you're on the track of something, you won't be bored.– testerabCommented May 5, 2011 at 22:55
-
If they're clicking the same button over and over, that seems like a great place for automation. I'd much rather have someone who will build a tool to do a job than do the job themselves. Commented Jul 10, 2017 at 19:15
Excellent posts! Apart from what's already been listed, I can add another (somewhat context-specific) ...
- a willingness to represent user/business interests
Coming into software testing from a UAT/business-side of things (I'm still working on developing the technical skills), a willingness to be able to talk to the business (be it managers, users, business analysts), defend their interests and work with (not fight against) the developers to meet those needs is important.
In one sense, testers are "advocates of the user" and knowing what the users want and how to find out what they want from a functional, usability etc. sense (usually more than reading the requirements) and putting yourself in their shoes is a very useful skill/s.
- Great communication
- Analytical thinking
- Asks "why not" questions
- No fear (confident)
- Team player, no "lone ranger" mentality
- Knows when to push the envelope & when to let go
- Grasps concepts easily
- Loves to learn
- Belief in themselves & the product (i.e. not a quitter)
-
I was always a booster of the "loves to learn" concept, if the person is not going to grow in the position why am I hiring? If I want hands to do the same thing all the time I'll set up automation, I want someone who can absorb and grow in the position.– MichaelFCommented May 10, 2011 at 12:42
Please find my perspective
Junior QA
- Follows defined QA Process
- Prepares Bugs Reports, Status Reporting with all relavant information
- Manages and updates automation suite
- Willingess to learn, passionate about QA role
Senior QA
- Self Organized
- Challenges the Environment, Raise testing standards by experimenting new processes/Adopting new Tools
- Aware of Test Automation Framework Design and Development
- Sound Technical Skills
- Selfless - Volunteers/mentors team in terms of process/sharing best practices
- Actively involves/drives meaningful discussions and implements best practices
- Takes calculated risks and delivers products meeting quality bar
Usually testers are "advocates of the user" only when helping with user acceptance test.
More often, testers are "consultants to the product owner." In that role, they help to assess risk and focus testing on high-risk stories. In addition, they exercise low and moderate risk stories to identify defects.
Would like to throw in some more
Ability to consistently find "critical" problems
How?
Through 'Understanding' of the usage,impact and risk — on the product, business, customer, project and a confidence to advocate his work (e.g. bugs raised).
Positive Leadership traits are a must in my book
- Ability to handle problems single in a handed manner
- Inclination (atleast) to take up complex and hard tasks
- Ability to mentor peers irrespective of his job title
Great at relationships
- Someone who is good at developing and maintaining positive working relationships with Developers, Project owners and within the test team
Many good features are listed above, but to them I would add that a good QA person needs to be:
- deliberate
- methodical
- thorough.
I will add to the above answers:
- Pays attention to details.
I'd like to add something I haven't seen in many of the other answers - I think that the passion for QA is extremely important in a person looking for a QA position.
It seems like a no brainer, but the reality is that there are many people out there who see QA positions as a stepping stone to development. I think that someone who truly wants to be a dev in their heart is never going to be as good of a QA person than someone who truly has a passion for testing.
I will have to slightly disagree with Laura Hensley's position on the presence of a "lone ranger."
The occasional "individual contributor" can be a powerful asset to a QA team. They tend to find the most defects, the most risky defects, and are extremely persuasive in having said defects fixed, no matter how minor they appear to be. With their eyes firmly fixed on product quality and not politics or advancement into management, they can dramatically improve the quality of a product.
However, where Ms. Hensley's comment rings true for me is in concern to his / her demeanor and integration with the rest of the team. As long as your testers respect and work well with each other, and even socialize well with each other, the occasional testing "lone ranger" isn't necessarily a bad thing.
There are many great characteristics required for a QA/tester. To me, communication is really important. Also, a team spirit is equally if not more important. Trying to prove oneself being smart or the other dumb will not help. We are all in it together. Defects or issues should be discussed with as clear as possible steps to reproduce the defects. Come ready with facts and figures to discuss further the issue. It's also important to not assume things and instead speak up, "we need to discuss this" and then hear out what the other party has to say whether dev, BA or PM. It's not about me or you or anyone trying to score points or look great to stake holders or upper management.
QA/Testing is about delivering the best quality we can.
Not someone -
- who is not a team player
- who cannot reason logically
- who cannot think critically
- who cannot understand deeply
- who cannot communicate effectively
- who cannot take a stand if required.
I would like to add two important points to the others:
- Have a clear understanding of what a tolerance or other limiting specification is and why it is important.
- Able and willing to learn.
The reason for this is me having, in the past, to spend several hours with a member of the QA department who had "stopped the line" due to a component being "not to drawing" as a result of a supplier having delivered, at no extra cost and with appropriate wavers, resistors that were 1% tolerance rather than the ordered 3% tolerance ordered but in every other aspect exactly what was ordered. Eventually he agreed to sign off on restarting production only to do the same thing a week later with a batch of capacitors that came in, again with all of the paperwork, but with a 5% tolerance rather than 10%.
Obviously this was a hardware issue but I can well imagine a similar problem where a software vendor is expected to deliver a component sub-system and the requirements specify permitted and expected size and execution times or a range of compatible OSes and the vendor delivers better than expected, e.g.: Required operating system compatibility: Windows 7,8, 10 & 11 but delivered certified to work on all windows version 3.11 through 11, OS-X 6+, RHEL 5+ - i.e. the requirements exceeded rather than simply met.
Depending on what team member the project needs. But roughly speaking, I'd look for the follogin areas:
- testing skills
- domain skills
- technical skills
- soft skills
A tester can be really strong in one of these areas, while not so much in others. It's ok as long as the project's context calls for it.