Note: Before jumping into this section, revise your SQA Concepts first.
Functional Testing:
In
this type of testing, we test the functionality of the application.
Functionality testing is performed to verify that a software application
performs and functions correctly according to requirement specification
(These requirements are collected from Client).
Types of Functional Testing:
Following are the types of functionality testing:
Following are the types of functionality testing:
- Unit Testing
- Component Testing
- Integration Testing
- Smoke Testing
- Regression Testing
- Sanity Testing
- Alpha testing
- Beta Testing
- System Testing
- User Acceptance Testing UAT
- Ad-hoc Testing
- User Acceptance Testing
- Static Testing
- Dynamic Testing
- Boundary Value Analysis
- Equivalence Partitioning
A unit is the smallest testable part of an application like functions, classes etc. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.
Unit
tests are basically written and executed by software developers. It is a
test to check the code whether it is properly working or not as per the
requirement. White Box Testing method is used for executing the unit test.
Component Testing:
Component testing is a method where testing of each component in an application is done separately. Suppose, in an application, there are 5 components. Testing of each 5 components separately and efficiently is called a component testing.
Component Testing:
Component testing is a method where testing of each component in an application is done separately. Suppose, in an application, there are 5 components. Testing of each 5 components separately and efficiently is called a component testing.
Component
testing is also known as a module and program testing. It finds the
defects in the module and verifies the functioning of the software.
Integration testing:
It is a test to check whether all the modules are combined together are working as specified in the requirement document.
Integration testing tests integration between components, interactions to different parts of the system such as an operating system, file system and hardware or interfaces between systems.
Integration testing tests integration between components, interactions to different parts of the system such as an operating system, file system and hardware or interfaces between systems.
Also,
after integrating two different components together we do the
integration testing. As displayed in the image below when two different
modules ‘Module A’ and ‘Module B’ are integrated then the integration
testing is done.
Integration testing is done by a specific integration tester or test team.
Smoke Testing: (IMP)
Smoke
testing is performed to test core functional flows in application
whenever QA team receives a build. We perform smoke testing before
performing the functional testing in detail. If Smoke testing gets
passed then we perform the functional testing in detail, if smoke gets
failed then we send the build to the dev team and we do not perform the
functional testing.
Regression Testing: (IMP)
When any modification or changes are done to the application or a bug is fixed then it can bring unexpected issues in the functionality of Application which was working fine previously, but after modification in code or fixing a bug can disturb the existing functionality. Along with the testing of new changes it becomes very important to test whether the existing functionality is intact or not.
The difference in Retest and Regression is; in Retesting, we test a bug after it is fixed and in regression testing, we test already working functionality in order to check whether this functionality is still working fine or not.
When any modification or changes are done to the application or a bug is fixed then it can bring unexpected issues in the functionality of Application which was working fine previously, but after modification in code or fixing a bug can disturb the existing functionality. Along with the testing of new changes it becomes very important to test whether the existing functionality is intact or not.
The difference in Retest and Regression is; in Retesting, we test a bug after it is fixed and in regression testing, we test already working functionality in order to check whether this functionality is still working fine or not.
Sanity Testing: (IMP)
In
Sanity testing, all the major flows are tested whenever there is a
change in code to confirm that there should not be any showstopper,
blocker or crashes.
A showstopper bug is a hardware or software bug that causes an implementation to stop and become essentially useless. This critical bug must be fixed for the development process to proceed further. We perform sanity testing when we don’t have enough time for regression testing.
A showstopper bug is a hardware or software bug that causes an implementation to stop and become essentially useless. This critical bug must be fixed for the development process to proceed further. We perform sanity testing when we don’t have enough time for regression testing.
Most Important Interview Questions:
Q: What is the difference between Smoke and Sanity Testing?
Q: What is the difference between Regression and Sanity Testing?
Q: What is the difference between Regression and Retest?
System Testing: (Final Testing)
In system testing the behaviour of the whole system/product is tested as defined by the scope of the development project or product.
It may include test based on risks and test based on requirement specifications, business process, use cases, or other high-level descriptions of system behaviour, interactions with the operating systems, and system resources.
System testing is most often the final test to verify that the system to be delivered meets the specification and its purpose.
System testing is carried out by specialist testers or independent testers.
System testing should investigate both the functional and non-functional requirements of the testing.
In system testing the behaviour of the whole system/product is tested as defined by the scope of the development project or product.
It may include test based on risks and test based on requirement specifications, business process, use cases, or other high-level descriptions of system behaviour, interactions with the operating systems, and system resources.
System testing is most often the final test to verify that the system to be delivered meets the specification and its purpose.
System testing is carried out by specialist testers or independent testers.
System testing should investigate both the functional and non-functional requirements of the testing.
User Acceptance testing UAT: (IMP)
After the system test has corrected all or most defects, the software is handed over to the user in order to find out if the software meets the user's expectations and works as it is expected to.
After the system test has corrected all or most defects, the software is handed over to the user in order to find out if the software meets the user's expectations and works as it is expected to.
Alpha testing:
Alpha testing is one of the most common software testing strategies used in software development. It’s especially used by product development organizations.
Alpha testing is one of the most common software testing strategies used in software development. It’s especially used by product development organizations.
- This test takes place at the developer’s site. Developers observe the users and note problems.
- Alpha
testing is testing of an application when development is about to
complete. Minor design changes can still be made as a result of alpha
testing.
It has two phases:
- In the first phase of alpha testing, the software is tested by in-house developers. They use debugger software. The goal is to catch bugs quickly.
- In the second phase of
alpha testing, the software is handed over to the software QA staff,
for additional testing in an environment that is similar to the intended
use.
Beta Testing:
It is also known as field testing. It takes place at the customer’s site.
It is also known as field testing. It takes place at the customer’s site.
The name itself suggests that this testing is
performed on an ad-hoc basis i.e. with no reference to the test case
and also without any plan or documentation.
Just
consider the above image, if we want to test the "Age" textbox then we
have to make sure that it should accept any value form 18-56 and not
below 18 and above 56. We cannot test by entering each value from 18 to
56 as it will take a lot of time. Here boundary value analysis comes. So
we will test using values i.e.
Equivalence Class Partitioning:
The objective of this testing is to find the defects and break the application by any
random functionality.
Ad-hoc Testing is an informal way of finding defects and can be performed by anyone in the project.
Ad-hoc Testing is an informal way of finding defects and can be performed by anyone in the project.
Static Testing:
In
static testing, we can test and find defects without executing code.
Static Testing is done during the verification process for example:
reviewing, walkthrough, inspection, etc. Static testing is the testing of the software work products manually, or with a set of tools, but they are not executed.
Dynamic Testing:
In
dynamic testing, the software code is executed to demonstrate the
result of running tests. It’s done during the validation process. For
example Smoke testing, Sanity testing, Functional testing etc.
Static Testing:
In
static testing, we can test and find defects without executing code.
Static Testing is done during the verification process for example:
reviewing, walkthrough, inspection, etc. Static testing is the testing of the software work products manually, or with a set of tools, but they are not executed.
Dynamic Testing:
Boundary Value Analysis: (IMP)
Just
consider the above image, if we want to test the "Age" textbox then we
have to make sure that it should accept any value form 18-56 and not
below 18 and above 56. We cannot test by entering each value from 18 to
56 as it will take a lot of time. Here boundary value analysis comes. So
we will test using values i.e.
1. A value below the minimum (18 ) value i.e 17
2. A Values above the maximum (56) value i.e 57
3. Values between 18 and 56 i.e min, +min, -max, max.
Have a look at the below image.
Equivalence Class Partitioning:
It is a testing technique and a type of Black
Box Testing. During this Equivalence Partitioning, a set of the group is selected and a
few values or numbers are picked up for testing. It is understood that all
values from that group generate the same output.
The
aim of this testing is to remove redundant test cases within a specific group
which generates the same output but not any defect.
Suppose,
the application accepts values between -10 to +10 so using equivalence
partitioning the values picked up for testing are zero, one positive value, one
negative value. So the Equivalence Partitioning for this testing is -10
to -1, 0, and 1 to 10.
A Few More Testing Types:
Data-Driven Testing:
Data-Driven is an automation testing part in which test
input or output values, these values are read from data files. It is performed
when the values are changing by time. The different data files may include
data pools, CSV files, Excel files. The data is then loaded into variables in
recorded or manually coded scripts. For data-driven testing, we use Parameterizing and Regular expression Technique.
Ex: To evaluate login functionality, we use the different user name and password combinations, variables are used to access different username and password. The list of username and password are stored in a data table or excel sheet.
Ex: To evaluate login functionality, we use the different user name and password combinations, variables are used to access different username and password. The list of username and password are stored in a data table or excel sheet.
White Box Testing:
It is a test in which a tester looks into the code and performs the testing.
Tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system, as well as programming skills, are used to design test cases.
It is a test in which a tester looks into the code and performs the testing.
Tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system, as well as programming skills, are used to design test cases.
Black-box testing:
In this type of testing the internal behaviour of the program is completely ignored. Also known as behavioural testing, since only the external behaviour of the program is evaluated and analyzed.
Treats the software as a "black box", examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it.
In this type of testing the internal behaviour of the program is completely ignored. Also known as behavioural testing, since only the external behaviour of the program is evaluated and analyzed.
Treats the software as a "black box", examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it.
Grey-box testing:
Gray box testing, also called grey box analysis, is a strategy for software debugging in which the tester has limited knowledge of the internal details of the program.
Data-Driven Testing:
Data-Driven is an automation testing part in which test input or output values, these values are read from data files. It is performed when the values are changing by time. The different data files may include data pools, CSV files, Excel files. The data is then loaded into variables in recorded or manually coded scripts. For data-driven testing, we use Parameterizing and Regular expression Technique.
Ex: To evaluate login functionality, we use the different user name and password combinations, variables are used to access different username and password. The list of username and password are stored in a data table or excel sheet.
Gray box testing, also called grey box analysis, is a strategy for software debugging in which the tester has limited knowledge of the internal details of the program.
Data-Driven Testing:
Data-Driven is an automation testing part in which test input or output values, these values are read from data files. It is performed when the values are changing by time. The different data files may include data pools, CSV files, Excel files. The data is then loaded into variables in recorded or manually coded scripts. For data-driven testing, we use Parameterizing and Regular expression Technique.
Ex: To evaluate login functionality, we use the different user name and password combinations, variables are used to access different username and password. The list of username and password are stored in a data table or excel sheet.
0 Comments