Perhaps you have 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 anyway more than you usual get so you can’t complain. There 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 previous topic, we’ll discuss types of tests today.
When you contact a chosen candidate, the question about 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.
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. It works? Then it’s ok.
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 performed? 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.
Maybe 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 set 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, it is preferable for the tester to 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. Performance test allows 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? 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 there’s anything annoying about it.
Specialists testing various applications, after detecting that something does not work as it should, report it – they report it to the software developer. The developer fixes this bug. Unfortunately, there is always a possibility that by fixing 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, 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 are automated.
Slowly, the subject of testing is coming to an end. It’s time to take up new threads. However, in order to complete everything properly, it is worth mentioning the “gibberish”, i.e. tools. Because you are asking about the next meeting, it will take place sometime soon (info on priv) and we will figure out this issue with the help of a colleague Michał Dudziak – a specialist, who knows what’s what 🙂