SOFTWARE TEST LEVELS AND TYPES
There are many different types of tests that can be used in the software development process to ensure that all changes to the code are working as intended and expected. However, not all tests are based on the same assumptions. The following article describes the differences between the different types of tests used in the software development process.
Manual and automatic tests
First, we need to make a basic distinction between manual and automated testing. Manual tests, referred to in some sources as “manual tests”, are performed personally by testers clicking through the application elements or using appropriate tools to interact with the software and APIs. These types of tests are very expensive because they require the employment of testers, setting up the environment and conducting the appropriate tests, and in addition, they can also be prone to human error due to the fact that testers may, for example, make typos or skip some steps included in the test script.
Automatic tests, on the other hand, are performed by a machine that implements the assumptions of a previously prepared test script. Tests of this type may differ significantly in complexity, including both very simple tests consisting in verifying the operation of a single method in a given class, as well as tests checking whether the execution of a sequence of complex actions in the user interface will lead to the same results each time. Automatic software testing is much more efficient and more reliable than manual testing, however, the quality of automated testing directly depends on the quality of the developed test scripts.
Automated Testing is a key component of practices such as Continuous Integration and Continuous Delivery. They are also a great way to scale your quality assurance process as you add new features to your application. Despite this, it is still worth doing manual testing using the practice of so-called exploratory testing, which is described later in our guide.
Test levels
Unit tests
Unit testing is carried out at a very low level of the application, very close to the source code of the software, and consists in testing individual methods and functions of classes, components or modules used in the program. As a rule, automation of unit tests is quite cheap, and in addition, they can be performed very quickly by the CI server.
Integration tests
Integration testing checks that the various modules or services used by the software work well together. This level of testing can be used, for example, to check the interaction of the application with the database or to make sure that the micro-services work in accordance with the stated requirements and expectations. This level of testing is more expensive to run because it requires multiple elements of the application to run.
End-to-end level tests
End-to-end testing simulates the behavior of the user using the software in the full application environment. This level of tests checks whether all elements of the application work as intended. As such, some of them can be extremely simple and rely on loading a website or logging in, while more complex scenarios can include validation of email notifications, online payments, and many more, among others.
End-to-end testing is very useful, but it is expensive to implement and, what’s more, it can also be difficult to maintain when automated. For this reason, it is recommended that you only run a few key end-to-end tests and rely more on low-level (unit and integration) tests to quickly identify bugs in your application.
Acceptance tests
Acceptance testing is formal software testing that is used to verify that a system meets business requirements. They require the entire application to be started and run correctly and consist in replicating user behavior. This level of testing may also cover a slightly wider scope, which may include, among others, measuring system performance and rejecting changes in case they do not allow the achievement of the set goals and requirements.
Types of software tests
Functional tests
Functional testing focuses on the business requirements that an application is to fulfill. These types of tests focus only on checking the results of the operation, completely ignoring the intermediate states of the system during their execution.
Sometimes integration and functional tests are confused with each other because both types require the interaction of many components of the application. The difference between these types of tests is that an integration test may simply check that the application is able to query the database, while the purpose of the functional test is to get a specific value from the database according to the product requirements.
Performance tests
Performance tests check the operation of the system under heavy load. These types of tests are classified as non-functional tests and can be carried out in a variety of ways to thoroughly examine and verify the reliability, stability and availability of the platform. As an example of a performance test, you can measure the response time when executing a large number of queries, or observe the behavior and performance of the system when working with a large amount of data.
Implementation and running performance tests is quite costly, but nevertheless, it is possible to check whether new changes will deteriorate system performance.
Smoke tests
Smoke tests are basic tests that check the most important functions and operation of the application. The main advantage of this type of test is its quick implementation, and its main goal is to ensure that the most important functions and components of the system work as expected.
Smoke tests are most often used after the delivery of the next code version to check whether further tests are possible at all, and also, for example, immediately after implementation, to make sure that the application works properly in the new environment.
Exploratory tests
As the number of features and code improvements increases, so does the number of tests that must be performed to make sure that the system is working properly. In addition, it is also worth checking whether the errors once fixed appear in subsequent versions of the application. The key to achieving this goal is test automation, and their development will sooner or later become part of the software development process.
Some will ask at this point, is it still worth doing manual tests? The short answer to this question is “yes, it’s worth it”, but manual testing should focus primarily on exploratory testing, the purpose of which will be to detect non-obvious errors.
The exploratory testing session should not last longer than two hours and must have a clear scope that allows testers to focus on specific pieces of software. After introduction, it is up to the testers to try and check various activities to verify the behavior and response of the system. These types of tests are expensive, but are also very helpful in detecting various problems with the user interface or verifying complex user work processes. It is worth doing them especially after adding new functions to the application, because they offer the possibility to check how it will behave in extreme cases.
A note about testing
We would like to conclude this test guide with a brief comment on the very purpose of software testing. Although it is important to check whether users can use the application (whether they can log in or save a given object), it is equally important to make sure that the entire system does not crash in the event of entering incorrect data or in a situation where the user does something unexpected. . Predict what will happen when a user makes a typo, tries to submit a form that has not been completed completely, or uses the wrong API. It is also worth checking whether unauthorized persons can easily gain access to data or resources that they should not have access to. A good test suite should also include attempts to break the application so that you can understand its limitations.
Additionally, you should also bear in mind that tests are also code! Therefore, keep them in mind when reviewing your code, as they may be the last step before deploying your application to a production environment.