Smoke testing vs Sanity testing vs
This article will present you with a complete idea about Smoke testing , Sanity testing and Regression testing
We will learn below topics in this article
- Smoke Testing is a Build Verification Testing
- A type of software testing that comprises of a non- exhaustive set of tests that aim at ensuring that the most important functions work.
- Initial testing process exercised to check whether the software under test is ready/stable for further testing
- Smoke testing decide whether deployed build is stable or not as to confirm if the QA team can proceed with further testing.
When do we do smoke testing??
Whenever the new functionalities of software are developed and integrated with existing build that is deployed in QA environment. Smoke testing ensures that all critical functionalities are working correctly or not.
- The main Objective of Sanity testing to validate the planned functionality is working as expected.
- Sanity Testing is a subset of Regression Testing and performed when we do not have enough time for doing testing
- Objective is to verify that each functionality is working as expected.
- Sanity Testing is performed for those builds which have gone through many regression tests and has come after a minor change in code.
- Sanity Testing is not a planned testing and is done only when there’s a time crunch.
When do we perform sanity testing??
- Bug fixing.
- Before the deployment of the production.
- When we get build after many regressions even if minor change.
- Regression means the return of a bug.
- Testing performed to find the regressions in the system after doing any changes in the product.
- If a piece of code of a software is modified , testing needs to be performed to ensure that it works as specified and that it has not negatively impacted any functionality that it offered previously.
When to perform Regression Testing ??
- Change in requirements and code
- New feature is added to the software
- Defect fixing
Why is Regression Testing important?
- Any Software change can cause existing functionality to break.
- Changes to a Software component could impact dependent Components.
- It is commonly observed that a Software fix could cause other bugs.
- All this affects the quality and reliability of the system.