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?
|
|||||||||||||||||
|
|
Please find my perspective Junior QA
Senior QA
|
||||
|
|
|
Many good features are listed above, but to them I would add that a good QA person needs to be:
|
||||
|
|
|
Would like to throw in some more
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).
|
||||
|
|
|
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. |
||||
|
|
|
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. |
||||
|
|
|
Excellent posts! Apart from what's already been listed, I can add another (somewhat context-specific)...
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. |
||||
|
|
|
Adding on to the above answers:
I've found that some of the better testers were ones that didn't get bored clicking the same buttons over and over again in The Great Bug Hunt. |
|||||
|
|
||||
|
|
The tl;dr:
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. |
|||||
|