This article is a sponsored post by TestMatick LTD.
Making the right decisions when hiring employees is an extremely important thing. And this rule applies to all professions and jobs.
Hiring a low-productivity QA engineer in a software testing company is sometimes even worse than having no such specialist at all. And there are several reasons for this:
- Maybe s/he doesn’t know how to automate tests. In this case, he will perform only manual tests, and the project’s deadline for release will be postponed.
- Maybe his/her level of automation knowledge is low, and you will get autotests that constantly fail and have to be monitored.
- Maybe the tester you’ve hired won’t understand the technical basics. In other words, the rest of your project team will have to spend their time explaining a lot of trivial things to him/her.
- Maybe s/he won’t be able to create test strategies. In the end, such specialist tests some unnecessary things. And the parts that need to be tested won’t be checked at all.
So, if you want to hire a good tester, you should look for someone who has the following skills.
If the QA engineer you potentially hire is not capable to find defects, there should be no reason to hire him/her at all. Every programmer can create so-called “save journey” tests and outline several autotests that can check the program code.
Testers are distinguished by their ability to think about testing things that programmers may miss: negative tests, obscure boundary cases, the correctness of interaction between parameters, and so on. To understand whether a potential employee can find bugs, give him software with a lot of defects, and ask him to find and describe bugs.
If a QA engineer cannot properly prioritize the tasks that need to be tested, he is unlikely to be useful to your team. Testers should know what exactly should be included in the smoke testing, and what areas need to be regressed when it is necessary to start looking for hard-to-reproduce defects.
To determine the candidate’s level of strategic thinking, give him a web product and ask him to create a test plan. He may not know all the features of the system, but he should be able to identify the important interconnections of its performance.
If your products are based on API, you need to make sure that the potential candidate understands how to test them properly. API that isn’t fully tested means impressive gaps in the overall web security, and hence, the poor end-users feedback.
To check the candidate’s knowledge, give him a sample API to test. Watch his work, what testing methods he will use, whether he will write enough negative/positive test scenarios, and what arguments he will use.
A tester who can look for bugs but cannot reproduce them is not much help. Any self-respecting tester should have sufficient communication skills. Ask the candidate to explain in his or her own words a complex defect. This approach will allow you to understand whether the person can find bugs, and how exactly will prove himself right. If his subsequent explanations are not clear to you, then such a specialist is unlikely to fit your position.
A potential candidate should be able to analyze a set of reasons to perform visual testing. For example, classic UI automation does not test that a picture displays correctly on web browser pages, but a visual testing tool does. The candidate should understand that web accessibility is a significant aspect of current web applications. They should be able to provide examples of web accessibility needs: the ability to scale text, apply screen reading, and view video files with subtitles.
As we see, there are a lot of things to consider when you look for a future member of your internal QA team or QA outsourcing. Keep them in mind, and remember that only masters of their business can ensure the best quality of any software product.