Manual Testing

Tutorial 26: Smoke Testing and Sanity Testing

What is Smoke Testing?

● Smoke testing, also known as “Build Verification Testing” or “Build

Acceptance Testing,”
● It is performed when dev team gives build to QA team for testing.
● It is used to quickly identify and fix any major issues with the software
before more detailed testing is performed.
● The goal of smoke testing is to determine whether the build is stable
enough to proceed with further types of testing.
Smoke testing :

New Build

Developer QA

● When dev team gives build to QA, as a tester we should not immediately
start detailed testing
● First we should check if basic things of application are working or not by
doing smoke testing
● If its not working as expected means build is not stable and we should
reject that build
Smoke testing :

New Build

Developer QA

● we verify whether the important features are working and there are no
showstoppers in the build that are under testing.
● Smoke testing shows that the product is ready for testing.
● This helps in determining if the build is flawed to make any further testing a
waste of time and resources.
Smoke testing :

-
Example 1 :
● Consider a web-based e-commerce application.
● A new build of the application has just been deployed, and the QA team needs
to perform smoke testing to ensure it is ready for further testing.

What we should test :

1. Verify that users can log in with valid credentials.
2. Verify that the homepage loads correctly.
3. Verify that the search, adding cart functionality works.
4. Verify item is getting checked-out successfully
Example 2 :
● Consider app with installer
● A new build of the application has just been deployed, and the QA team needs
to perform smoke testing to ensure it is ready for further testing.

What we should test :

1. Verify that installer correctly installs the app
2. Verify that after installation app is launched properly
3. Basic navigation in app, basic functionality is working
Benefits of Smoke Testing :
● Early Detection: Identifies major issues early in the development cycle.
● Saves Time: Prevents the QA team from spending time on detailed testing
when the build is unstable.
● Confidence Building: Provides confidence that the major functionalities are
working as expected.
● Improved Quality: Ensures that only stable builds are subjected to thorough
testing, leading to higher overall quality.
● It saves test effort and time.
● It runs quickly.
What is Sanity Testing :
1. Sanity testing is a subset of regression testing that focuses on verifying specific
functionalities after minor changes or bug fixes in the software.
2. It ensures that the recent changes or fixes did not adversely affect the existing
functionality of the application.
3. The goal is to determine whether the section of the application being tested is
working as expected.
Key Characteristics of Sanity Testing

● Targeted Testing: Focuses on specific areas or functionalities that have been

modified.
● Narrow and Deep: Tests in greater detail, but only the areas impacted by
recent changes.
● Quick Execution: Aimed at quickly verifying that recent changes are working
correctly.
● Unscripted: Often performed without formal test cases, relying on a
high-level understanding of the changes.
● Sanity testing is normally performed by testers. Examiners concentrate on
the regions impacted by the most recent modifications, quickly evaluating
their stability.
Example of Sanity Testing
Scenario: Suppose a bug was reported in a web-based email application where
on users profile page the "Forgot Password" feature was not sending a reset
link.

The development team fixed this bug and released a new build.

Sanity Test Cases (on users profile and login page ):

● Verify that the "Forgot Password" feature sends a reset email.

● Verify that the reset link in the email works correctly.
● Verify that the user can update their password using the reset link.

As part of the sanity testing, login page is validated as well as the profile page to
ensure that the checks are working fine at both the places.
Advantages of Sanity Testing:
● helps to quickly identify defects in the core functionality.
● carried out in lesser time as no documentation is required for sanity testing.
● Verifies a small functionality of the system application whether it is still working or
not even after a small change.
● It helps in the scenario when the time for testing of the product is limited or having
less time to complete the test.
● fast process that provides quick feedback on the overall functionality of a software
build, allowing teams to quickly identify and address any critical issues.
● less time-consuming and less expensive than other types of testing, making it a
cost-effective solution for evaluating new builds.
● Enables developers and testers to focus on more complex testing scenarios,
improving overall productivity and reducing the time required for full regression
testing.
Smoke Vs Sanity Testing
Smoke Testing Sanity Testing
Manual Testing
Tutorial 25 : Regression Testing and Retesting
What is Regression Testing?

