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?
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:
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.
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.
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.