Ever wondered whether you are aware of all types of functional testing exists in the testing industry?
Let’s see them in this article. Straight to the core!
Types of Testing
- Unit Testing
- Smoke Testing
- Sanity Testing
- Component Testing
- Integration Testing
- Regression Testing
- System Testing
- User Acceptance Testing
- Exploratory Testing
- System Integration Testing
The Banking Application
Before we get into the details on what does each mean and when to use it, let’s quickly see the below example banking application.

In the above banking application architecture you will be able to see –
5 Features – Login, Account Summary, Pay Bills, Transfer Funds, Statements
6 Interfaces – Login Validation, Payment Service, Transfer Funds Services, Doc Engine, Doc Generator & Doc Generator Service
Tip: You can consider Features as Components of an application
Software Development Model
In order to build the above enterprise level banking application, the organisation or the team should adhere to a Software Development Life Cycle model. Just for our example, let’s assume we are following Agile Development Model.
Every feature and the interface gets developed in an iterative fashion. So as the testing, it happens iteratively along with development.
In reality, the interfaces are developed prior to any UI components / screens. This is because when the UI components are developed, the real & working functionality of the component (feature) is available. This will ensure that the component is developed and tested completely.
Types of Testing – Deep Dive
Unit Testing:
This testing is predominantly done by the Developers and NOT by Testers. Basically, the developers are testing the consistency of each line of code & code snippets (like methods), whether it returns the desired output by inputting several parameters.
This will be done before the developer commits the code to the source control.
Smoke Testing:
Smoke testing scope is very limited to critical paths of the application. The smoke tests will be added newly based on criticality of the path application. Say for example, in the above banking application, the smoke tests will include – Login, Pay Bills & Transfer Funds as these are critical flows.
Once developer commits the code to source control and deploys the code to an environment, smoke tests are the first set of tests that should be executed.
Sanity Testing:
Sometimes, during the testing the tester will report several bugs to be fixed by the developers. The tester would have identified the bugs based on a test case he/she drafted either in automated fashion or manually.
Now, once the developer fix the bug and deploys the code, the tester will execute the tests related to the bug fix and optionally the entire component tests. This will ensure that the fix done by the developer is not breaking any other functionality and create new breakage.
Component Testing:
Testing a feature or component of the application is called as component testing. In our example, we do component testing rigorously on various permutations and combinations against a component.
For example, Login is a component and we need to test the functionality of this component thoroughly. The tests may include valid credentials, error messages for invalid login attempts like giving wrong login details, field validation error messages etc.,
Component testing will be done during the sprint along with the development.
Integration (or Interface) Testing:
Interface bridges the data flow between two components. The components can either be UI screen or another system itself. In our application, the interfaces are clearly marked and the data flow between these components like Payment Gateway, Doc Engine, Database etc.,
The data flow can happen in any data exchange formats like XML, JSON between 2 components. The request will contain the details to be added in DB and be processed. A response will be returned which will contain the details to be shown in UI screen.
Integration testing is a technique in which the data flow is tested using request and responses. The tester will add a request with the data that needs to be processed and use appropriate tools to send the request. Once processed the response will be returned whether the tester will validated the status code and the details returned are valid.

Regression Testing:
This type of testing is carried out to validate whether the existing functionalities of the application are still working when the developer introduces a new feature or change into the system.
Usually, the regression tests are the piled up component level tests from previous builds / sprints.

Let’s understand better from our example scenario. The below example can give you an idea on how the tests are piled up from various sprints and becomes regression tests.

The sprints can include API developments as well which will become the part of regression suite eventually.
Tips:
- Regression testing will always be time consuming. It is always better to revisit your regression cases periodically to remove unnecessary test cases from the regression suite
- Try to derive realistic E2E scenarios from the various component level tests and stitch them together for a logical work flow tests
System Testing:
Many people will get confused with system testing and component testing.
System testing is a technique which is used to test the system itself.
From our banking example, Doc engine, Secure Payment Gateway, Document Generator and Database are individual systems. The scope of system testing stays within these individual systems and the tests focuses more from permutation and combinations of various cases.

User Acceptance Testing (UAT):
This is the last stage of testing phase. Usually during UAT, real users will be hired to test the application from an end-user perspective to identify any gaps. Some organisations will have a dedicated UAT team to do this task or a Business Analyst or a Product Owner will do the testing.
UAT will generally be done from front-end only to simulate user journey.
Exploratory Testing:
Although, this type of testing is not a scripted functional testing, the ways we perform the testing is specific to the functionality of the AUT.
Exploratory testing is a type in which the testers will test the system on the go. There will be no scripted test cases in advance which they use to do test execution. In this type, the testers will randomly pick a functionality and test the AUT to find bugs. It can be ent-to-end or a system specifically as well.
System Integration Testing (SIT):
System Integration Testing (a.k.a SIT), is a type of testing which is absolutely the complex type of functional testing that exists. This kind of testing is done across various systems right from front-end system to all types of downstream systems where the data flows.
SIT is highly complicated, but it is do-able provided, we have all resources and environments available at the type of test execution. If your AUT has many downstream systems, make sure you have the environments up and running using heart pulse tests before commencing SIT.
SIT is suppose to test the data flow across various systems your AUT interact. So make sure you have front-end tests and API tests are in place.
For example in our banking application, when the customer transfer funds, the application is designed in such a way that the updation of the transaction should happen in 2 different databases like DB 1 (Payment Info – PI) and Messaging Service (Text Message System – TMS). Once the transaction is successful, then the transaction details like sender name, recipient name, amount, status etc., are updated in Payments Info DB and a request is sent to TMS to send a text to the customer.
Now for SIT, we need to start from the front-end and submit the fund transfer from UI and validate whether the transaction details are stored correctly and a text message has been sent to the customer in one flow.

Conclusion:
I hope this article helps you in understanding various types of commonly used functional testing terminologies in the industry. The main objective of this article is to make people aware of several concepts and when they should use it. Of course, it differs from organisation to organisation, but let’s benchmark it with these definitions.
Image Credits:
Leave a Reply