Following on from the previous topic, let's look at other types of testing from a different perspective. Understanding the variability of testing allows the tester to do the job more thoroughly, find different bugs, and go according to the company's business processes.
Testing by code access level
There are three types of tests for this criterion. They are shown in the picture.
Black-box testing is testing where there is no access to the code and we know nothing about how the system works. This type of testing is also called "specification-based testing". Here we need to focus on what the software does and not on how it does it. Both functional and non-functional testing is carried out within a black box framework, which does not require knowledge of the internal structure of a component or system.
The aim is to detect the following categories of defects:
Wrongly implemented or missing features.
Interface errors.
Behavioural errors or poor system performance.
For example: You get your hands on a blender, you have no idea how it works and you don't know the specifics of its assembly. You just use the buttons and specifications that come with it.
Another example: A tester tests a website without knowing the specifics of its implementation, using only the input fields and buttons provided by the developer. The source of the expected result is the specification.
Gray box testing is testing based on limited knowledge of the internal structure of the software. In this case, the tester does not work with the software code but is familiar with the internal structure of the program and the interaction between components.
For example: You want to test the operation of your TV but you don't have access to its internal components. However, you can perform various tests and experiments with external interfaces and buttons. This would be the gray box testing.
Another example: The tester detects all intended (both correct and incorrect) and unintended user input and compares the actual result of program execution with the expected result. The tester knows about how the web app works, the database structure, and other system parts, but they can't look at or use the actual code.
White-box testing is testing a software product with access to the code and full knowledge of the system.
For example: You know how a blender works, you can open the source code of a board (e.g. Arduino) and read it, find bugs in the code, etc. You can also work with sensors and other components at any level.
Another example: The tester examines the code implementation of input fields on a web page, determines all provided (both correct and incorrect) and not provided user inputs, and compares the actual result of the program execution with the expected result.
The expected result is determined not only by the specification but also by how the code is supposed to work.
Testing by levels
Level testing is a software testing methodology that involves testing at different levels of application functionality. These levels are often called "test levels" and represent different aspects of the system under test that can be tested independently of each other.
Unit/component testing – checks individual small parts of the application.
Integration testing – the interaction between several parts of the application is tested.
System testing – the application is tested as a whole.
Acceptance testing – a formal testing process that verifies that the system meets the user's needs, requirements and business processes. This is done to decide if the customer (inside or outside the company) or someone authorized should approve the application.
This topic is an answer to the question "What levels of testing do you know" in the interview.
Testing by formality
Formality testing is determined by the testing approach chosen.
Test-driven testing – testing based on pre-written test cases.
Exploratory testing – testing based on experience without detailed preparation, with simultaneous test development and execution.
Ad Hoc testing – testing without test development, without documentation. It is based on the tester's intuition and experience.
This topic is an answer to the question "What approaches to testing do you know" at the interview.
Testing by importance
Testing by importance means that testing, test scenarios, and tasks are prioritized and executed according to their importance and priority for the project. This approach helps to focus on testing the most important and critical aspects of the system to ensure its high quality.
Smoke testing is a test of key functionality before full-scale testing begins, to ensure that the build is fit for testing as a whole. This testing avoids wasting time, as testing the whole application is useless if there are problems with key features and critical bugs.
Regression testing – is performed to verify that the system has not degraded after the changes have been made. A deep and complete check of the product is performed.
Sanity testing – checks the operation of the main functions of the application. It is performed when release schedules are tight and it is practically impossible to perform thorough regression testing. It is essentially a shortened regression.
Conclusion
In summary, software testing is a complex and multifaceted process involving different testing methodologies, each with its own unique approach and purpose. Understanding the testing framework allows for a comprehensive assessment of software quality and functionality. This works for both simple and complex multi-tier applications.