Guide For IT Recruiters: Types of Tests

Perhaps you have had a similar experience.

Your manager brings you a new job from a client. We need a tester! ASAP! Pronto, pronto, Andale, Andale! You get a short description, which is way more than you usually get, so you can’t complain. There is some gibberish – JIRA, JMeter, Selenium, ISTQB, UAT, Black Box… You try to decipher the description, but as always, time is not your friend, and you have to get moving. Anyway, a tester is a tester, right?

Actually, you couldn’t be more wrong. To complete the previous topic, we’ll discuss types of tests today.

When you contact a chosen candidate, the question about the type of tests is bound to come up. Manual and automated tests were already discussed so you can show off a little here. However, it is also worth knowing whether they’d be performing functional, non-functional, or maybe regression tests so you could provide more details for the potential tester. Even better, this knowledge will let you assess if the candidate you’re currently considering is the right specialist for you.

Okay. Let’s move on to some specifics. What types of tests are there?

FUNCTIONAL TESTS

They test HOW and TO WHAT LEVEL something is functional. In other words – whether the implemented functionalities work properly, in accordance with the requirements. Let’s take a simple example – a calculator – in this case, it will be addition and subtraction. Does it work? Then it’s okay.

The most commonly used technique here is:

Black-box testing

The specialist looks at the application as if from the outside. Are the tasks that should be performed actually performing? The tester does not need to know the programming language. In this case, you do not need to know “the inside”, i.e., the code. Okay, maybe sometimes you do… but in general, the essence is that we are not interested in what is happening inside the black box (of a given system), but we know what enters it – what data and what should come out of it – what result. Nothing more than that.

I’ll give you an example. Let’s take a blender. We put in fruits and vegetables, set the speed, time, and start the device (data). After the arranged time, let’s give it 30 seconds, we get a smoothie (result). That’s it.

STRUCTURAL TESTS

They focus on testing the application code. So the tester should have knowledge of the architecture of the whole system and, of course, the coding.

Here, on the other hand, we use:

White Box Testing

Unlike the black-box tests, where you look at something from the outside, in this case, you look at the inside of the program. You check the code and the errors that occurred in it. Therefore, the tester should know the programming language.

And back to the blender. We’re thinking about what’s going on inside the hardware. Here we know which cogs interact with which and in what order.

NON FUNCTIONAL TESTS

In general, they are used to evaluate the features of the tested system, software, applications, etc. And there are many types of them… I’ll give you a few examples:

• Load test
• Performance test
• Security test
• Reliability test
• Usability test

Let’s say we are testing a banking application. Load tests will allow us to verify whether the website will work (will not “freeze”) if many people log in at the same time. A performance test will enable you to check how long the user has to wait for the “reaction” of the website, its individual elements (functions) during the performance of subsequent activities. For example, the user logs in within 3 seconds, but while making a transfer, waits 15 seconds, and we have to check if this is acceptable. Or maybe everything should work faster? The security test, as the name suggests, is to make sure that no unwelcome individual has access to information resources, confidential data. Usability test, just whether the site is user-friendly or if anything is annoying about it.

REGRESSION TESTING

Specialists testing various applications, after detecting that something does not work as it should they report it to the software developer. The developer fixes this bug. Unfortunately, there is always a possibility that by adjusting one thing… we create another bug. That’s why you should check the main functionalities after such a repair.

And here, regression tests are used to verify this. Whether the changes made caused new errors to appear or somewhere in other parts of the application. As you probably already guessed, this involves a lot of work (you have to repeat it many times), so very often, this test is automated.

Authors

I have been on the IT market for a few years. I started to work as an IT recruiter, currently, I combine it with the Recruitment Manager role at deepsense.ai company (Warsaw, Poland). The beginning was for me like a jump in the deep end. I had absolutely no IT knowledge, whatsoever. The truth is I did not have the idea of what Java or JavaScript was :) Everything was new, but also exciting. I missed the most three things: Knowledge. I wanted to understand what people have been saying to me. Experience. I wanted to work properly. Patience. I wanted immediately. It was a huge challenge and a great journey. I spent a lot of time to learn many things actually from scratch. Now, I try to share my IT knowledge with the people who want to understand the IT world. I truly believe that through hard work, positive energy and self-confidence it is possible to change a lot!