Continuous integration and delivery practices must heavily rely on testing to be successful.
Testing is the process of evaluating a system and its components, to find if it satisfies the specified requirements or not.
Different types of tests are needed throughout these processes to gain confidence in a given solution. Each type of testing has its own features, advantages, and disadvantages as well.
In this post, we'll present the most used chain of testing phases, and explain the details of each type and phase.
Smoke Tests
Smoke tests are designed to ensure basic functionalities and implementations and environmental assumptions. They are generally run at the start of each testing cycle as a sanity check before running the complete test suite.
Smoke tests are designed to ensure basic functionalities and implementations and environmental assumptions. They are generally run at the start of each testing cycle as a sanity check before running the complete test suite.
The term ‘smoke testing’ for software testing, seems to come from a similar type of hardware testing, in which the device passed the test if it did not catch fire (or smoked) the first time it was turned on.
Unit Tests
Unit tests are responsible for testing individual elements of code in an isolated way. The functionality of individual functions and classes are tested on their own. Any external dependencies are replaced with stub or mock implementations to completely focus the test on the code in question.
Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. Often, after any smoke tests, unit tests are the first tests that are run when any changes are made.
Unit tests are typically run by individual developers on their own work station prior to submitting changes. However, continuous integration servers almost always run these tests again as a safe guard before beginning integration tests.
Integration Tests
After unit tests, integration testing is performed by grouping together components and testing their interconnection. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another, and focus on the flow of data and information between them. A typical software project in-fact, consists of multiple software components, developed by different programmers. The purpose of this level of testing is to expose defects in the interaction between these software components when they are integrated, in different combinations.
Integration tests are important for shared work because they protect the health of the project. Changes must prove that they do not break existing functionality and that they interact with other code as expected. This is usually also the first time that new code is tested against real external libraries, services, and data (for example external databases or APIs).
System Tests
Once integration tests are performed, another level of testing called system testing can begin. The focus of system tests are to make sure that groups of components function correctly as a unique identity.
Instead of focusing on the interfaces between components, system tests typically evaluate the functionality of a full piece of software, and focus on user-interfaces or externally-accessible interfaces. It is a black box testing technique to evaluate the complete system (end-to-end) against specified requirements.
User Acceptance Tests (UAT)
Acceptance tests are one of the last tests types that are performed on software prior to delivery. This type of testing is used to determine whether a piece of software satisfies all of the requirements from the business or user’s perspective. These tests are aimed to test interfaces for the expected functionality and for usability, and can be manual or automatic.
Frequently, acceptance testing begins by deploying the build to a staging environment that mirrors the production system. From here, the automated test suites can be run and internal users can access the system to check whether it functions the way they need it to. After release or offering beta access to customers, further acceptance testing is performed by evaluating how the software works with a real use and by collecting feedback from users.
Unit Tests
Unit tests are responsible for testing individual elements of code in an isolated way. The functionality of individual functions and classes are tested on their own. Any external dependencies are replaced with stub or mock implementations to completely focus the test on the code in question.
Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. Often, after any smoke tests, unit tests are the first tests that are run when any changes are made.
Unit tests are typically run by individual developers on their own work station prior to submitting changes. However, continuous integration servers almost always run these tests again as a safe guard before beginning integration tests.
Integration Tests
After unit tests, integration testing is performed by grouping together components and testing their interconnection. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another, and focus on the flow of data and information between them. A typical software project in-fact, consists of multiple software components, developed by different programmers. The purpose of this level of testing is to expose defects in the interaction between these software components when they are integrated, in different combinations.
Integration tests are important for shared work because they protect the health of the project. Changes must prove that they do not break existing functionality and that they interact with other code as expected. This is usually also the first time that new code is tested against real external libraries, services, and data (for example external databases or APIs).
System Tests
Once integration tests are performed, another level of testing called system testing can begin. The focus of system tests are to make sure that groups of components function correctly as a unique identity.
Instead of focusing on the interfaces between components, system tests typically evaluate the functionality of a full piece of software, and focus on user-interfaces or externally-accessible interfaces. It is a black box testing technique to evaluate the complete system (end-to-end) against specified requirements.
User Acceptance Tests (UAT)
Acceptance tests are one of the last tests types that are performed on software prior to delivery. This type of testing is used to determine whether a piece of software satisfies all of the requirements from the business or user’s perspective. These tests are aimed to test interfaces for the expected functionality and for usability, and can be manual or automatic.
Frequently, acceptance testing begins by deploying the build to a staging environment that mirrors the production system. From here, the automated test suites can be run and internal users can access the system to check whether it functions the way they need it to. After release or offering beta access to customers, further acceptance testing is performed by evaluating how the software works with a real use and by collecting feedback from users.
No comments:
Post a Comment