What is Functional Testing?
Testing each and every functionality of an application is called Functional Testing.
Functional testing is a type of testing that verifies that each function of the software application meets the requirements.
Types of Functional Testing
- Smoke Testing
- Sanity Testing
- Unit Testing
- Integration Testing
- System Testing
- UAT (User Acceptance Testing)
- Retesting
- Regression Testing
Smoke Testing
It means we check the application's critical functionality and whether the build is stable.
It is documented.
We use only positive data to test the application.
When Do We Do Smoke Testing?
- Smoke testing is done to ensure build stability — that is, to check whether the build is stable.
- It is also known as BVT (Build Verification Testing).
- It is done whenever new software functionality is developed and integrated into the existing build deployed in the QA/Staging environment.
- It ensures that all critical functionalities are working correctly.
How Do You Decide on the Test Cases for the Smoke Test Suite?
- The smoke test cases should be simple, fast, and easy to execute and automate.
- They should cover the main scenarios and workflows of your system.
- They should also verify the integration and communication of your system with other systems or components.
How to Do Smoke Testing?
Smoke testing is usually done manually, though it can also be automated.
The approach may vary from organization to organization.
Manual Smoke Testing
- In general, smoke testing is done manually, and the approach varies from one organization to another.
- It is carried out to ensure that navigation along critical paths is as expected and does not hamper functionality.
- Once the build is released to QA, high-priority functionality test cases are executed to identify critical defects in the system.
- If the test passes, we continue with functional testing.
- If the test fails, the build is rejected and sent back to the development team for correction. QA then starts smoke testing again with a new build version.
- Smoke testing is performed on the new build and integrated with the old builds to maintain system correctness.
- Before performing it, the QA team should check for the correct build version.
Smoke Testing by Automation
Automation testing is used for regression testing.
However, we can also use a set of automated test cases to run as part of the smoke test.
Sanity Testing
- It is a subset of regression testing.
- We check only minor functionality and the area where bug fixes were made.
- We test the application after bug fixes or when new modules are added to verify whether it affects others.
- If the sanity test fails, it will reject the build.
Smoke Testing vs Sanity Testing
Smoke Testing
Scope
- Wide — critical functionality across the build.
Depth
- Shallow.
Goal
- Check whether the build is stable.
Documentation
- Documented.
On Failure
- Build is rejected.
Sanity Testing
Scope
- Narrow — only the area where a bug was fixed or a module was added.
Depth
- Deeper on the impacted area.
Goal
- Verify that a specific fix/change works and hasn’t affected others.
Documentation
- Usually a subset of regression.
On Failure
- Build is rejected.
Build Verification Testing (BVT)
How to check if the build is testable or not:
We perform the Build Verification Test (BVT).
- BVT is a set of tests run on every new build to verify that the build is testable before it is released to the testing team for further testing.
- These are core functionality test cases that ensure the application is stable and can be tested thoroughly.
- Typically, the BVT process is automated.
- If BVT fails, the build is reassigned to a developer for a fix.
Tips for Test Cases in Your BVT Automation Suite
- Include only critical test cases in BVT.
- All test cases included should be stable and have known expected results.
- Make sure the included critical functionality test cases are sufficient for application test coverage.
BVT is essentially a set of regression test cases executed each time for a new build — also called a smoke test.
The build is not assigned to the test team unless and until the BVT passes.
Regression Testing
If there are any changes to the code — any modification, bug fix, or requirement change — we must verify whether it affects the existing system.
When Do We Do Regression Testing?
We perform regression testing whenever:
- There is a code change.
- A new feature is added.
- A modification is made.
- A defect is fixed.
How to Do Regression Testing?
- First, we debug the code to identify the bugs.
- Once the bugs are identified, the required changes are made to fix them.
- Regression testing is performed by selecting relevant test cases from the suite that cover both the modified and affected parts of the code.
Regression Testing Techniques
Retest All
All the tests in the existing test suite are re-executed.
This is very expensive as it requires a lot of time and resources.
Regression Test Selection
Some selected test cases from a test suite are executed to test whether the modified code affects the application or not.
Prioritization of Test Cases
Prioritize test cases based on business impact and critical and frequently used functionalities.
Selecting test cases by priority greatly reduces the size of the regression test suite.
Selecting Test Cases for Regression Testing
- Test cases that have frequent defects.
- Functionalities that are more visible to the users.
- Test cases that verify the product's core features.
- Test cases of functionalities that have undergone more recent changes.
- All integration test cases.
- All complex test cases.
- Boundary value test cases.
- A sample of successful test cases.
- A sample of failure test cases.
Why Do We Perform Regression Testing for Every Build?
For every build received from the developer, we run regression tests because each build includes code changes.
Example:
Build version 1 is given to me. I complete regression testing, the test cycle completes, and I report some defects.
The developer then works on it — changing, updating, adding, or removing code — and gives another version of the build.
Because of these code changes, existing functionality may be affected.
That is why we do regression every time we receive a build.
Why Do We Perform Regression Testing Along with Retesting?
Not only the retested area, but also other areas may be affected.
When we do retesting, the developer has already taken up some defects.
While fixing them, the developer may have modified or removed code from the application — not just fixed it.
Because of this, other areas of the software may be affected, so we have to check whether they are working properly.
Re-Testing
Testing a defect to determine whether it is fixed is called Retesting.
Order in Which We Perform Smoke / Retesting / Sanity / Regression
Smoke Testing
As soon as we get the build, we perform smoke testing first.
Retesting
After smoke testing, if any bug occurs, we perform retesting to verify it is working.
Sanity Testing
Whenever the developer changes code or fixes a bug, we perform sanity testing to verify the changes.
We test the impacted area in depth (not the whole application).
Sanity testing is a subset of regression testing.
Regression Testing
We test the entire application in depth, checking where bug fixes or modifications were made and which areas are impacted.
User Acceptance Testing (UAT)
We do user acceptance testing once system testing is performed.
It is done on both the user and client sides.
Here, we focus on user needs — whether the software meets customer requirements and user expectations.
UAT is a type of testing performed by the end user or the client to verify the software system against requirements before moving the application to the production environment.
It is done in the final phase of testing, after functional, integration, and system testing are complete.
Types of User Acceptance Testing
Alpha Testing
Generally performed at the organization level.
An employee of the organization performs testing and verifies the software system against requirements.
Beta Testing
Performed at the client side, where the whole system is tested as per the client’s environment.
Generally, alpha and beta testing are done by two separate teams — largely by a team that is functional users of the software.
As a QA team, we assist them as requested by the client.
Ad-hoc Testing
Testing an application randomly, without any test cases, is called Ad-hoc Testing.
- It is an informal testing approach aimed at breaking the system.
- The tester should have knowledge of the application even though they do not have requirements/test cases.
- This testing is usually an unplanned activity.
FAQs
1. What is functional testing?
Testing each and every functionality of an application to verify that each function works against the requirements.
2. What is the difference between smoke and sanity testing?
Smoke testing is a wide, shallow check of critical functionality to confirm the build is stable.
Sanity testing is a narrow, deeper check on the specific area where a bug was fixed or a module was added.
Sanity is a subset of regression.
3. What is Build Verification Testing (BVT)?
A set of core tests is run on every new build to confirm it is stable and testable before it goes to the testing team.
It is typically automated and is also called a smoke test.
4. When do we perform regression testing?
Whenever there is:
- A code change.
- A new feature.
- A modification.
- A defect fix.
5. Why do we perform regression testing for every build?
Because every build may introduce code changes that affect existing functionality, we re-verify the application each time we receive a new build.
6. In what order should smoke, retesting, sanity, and regression be performed?
- Smoke Testing
- Retesting
- Sanity Testing
- Regression Testing
7. What is retesting?
Testing a defect to confirm whether it has been fixed or not.
8. What is User Acceptance Testing (UAT)?
Testing by the end user or client to verify the system against requirements before it moves to production.
It is done after functional, integration, and system testing.
Its two types are:
- Alpha Testing
- Beta Testing
9. What is Ad-hoc Testing?
Random, unplanned testing without test cases, aimed at breaking the system.
The tester relies on application knowledge rather than documented cases.