Functional Testing

Functional Testing

The purpose of Functional Testing is to verify each function of the software application, ensuring the appropriate input, verifying the output depending on the functional requirements. It checks whether each component is working as expected or not. Therefore, it is also called "Component testing". This type of testing is mandatory regardless of the type of application.
During Functional Testing, the Black Box Testing technique is used, in which the internal logic of the system under test is not known. Tests User Interface, APIs, Database, Security, Client/Server communication and other application functions. It can be done both manually and automatically. Functions are tested by passing them input data and examining the output.
Functional Testing ensures that the application properly meets the requirements. This type of testing is not related to how the implementation happens, but only related to the results.

What does Functional Testing test?

1. The main functions of the application, the described functionality. In other words, the behavior of the application is tested according to the test specification.
2. Error conditions - presence of messages in case of error conditions.

Steps of Functional Testing

1. Understand the functions that the application should implement.
2. Generate input data based on function specifications.
3. Determine the expected output results for the selected input values.
4. Implement test cases.
5. Comparison of actual and expected results.

Types of Functional Testing

1. Unit testing

2. Integration testing 3

3. Interface testing

4. System testing

5. Regression testing

6. Smoke testing

7. Sanity testing

8. Acceptance testing

Unit testing

1. In this type of functional testing, the smallest functional and testable unit of code is tested during unit testing.
2. Mainly performed by developers as it is a White-Box testing technique.
3. Performed at the earliest stages of development, hence helps to identify defects at early stages of development. This helps save the higher cost of fixing defects in later stages of STLC.

Integration testing

1. Two or more unit-tested components of software are integrated together and tested to confirm that they interact as expected.
2. The communication of commands, data, DB calls, API calls, microservices processing takes place between departments and no unexpected behavior is observed during this integration.

Interface testing

1. Part of integration testing; The accuracy of data exchange, data transfer, messages, calls and commands between two integrated components is verified.
2. The communication between the database, web services, APIs or any external component and the application is tested during Interface testing.
3. There should not be any error or format mismatch in the communication of this data or command. If such a problem occurs, it should be fixed.
4. Interface testing is the testing of connectivity between different interfaces, while Integration testing is the testing of an integrated group of modules as a single unit.

System testing

1. All system components are combined and the system is tested for conformance and accuracy to requirements specifications (functional or system).
2. It is a Black-Box testing technique that validates the integrated system.
3. It is performed before Acceptance testing (UAT) in STLC (Software testing life cycle).
4. System testing is performed in a near-real environment and according to real-life usage.

Regression testing

1. After some improvements or code fixes by the developers, it becomes very important to run the Regression testing package. Regression testing is performed to ensure that these code changes have not hindered existing working functionality or introduced any new defects in the code.
2. Regression testing cases are a subset of existing functional tests that cover the main functions of the system.
3. Regression cases should be updated, added and deleted according to changes in the application.
4. Regression testing cases are the best candidates for automation testing because they are run frequently and take time to execute.

Smoke testing

1. After Developement, when a new build is released, Smoke Testing is performed on the application to ensure that all key features work to perfection.
2. Smoke Testing is usually performed early in application development for builds that are not yet stable.
3. During testing, if any key functionality does not work as expected, that particular build is rejected. Developers should fix bugs and create a new build for further testing.
4. After successful smoke testing, the application is ready for the next level of testing.

Sanity testing

1. Sanity testing is selected from the Regression testing suite, covering the core functionality of the application.
2.Sanity Testing is performed on a new build created by developers for a relatively stable application.
3. Once the application successfully passes Sanity testing, it is ready for the next level of testing.
4. It is easy to confuse Smoke testing and Sanity testing. After a new build, Smoke Testing is done to test the initial application. After multiple releases, once it has achieved stability, Sanity Testing is performed on the same application.

Acceptance testing

1. Acceptance of the application by the end user is checked during acceptance testing. The purpose of this testing is to ensure that the developed system fulfills all the requirements that were agreed during the creation of the business requirements.
2. It is performed immediately after System testing and before the final release of the application.
3. Acceptance testing becomes a criterion for the user to either accept or reject the system.
4. It is a Black-Box testing technique because we are only interested in knowing the functionality of the application for the market and real users.

Useful links:

Functional testing article/eng

Functional testing types article/eng

Functional testing article/rus

Functional testing video tutorial/eng

Functional testing video tutorial/rus