Building great software requires great QA engineers.

Of course, you need talented product managers to build a roadmap, and talented developers to build the product – but without a top-notch QA, the whole thing can be derailed.

So what do you need to look for when you’re hiring a QA? The real deal cares about the end user, isn’t afraid to fight their corner but knows when to let things go. They’re both technical and personable.

To help you spot the best QAs in your hiring process, here’s our top five list of some of the less obvious qualities that make a really great QA engineer.

 

1. Diplomacy

 

Nobody wants to tell someone they have an ugly baby, but unfortunately, it’s our job

As software consultant Dave Whalen put it years ago, the QA’s job is to tell developers and product managers their baby is ugly. Getting there early in the process is important, but so is the way you deliver the news: tread softly. As Whalen highlights, a good QA needs to have the ability to build good rapport with development teams. This is vital.

A good QA has the ability to help the development team understand that their role ultimately makes the team look good.

 

2. Creativity

 

A good QA can easily identify requirements and scope out relevant negative/positive scenarios at every stage of the process. But it’s their ability to predict the curveballs that make a great QA. What sets the ideal QA apart is a creative approach to planning for those niche-but-possible scenarios capable of undermining even the best-developed systems. You need your QA to test outside the boundaries to ensure the best products.

 

3. Clarity

 

Finding faults and bugs is all well and good but these issues need to be translated into clear, actionable insight. Great QAs recognise the importance of detailed, specific information on the precise nature of a flaw, including details on how it can be reproduced.

More really is more here – rather over deliver than leave developers continually coming back with questions. Great QAs spell things out and leave zero guesswork for developers and product managers. The alternative is for the QA to be bombarded continually with questions, and nobody wants that.

 

4. Objectivity

 

QAs have input into the entire software development process. Verifying software is just one aspect of the role – but most end users aren’t interested in code, they’re interested in what an application can do for them. A QA’s ability to offer objective insight into the validity of any features/changes/applications is just as important as the ability to verify code. Objectivity means being able to let go of minor imperfections or features that aren’t going to have a significant negative impact on the product, but which may bug the QA.

Then there’s the art of being able to recognise the right time to pick a battle. Picking usability holes the week before a product launch is more likely to result in arguments than any changes being implemented, so validation should take place early in the development process. A QA who is able to verify and validate will bring real value to your team.

 

5. Ability

 

Last but not least a great QA has ability. Tools will come and go; sophisticated automated QA testing procedures for highly complex software mean the best QAs need to have command of popular developer languages like C# or Java. The ability to learn and adapt quickly goes a long way when writing automation scripts using languages Perl, Python, Ruby and understand frameworks like Selenium.

Finding the right software Quality Assurance Engineers for your team can be the difference between success and failure. No one wants to ship bad software, and great QAs mean great teams, great software and a great product.

 

If you‘re in need of QA support, reach out today. Zartis Digital empowers companies to build outstanding software. Our services include technology advisory, remote teams and software development. Colm Flood is Client Services Director at Zartis Digital. For more information on the topic above, reach out to Colm@Zartis.com.

This is a revised version of an article that first appeared on Zartis.com in 2015.