● Regression testing in software testing is a type of testing that ensures

that recent code changes have not adversely affected existing
functionalities.
● The main purpose of regression testing is to detect defects that might
have been introduced into a previously tested and stable application
after changes such as enhancements, patches, or configuration
modifications.
Key Aspects of Regression Testing :
● Scope: It involves re-running previously conducted tests on the modified
software to ensure that the existing functionalities work as intended.
● Automation: Regression tests are often automated to save time and
resources. Automated regression tests can be run frequently and
consistently
● Test Suites: Regression test suites typically contain a comprehensive set of
test cases that cover critical functionalities. These test cases are regularly
updated to include new features and changes.
● Confidence Building: Provides confidence that the major functionalities are
working as expected.
Types of Regression Testing:

1. Unit Regression: Testing individual units or components in isolation.

2. Partial Regression: Testing only the parts of the application that have been modified and the related
parts.

3. Complete Regression: Testing the entire application from end to end to ensure that changes have
not affected any part of the system.
Unit Regression Testing: Dev made some changes around user login
module and it has no impact on other modules
E commerce web-app
In such situation , we can test those changes
first, and along with that we have to do unit
User login
New user regression testing on that module only.
Register

We should select cases around login module as

Product Product cart part of unit regression testing
search checkout

payment User details

Rating and settings

Reviews
Partial Regression Testing: Dev made some changes around user register
module and it has impact on user login, user
E commerce web-app details section as well

In such situation , we have test those changes

User login
New user first, and along with that we have to do partial
Register
regression testing on all three impacted
modules as well.
Product Product cart
search checkout We should select cases around those modules
as part of partial regression testing

payment User details

Rating and settings

Reviews
Full Regression Testing: Dev made some changes around multiple
modules and it has impact on 70 to 80 % of
E commerce web-app application modules

In such situation , we have test those changes

User login
New user first, and along with that before release we
Register
have to do full regression testing on all
modules
Product Product cart
search checkout We should select full regression test cases
which will verify that all modules basic
functionality is working correctly.
payment User details

Rating and
settings
Reviews
Steps in Regression Testing :
1. Understand the changes made in the application, including new features, bug fixes, and
enhancements.

2. Choose relevant test cases from the regression suite that need to be executed based on the
changes made. This selection can be based on impact analysis to determine which areas are most
likely affected by the changes.

3. Prioritize Test Cases: Prioritize test cases based on the criticality and usage of the functionalities.

4. Where possible, automate the test cases to ensure efficiency and consistency in execution.

5. Run the selected test cases to verify that the existing functionality is intact.

6. Analyze the test results to identify any regressions or defects introduced by the changes.

7. Report any defects found, and once they are fixed, repeat the regression testing process to
ensure that the fixes do not introduce new issues.
Regression testing steps
Challenges in Regression Testing

● Maintenance: Keeping the regression test suite up to date with the latest
changes in the application can be challenging.
● Time-Consuming: Comprehensive regression testing can be
time-consuming, especially for large and complex applications.
● Resource Intensive: Requires significant resources for execution, especially
if the tests are not automated.
Retesting :
● While testing issue is found then QA will report and assign that issue to dev
● Once developer fixes the issue , it will be given to qa for retesting
● QA should retest that issue, if it’s working as expected then QA close that
issue
● If after retest that issue is still not working as expected , then QA should
reopen that issue and assign back to developer , and developer will have to
fix that issue and give back to QA for retest.
● Retesting involves re-executing test cases that previously failed to ensure
that the defects or bugs have been fixed.
● This is different from regression testing, which checks if new code changes
have affected existing functionality.
Retesting :
● Purpose: To verify that specific bugs have been fixed.
● Scope: Limited to the failed test cases.No need to test entire module
● Execution: Performed after the defects have been addressed.
● Priority: High, as it confirms the resolution of critical issues.
● Test Cases: Same test cases that originally failed are used.