1) Smoke Testing: –

It is initial testing.

Once the build is ready from the Development environment before releasing the build to the Testing team they will conduct the smoke test on the build.
A smoke test is the initial testing performed on the build to check whether the application is ready for the testing or not? 
The development team will click on all modules (Tabs & Links) and sub-modules to check whether it is navigating to the appropriate phase or not? 
If it is navigating properly then they will conclude that the smoke test is passed.
If it is failed to navigate to any phase, they will conclude that the smoke test is failed.
If the smoke test passed, then they will release the build to the testing team. 

Pre SRN / Build Acceptance Testing/ Build Verification Testing: –

Before releasing the build to the testing team, the test engineer will perform the smoke testing in the development environment is known as PRE SRN/BAT/BVT.


2) Sanity Testing:-

Once the build is released to the testing team, that test engineers will perform smoke testing in the test environment is known as Sanity Testing.
Once the smoke test is performed by the testing team they have to send the smoke test results to all the resources they know and email.

SRN (S/w Releasing Notes):-
It is a document whenever the developer is releasing the build he will also send an SRN document along with the build.
It contains
1) Deployment guidelines
2) The number of bugs fixed, number of bugs in Open State (not at fixed)
3) The modules which need to be tested
4) The modules which are under development.

Whenever the build is deployed in the test environment the test engineer has to properly review the SRN document then he has to go for sanity/smoke testing.

3) Regression Testing:-

The process of testing already tested functionalities on the iterative build is known as regression testing.
It will be performed in two ways.
1) Whenever the test engineer identifies a bug, the bug will be reported (Send) to the development team, the developer will fix the bug and release it to the testing team in the form of a new build.
The test engineer will check whether the bug is fixed or not?
The test engineer will also check that the test cases which are passed in the previous build are working properly or not will be tested in the new build.
Regression testing is performed to verify that the defect fixes made to the software/application works as expected and do not break the existing functionality.

2) Testing new functionalities is not regression testing. Testing already tested functionalities is regression testing.

4) Re-Testing:-
Retesting is to verify that the defects are fixed and the functionality is working as expected. When a defect is fixed, the test cases which are failed with reference to the defect are executed again.
The process of testing the same functionalities again and again by using multiple sets of data.

Ex: Test Gmail login functionality again and again with 100 login credentials.

Test the create an a/c functionality by using multiple sets of data.

5) GUI Testing:-

GUI stands for Graphical User Interface.
The test engineer has to perform the below activities in GUI testing.

1) Check the Alignments of all the fields in the application

2) Check the Spell of all the fields in the application.

3) Check the Font of all the fields whether it is maintaining consistency or not?

4) Check the Colour of the fields it should consistent.

5) Check the Overall look and feel of the application.

6) Usability Testing:-
While performing the testing on the application the test engineer has to check whether the application is maintained at user-friendly end-user or not?
Providing user-friendliness to the application is known as usability testing.
We have to verify the below activities: –


  • A to Z
  • a to z


  • 0 to 9

Special Characters

  • *, &, $

Minimum 5 Characters and Maximum 12

To display the “Invalid Username / Username and Password does not match”.

Ad-hoc Testing:-

In Ad-hoc testing, one will perform testing in their own style after understanding the requirements clearly.

It is done to uncover the defects that are not covered/found in planned testing. Usually in the final stages of the project, this type of Testing is encouraged.

By performing ad-hoc testing the test engineer can provide user-friendliness usability to the application.

Test Design Techniques: –

It contains 2 techniques. 

1) BVA – Boundary Value Analysis 

2) ECP – Equivalence Class Partition Or Equivalence Partitioning Testing

1) Boundary Value Analysis (BVA)

Whenever we are planning to test the range like 0 to 100, 0 to 1000, 0 to 10000, etc.

It is very difficult to test the application or field with all the values and we can also not possible write the test cases for all the positive and negative flows. 

In this scenario/situation, we have to apply the technique are called “BVA”. 

Test the application with Minimum, Min+1, Middle, Maximum, Maximum-1 values if the field is acceptable then we can conclude that the field accepts all the range.

Test the field Min-1 & Max+1 if it is not acceptable then we can conclude that it is accepting only range.

Scenarios / Requirement: –

Check whether the test box is accepting the range between 0 to 100.


2) ECP – Equivalence Class Partition Or Equivalence Partitioning Testing

Whenever we are having a special requirement like username and password field should accept 

[ a to z ] Or [ z to a ]

A to Z    

A to z

a to Z Or Z to a 

0 to 9







The user field should not accept symbols 







In this scenario/situation, it is not possible to develop the test cases for will all the above given.

We have to use the Equivalence class partitions technique. 

Divide the test data equally into valid & invalid.

Test the application with valid data so the field should have accepted it.

Test the application with invalid data so the field should not have accepted it.

Test Data: –

The data which the test engineer is using the test the application is known as test data.

Valid Test Data         Invalid Test Data