Manual Part: - 1

Definition:-
Software: Software is a collection of programs which perform a certain task.
Software Testing: To Check Completeness, Correctness and Quality of the developed software as per
customers’ requirements.

Correctness: To check whether the particular software is going to generates the desired output as per
customer satisfaction or not.

Completeness: To check particular developed software is complete as per customer requirements

Quality: To ensure that particular software is user friendly or not i.e. particular software is defect free or not

Defect: When actual results not match with expected results is called Defects.

Bugs: When defect is accepted by development team is called bug.

Error: A mistakes in a coding is called Error.
Failure: When Build does not meet the requirements then it is called “Failure”.
SQA: Software Quality Assurance- Communication between business Analyst and customer is called
Software Quality Assurance.

Need/Important/Requirements of Software Testing:

1. To make good Quality of products.

2. For customer satisfaction.
3. To avoid loss of money.
4. To meet customer Satisfaction.

Resources Involved in Software Development Process:

Client:
1. Client is responsible to gives the requirements to the company.
2. Also client wants correct products as per his requirements from the company(organization)

BA (Bussiness Analyst):
1. BA is going to collect all the requirements from the Client.
2. On the basis of requirments BA is going to prepared BRS & SRS documents, and send to developments
team.

Tester:
1. Tester starts the test Application on the basis of positive scenarios & negative scenarios.
2. Positive Scenarios: -- Name is equal to “Vikas”.
 3. Negative Scenarios: -- Name is equal to 1234.

Customers:
1. After testing a product, the product is ready to delivery to the customers.

Software Development Factors:

a. To meet the customers (client) requirements:
In this requirement which types of application customers wants. & for which purpose
customers wants that products.
Example: Banking Domain, Telecom Domain, Finance Domain etc.
b. To meet the customers (client) expectation:
1. Privacy: privacy is nothing but security in that software.
2. Performance: In performance we check software is properly working in heavy load or not.

Costing of Product:
1. Product Costing for MNC’s are as per hour cast and customer have to paid it.
2. This payment depends upon the resource utilization & as well as time to complete the project.

Time- in Delivery:
1. Product should deliver in particular time depending upon the resource gathering & documentation.
2. If company not deliver the product on time, then company have to pay the penalties.

Maintenance:
Maintenance is the part of of service provided by the company after delivery the product.

SDLC: Software development Life Cycle

Why? Need/Advantages of SDLC:
1. For proper planning of Project.
2. By using SDLC BA is Collect the information from the user/customer what he exactly wants.
3. By using SDLC to identify how many resources are required to developed a particular software.
4. By using SDLC project should deliver within a time period.

Phases of SDLC:
Information Gathering:
1. In this phase collect the information from the client/customer.
2. Customer/client have bunch of requirements

Business Analysis:
1. BA is responsible to collect the information from customers.
2. On the basis of the requirements BA prepared BRS & SRS Documents.
3. BRS is nothing but Business Requirements Specification which is bridge between Client, developer &
Tester.
4. SRS is nothing but Software requirements Specification. SRS contain detailed documents about the
Project.
5. SRS contain: a. functional flow diagram b. functional requirements c. use cases d. snapshots

Functional flow diagram: Stepwise representation of software or proper sequence of task.

Functional Requirements: That s mean’s attributes which are required to complete a specific function.

Ex: Sign Up page Requirements

Use Cases: Use cases is nothing but functionalities in terms of Input & Output.
 Snapshot: Snapshot is nothing but Visualization of functionalities before development of product.

BA is responsible to prepare/create snapshot.

Design Phase:
There are two types in Design phases.

1. High Level Design (HLD)

2. Low Level Design (LLD)

Sr. High Level Design Low Level Design

No.
1 In HLD, Design of working of main module In LLD, Design of working of sub module.
2 It includes relation and dependency of main module It includes design for sub module
3 HLD created by Design Architecture LLD created by front end developers

Coding Phase:

1. In Coding phase developers are involved.

2. Only positive scenarios get tested by developers.
3. Set of programs are written by developers in this phase.
4. In coding phase two types of developers are involved. A. Front End Developer B. Back End developer
Sr. Front End Developer Back End Developer
No.
1 Front end developers are involved in UI. (User Back-end developers are involved in back end. (DATA
Interface) Base)
2. Front end developers going to cover the Algorithms selection is done by Back-end developers
functionalities of particular software

Testing Phase:
1. Testing phase is nothing but process to check completeness, correctness & quality of developed
software.
2. Once development is done tester is going to test positive as well as negative scenarios.
3. Testing phase are further had three types. A. BBT B. WBT C. GBT
WBT: WHITE BOX TESTING:
1. Only developers are involved in WBT.
2. Only positive scenarios check.
3. Also called unit testing
4. Also called glass box testing
5. Also called clear box testing.
6. Also called code level testing.

*** Unit Testing: -

1. Unit testing performed by developers.
2. Unit testing also known as WBT.
3. Only Developers are involved.
4. Only positive scenarios are tested by developers.
 BBT: BLACK BOX TESTING:
1. Only tester involved.
2. Cover or test both positive & negative scenario
3. Also called system & functional testing.
4. Overall, all functionalities of the application get tested in BBT.

GBT: GREY BOX TESTER:

1. Combination of both WBT & BBT.
2. GBT have Coding Knowledge.
3. The role of Grey Box Tester is whenever the software is hand over to the tester, tester check
this functionality and if any fault is occurred in the output of the function the Grey Box Tester
is not revert back to the developer instead of that Grey Box Tester himself solve those issues
by doing changes or making changes in the code.

Maintenance Phase:
Maintenance is the part of of service provided by the company after delivery the product.

Fish Model:

Sr. Verification Phase Validation Phase

No.
1. Also called Static testing Also called Dynamic Testing
2 Also called Quality Assurance Also called Quality Control
3 Also called Preventive Techniques Also called corrective techniques.
4 Verification phase conducted before validation phase Validation phase are conducted after Verification Phase
5 In verification WBT, BA, Designer, coder is involved. Only In validation BBT tester are involved. Both positive and
positive scenarios tested. negative scenario tested.
6 In verification coder review his own code, designer review his Tester reviews his own test cases.
own design.
7 Verification phase is a in progress phase Validation phase is a end process.

Waterfall Model:
1. Waterfall model is a standard model of SDLC.
2. Waterfall model is look like Waterfall.
 3. Waterfall model is also known as linear sequential model.
4. Waterfall model is a step-by-step implementation of SDLC.
5. In waterfall model when first phase is over then procedure goes to next phase.
6. Duration of Waterfall model is Three Months.
7. Change of request not accepted in waterfall model because we are not reverting back to previous
phase, we start from first phase.
8. Mostly waterfall model is used in “product based” organization

Advantages of waterfall Model:

1. Waterfall model is simple model of SDLC because waterfall model is linear sequential model.
2. Waterfall model is simple and easy to used.
3. Waterfall model work’s well for smaller projects.

Disadvantages of waterfall Model:

1. Requirement for changes is not accepted in waterfall model
2. We are not reverting back to previous phase. We revert back to first phase
3. Duration of waterfall model is more compared to V model and Agile Model.

Phases Of Waterfall Model:

V Model:
1. The Shape of V model is look like English Character V.
2. V model is a advance model of Waterfall.
3. In V model Verification phases & validation phases run parallelly.
4. In v model Development stages are mapped with Testing stages.
5. In v model Change of Request are accepted but charge some amount from the customers(client).
6. Duration of V model is Three months.
7. In v model if any requirement for changes is occurred, we are reverting back to previous phase.
8. V model is used in big organization.
9. V model is also known as continuous model because both phases run simultaneously. (parallelly)
10. V model is suitable for the project where requirements are changing.
 Advantages Of V model:
1. Change of Request Accepted
2. duration less than Waterfall model
3. We reverting back to previous phase. Both phases running parallely.
4. Used in Big organization

Disadvantages Of V model:
1. For change in request, we charge some amount from client/customer.
2. Expensive compared to Waterfall model.
3. Duration is more compared to Agile methodology.

Assessment of Development Phase:

1. In this phase we are going to make strategy for testing.
2. Project manager is deciding which methodology is used for testing. (Manual or automation)

Test plan preparation:

1. Test plan is a project level document which is prepared by team leader.
2. By using test plan, we are going to decide how many times required for testing an application.
3. Also decide release date of our application.

Requirement Phase Testing:

1. In this phase estimation (like resource) of project are finalized.
 Design Test cases:
1. Tester prepared test cases on the basis of test scenarios.
2. On the basis of one test scenario tester write multiple test cases.
3. Tester writes both positive & negative test cases.
4. Design test cases is written by BBT.

Design Phase Testing:

1. Developer & Tester both are involved in design phase testing.
2. Developer involved in this phase because he knows the coding knowledge & he can solve the
problem easily.
3. Tester writes the test cases on the basis of small unit of codes.

Program Phase Testing:

1. Developer is involved in program phase testing.
2. Program phase testing performed by WBT.
3. WBT starts testing from small unit of program.

Smoke Testing:

1. Smoke testing comes under validation phase.

2. When we received the build from the developers then we are going to check whether the build is
ready for testing or not is nothing but Smoke testing.
3. In Smoke testing we are going to check stability of our build (Application).

System And Functional Testing:

1. After performing Sanity testing, we are going to perform system & functional Testing.
2. In this testing tester is involved.
3. In this testing we are going to test all the functionality of our application.
4. Tester test both positive & negative Scenarios.
5. System & functional Testing Are performed by BBT tester.

UAT: User Acceptance Testing:

1. After SIT phase we comes to UAT phase.
2. UAT stand for User Acceptance Testing.
3. User & tester both are involved in UAT.
4. When user validate it is the correct product then product send to the final production.
5. UAT are Two Types
a. Alpha Testing
b. Beta testing

Sr No. Alpha Testing Beta Testing

1 Alpha testing is conducted before realizing the product. Beta testing is conducted after realizing the product. That
That means something happens developers’ side means something not happens developers’ side
2 Alpha testing conducted in control environment in the Beta testing conducted in uncontrol environment.
presence of developers & testers.
3 Service based organization Product Based Organization.
4 It can be WBT or BBT Only BBT.
5 More client is involved Less client is involved.
4 Ex: HDFC, HSBC, CITY Bank Ex: Phone Pe, Google Pay

Documentation:
1. Documentation is nothing but test summary report & test closure report.
2. Test summary report is prepared by Test engineer & test closure report is prepared by Test Lead.
(Team lead)
3. Test summary report contain detail information of project like:
a. How many tests cases pass?
b. How many test cases failed?
c. How many test cases blocked?
d. How many test cases skip?
4. After preparing the test summary report Test engineer send this report to Team leader.
DRE:
1. DRE stands for defect removal efficiency.
2. DRE calculates at which level tester(we) test the application
3. Formulas for DRE is:
DRE=A/(A+B)
Where: A= Defect found by tester
B=Defect found by Customer During UAT.
4. The ration 0.8:1 considered as good testing.
5. The ration 0.5:1 considered as average testing.
6. The ration 0.5<1 considered as bad testing.

Post-Mortem Testing:
1. Post- mortem testing performed by WBT.
2. When whole testing is done and product is ready for production, if product does not produce
expected (desired output) then white box tester is going to test all modules in details.

Comparison:

Sr Regression Testing Re-Testing

No.
1 When we add any new module in our application then we are Re-Testing is the Testing Method of Re-executing same
going to check impact of added module on existing module build/Application with multiple test data.
then we are going to performed Regression Testing
2 Regression perform Regression testing. BBT perform Re-Testing
3 Regression testing can be performed by three techniques: a. Before we log defect, we do re-testing
Re-Test-All B. Regression test Selection c. Prioritization of test-
case-suit
4 We can perform regression testing for both functional & non- After developer solve defect, we again do re-testing
Functional testing
 Sr Smoke Testing Sanity Testing
No.
1 Smoke testing is nothing but we are going to check whether Sanity testing focus on one particular part of your
the build is ready for testing or not application.
2. Smoke testing is a subset of build acceptance testing Sanity testing is subset of Regression Testing.
3 Smoke testing is usually performed when we received the Sanity testing is performed normally on single or one
build from the developers. particular module.
4 Smoke Testing performed by both developer and tester. Sanity testing performed by tester.
5 Smoke testing is scripted. Sanity testing is not scripted
6 Smoke testing is documented. Sanity testing is not documented

Example of Smoke Testing:

Sanity Testing Example:

➔ Consider a project where there are five module such as home page, login page, new user page,
user detail page, task creation page. The user’s name in the login page should not accept less
than six char, but login page user name field accept less than six character and bug/defect is
created.

The bug is sent to development team for fixing the defect. Development team
modifying/changing in code, defect is fixed. After fixing defect development team send again
to testing team for re-testing. Now testing team check again and bug/defect is fixed by
development team is not affecting the functionalities of other module is nothing but sanity
testing, because functionalities of all module is not check in detail by testing team check only
one particular module.

Level of Testing/ Testing Environment/ testing Phases

DIT:
1. DIT stands for development integration testing.
2. Only WBT involved (developers).
3. Developers is going to developed the application in DIT Phase.
4. Only positive scenarios are covered in DIT Phase.

SIT:
1. SIT stands for system integration testing.
2. BBT is involved in SIT phase.
3. SIT phase comes after DIT.
4. Both scenarios covered in SIT phase, i.e. positive & negative scenarios.

UAT:
1. UAT stands for user acceptance testing
 2. After SIT phase we comes to UAT phase.
3. Tester and user both are involved in UAT.
4. UAT are Two types a. Alpha testing B. Beta Testing
5. If user validate it is a correct product, then product is sent to production phase.
Production issue/HOT fix/ HOT leakage/Production leakage/Bug Leakage:
When issue (defect) found by customer in production and missed in UAT is called HOT fix/HOT
leakage/Production issue/Production leakage.

Sr. Product based Company Service Based Company

No.
1 The company which makes the software or application and give The company which makes their software or application
it directly to the customer are product-based company. from other companies and gives it for client usage are the
service-based company
2 Ex: Syngenta, Avaya, Cybage Ex: TCS, WIPRO

Terms Used in V model & Agile Methodology:

Sr no. V model Agile Methodology
1 Customer Stack Holder
2 Business Analyst Product owner
3 BRS Product Backlog
4 SRS Sprint Backlog
5 Use Cases User Stories
6 Release Sprint
7 Product Manager Scrum master

Agile Methodology:
Agile: Agile is a iterative & incremental approach for project development & Software Development.
Types of Agile:

XP-Extreme Programing

Lean

Kanban

Scrum

DSDM-Dynamic system development method

FDD- Future Driven Development

We are involved in Scrum Agile methodology

Sprint: Sprint is a time box Period of two week to three week in which product owner, scrum master, scrum
team are involved to complete the work in a given specific time.

What is Agile:
 1. Agile is a iterative & incremental approach for project development & Software Development.
2. Duration of Agile methodologies is “One” Months.
3. In agile methodology requirements are frequently changed
4. Now a days agile methodology is used in most of the service-based organization.
5. In agile at any point of development we accept the change in requirements.
6. The change in requirements does not impact on other development phase nor testing phase.
7. Also change in requirements does not increase the project duration.
8. For change in requirements, we are not charge any extra money from client.

Actors involved in Agile:

1. Stack Holder:
➔ Stack holder top most body of the organization.
➔ Stack holder gives the requirements to the product owners.
➔ Stack holder have bunch of requirements.

2. Product Owner:
➔ Product owner collect the requirements from the stack holder.
➔ Product owner prepared product backlog & Sprint Backlog.
➔ He is bridge between development team, testing team and stack holder.

3. Scrum master:
➔ Scrum master is the chairperson of the scrum meeting.
➔ Scrum master is going to check whether the sprint is going on smoothly or not for particular
sprint.

Backlogs in agile:
1. Product backlog:
➔ Product backlog is prepared by Product owner.
➔ Product backlog contain every features & requirements of the projects.
➔ Product backlog is nothing but product owner is going to store all the requirements of the
projects.
➔ Ex: if we have 10 user stories in our whole projects, then we are going to stored all the 10
requirements into product backlogs.

2. Sprint backlog:
➔ Sprint backlogs are created by product owners.
➔ Sprint backlogs contains detail information of the requirements which are required for module
developments.
➔ Under the Sprint backlogs we are going to stored current sprint user stories.
➔ Sprint backlog is subset of product backlogs.
➔ Ex: if we have 10 user stories in whole projects, then we are going to stored as 2 requirements
into sprint backlogs for the current sprint only.

Architecture of Agile Methodology/ Process of Agile Methodology:

Stack Holder:
➔ Stack holder top most body of the organization.
➔ Stack holder gives the requirements to the product owners.
➔ Stack holder have bunch of requirements.

Product Owner:
➔ Product owner collect the requirements from the stack holder.
➔ Product owner prepared product backlog & Sprint Backlog.
➔ He is bridge between development team, testing team and stack holder.

Product backlog:
➔ Product backlog is prepared by Product owner.
➔ Product backlog contain every features & requirements of the projects.
➔ Product backlog is nothing but product owner is going to store all the requirements of the
projects.
 ➔ Ex: if we have 10 user stories in our whole projects, then we are going to store all the 10
requirements into product backlogs.

Sprint backlog:
➔ Sprint backlogs are created by product owners.
➔ Sprint backlogs contains detail information of the requirements which are required for module
developments.
➔ Under the Sprint backlogs we are going to stored current sprint user stories.
➔ Sprint backlog is subset of product backlogs.
➔ Ex: if we have 10 user stories in whole projects, then we are going to store as 2 requirements into
sprint backlogs for the current sprint only.

Estimation:
➔ Estimation is nothing but how much time required to test a particular software
➔ How much time required to test a particular software is depend upon three factors which are 1.
Knowledge 2. Efforts 3. Complexity
1. Knowledge: Knowledge means how much knowledge have the team which are going to work in
same software.
2. Efforts: Under the efforts, higher authority decides how much efforts required to complete the
software.
3. Complexity: complexity means how much complex of the same project which are going to work
by same team. In short i) high ii) medium iii) low

User Stories:
➔ User stories is decided in Estimation phase.
➔ Based on user stories tester design the test cases.
➔ User stories consisting of two parts
a. Description criteria: description criteria is nothing but what user want to do and what’s its
desired output.
b. Acceptance criteria: If Different kind of scenarios are true then system generates Correct
output Otherwise system generates (shows) Error’s.
Example: Valid mobile number—int type data types.

Design Test Cases:

➔ On the basis of user stories tester design the test cases.

Ceremonies/ Meeting of Agile:

1. Sprint grooming & planning session
2. Scrum meeting
3. Sprint retrospective meeting
4. Sprint review meeting

Sprint grooming and planning Session:

 1. In the sprint grooming and planning product owner is going to groom the all the requirements to the
development team and testing team.
2. Product owner explain what exactly customer wants in the sprints.
3. In the sprint grooming and planning session we are going to estimates the user stories on the basis of
knowledge, efforts, complexity.
4. In the sprint planning meeting testing teams gives the user stories points to the user.
5. User stories points is nothing but the functional requirements of the application.
6. Peoples are involved in sprint grooming and planning session is product owner, development team
and testing team.

Scrum meeting:
1. Scrum meeting is also known as daily stand-up call or daily stand-up meeting.
2. Scrum master is the chair person of the scrum meeting.
3. Scrum master asked to any member of the team who are involved in the scrum meeting
4. In the scrum meeting we are going to discuss progress of our sprints.
5. People involved in the serum meeting is scrum master, development team, testing team and product
owner.
6. Scrum meeting depending upon organization is conducted some organization it conducted in the
morning, some organization it conducted in the evening or afternoon.
7. Mainly three types of question asked in scrum meeting:
a. What we did yesterday?
➔ In this we are going to discuss about status of yesterday’s work.
b. What we are going to do today?
➔ In this we are going to discuss about today’s task which are assign to me.
c. What we are going to do tomorrow?
➔ In this we are going to discuss about tomorrow’s plan.
d. What is roadblock or issue?
➔ In that we are going to discuss difficulties in executing the test cases.
Like: lack of co-ordination from the teams.
Error or defect in code compilation
Defect are not resolved by the developers.

Sprint review meeting:

1. As a name indicates sprint review meeting is nothing but teams are going to gives the reviews of his
products.
2. In shorts team explaining how we have developed the product.
3. In sprint review meeting development team, testing team, scrum master, product owner and stack
holder are involved.
4. In the sprint review meeting as tester we are going to check our sprint is going as per plan or not.

Sprint retrospective Meeting:

1. Sprint retrospective meeting is conducted after completion of one sprint and before starting of next
sprint.
2. In this meeting development team, testing team, scrum master and product owner are involved.
3. If something bent goes well then, we are going to continues and if something bent goes wrong then
how overcome these issues is discuss in this meeting.
4. In this meeting we are going to discuss what bent goes wrong and what bent goes right.
 Advantages of Agile Methodologies:
1. Sprint wise delivery.
2. Working software is delivered frequently.
3. Stack holder, developer and tester are continues interact with each other.
4. Change of request are always welcome.
5. For change of request not charge any amount from the customer.
6. Check point:

7. Implementation of automation:
If we implement automation the we get some benefits like:
a. less resources requirements to complete the project
b. less time to complete the project
c. high accuracy
d. less human error

Disadvantages of Less documentation

1. Less KT (Knowledge Transfer)
2. Less documentation
3. Product can go quickly out of track if product owner is not clear about the requirements.
4. Cost high compared to another model.

Comparison of Waterfall Model, V model And Agile Methodology.

Waterfall model V model Agile Methodology

Waterfall model is a linear sequential model Verification & validation run parallelly in v Agile is a iterative & incremental
model. approach for software development &
project management.
Duration of waterfall model is 3 to 6th month Duration of v model is 3 months Duration of Agile is one months.
Change in requirement not accepted Change in requirements is accepted, but Change in requirements are always
charge some amount from customer. welcome in agile. & not charge any
amount from customers.
We are not reverting back to previous phase We are reverting back to previous phase if We give sprint wise delivery in Agile.
we revert back to first phase. any changes are occurred.

Integration Testing:
Integration testing is nothing but when two or more than two modules connect by
developer is called integration. And we are going to test this connected module is called
integration testing.
Types of Integration Testing:
1. Front-end integration testing (incremental testing):

In front end integration testing developer connect two or more than two modules in front end by
using called functions.
2. Back-end integration testing (non incremental testing):

In Back-end integration testing developer connect two or more than two table in back end by using
join query.

Note: Communication between two modules done through XML (Extensible

Markup Language).

Testing Approaches: Whenever integration testing ends, then testing starts is known as testing
approaches.

Types of testing approaches:

1. Top -down approaches:

→When we have main module but we don’t have a sub module then top-down approaches are going
to test.
 ➔ The developer is going to create one dummy program for sub – module. This dummy program is
known as STUB.
➔ The dummy program is written by developer in XML language.
2. Bottom -up approaches:
➔ When we have sub- module but we don’t have a main module then bottom-up approaches are
going to test.

➔ The developer is going to create one dummy program for main – module. This dummy program is
known as Driver.
➔ The dummy program is written by developer in XML language.

3. Bi-directional approaches (sandwich approaches)

➔ Bi-directional approaches are also known as sandwich approach.
➔ Bi-directional approaches are the combination of Top-down approach & Bottom -up Approach.
➔ When we want to check the functionalities of main module but don’t have sub module then we
used “STUB Program”.
➔ When we want to check the functionalities of sub module but don’t have main module then we
used “DRIVER Program”.

Zero-Level Testing:
1. Zero level testing is also known as smoke testing.
2. Zero level testing is also known as build acceptance testing.
3. After integration testing is done, we start for zero level testing.
4. Database analyst (DBA) creates the test environment for zero level testing.
5. Once testing environment is ready, tester is going to do testing & check that whether the system is
generates desired output or not.
6. In zero level testing tester do testing for:
a. Basic core functionalities:
In basic core functionalities, we are going to check button, icon’s etc.
b. Tab Validation:
In tab validation, if we enter any values in tab by using on screen keyboard or physical keyboard.
Those characters number and symbols should get generated in tab.
c. Link Validation:
In link validation we are going to check sequence of interlink page get tested.
Ex: if user click on flight icon, then flight information page should be open. In make my trip
application.
d. Page validation:
It is also called as page navigation testing.
 In that we are click on Next or Back button (→, ) then page should navigate front & back.
e. GUI Testing:
GUI stands for graphical user interface.
In this testing tester check, whether the page is displayed correctly or not.
Images are visible clearly on page or not. This validation of visualization is called as GUI testing.

System and Functional Testing:

System & functional testing is performed by BBT (Black box testing).
Both the scenarios are get tested in system & functional testing. i.e., positive & negative
scenarios.
In system and functional testing, we check internal & external functionalities.

Functional Testing:
In functional testing we are going to check internal functionalities depends upon external
functionalities.
There are six coverages which comes under functional testing.
1. Behavioral Coverage:
In these coverages we check behavioral and properties of the object.
Ex: properties of check box i.e., check or uncheck like radio button.

2. Input Domain Coverages:

In input domain coverages we are going to check type and size of the inputs.
Type: Data types of the input’s like: int, char, string.
Size: size of the particular input like text box.
Ex: mobile number of the field.
Size: size is 10 digits
Type: type is int.

***imp***
Input domain coverages contain two types:
BVA: Boundary Value Analysis
ECP: Equivalent Class Partition.

BVA:
In BVA we check’s size of the object.
We are going to check how our system is working when we insert the
boundary values.
Formulas for BVA is:
a. MIN
b. MAX
c. MIN-1
d. MIN+1
e. MAX-1
f. MAX+1
EX: suppose number field is accepting number from one to hundred.
So, Boundary values is: by using formula
Min=1
Min-1=1-1=0
Min+1=1+1=2

Max=100
Max-1=100-1=99
Max+1=100+1=101

From the Above formula we will get boundary values is 0,1,2 And
99,100,101.
ECP: Equivalent Class Partition:
It maintains data types of an object.
Ex: In text box we should accept 4 to 6 characters.

BVA ECP ECP

Size Invalid Valid
Min=4 valid
Max=6 valid
 Min-1=3 invalid a-z
A-Z
Min+1=5 valid 0-9 Special Symbols
spaces (-)
Max-1=5 valid
Max+1=7 invalid

Ex:
1. we need to check 100 to 500 numbers for text box. Then we are going to create equal
classes and gives random inputs to the text box
2. If that text box is accepted random values for the particular class, then we can say that
whole class is passed.
3. If that text box is not accepted random values for the particular class, then we can say that
whole class is failed.

3. Error Handling coverages:

1. In this coverage we are going to checking whether system showing error messages or
not.
2. Mobile number filled should accept 10 digits if user insert less than 10 digit or more than
10 digits, then system show error or error message visible to user.

4. Back- end Coverages:

In back-end coverages we are going to check whether the entered information from the user
get’s stored in database or not.
Also we are check whether data get fetched from DATABASE or NOT.
5. Service-Level Coverages:
In this we are going to check sequence & functions of module on the basis of functional flow
diagram
We are checking working of system as per functional flow diagram or not.
Ex:

6. Calculation base coverage:

We check arithmetic operation.
It includes Addition, Subtraction, Multiplication, Division
Ex:
 Functional Testing Type:
1. Unit Testing
2. Integration testing
3. Smoke testing
4. Sanity testing
5. UAT
6. Regression testing
Non-Functional Testing:
1. In non-functional testing we check whether the application is running on particular browser or
operating system.
2. Process of checking external functionalities
3. Ex: O.S. or Browser

1. Recovery Testing (Reliability Testing)

➔ Recovery testing is also known as reliability testing.
➔ Recovery testing is the process of checking the whether the system is able to recover from from
abnormal situation to normal situation.
➔ The recovery requirements are given by the customers.
➔ Customers can give the requirements that he wants then that system should recover from at that
point or from a starting point.
➔ Ex: when we accessing google page & suddenly internet connection lost, then google shows that
you are offline and whenever connection resume page which we were accessing is shown by
google.
➔ Ex: when we buying something from the amazon after entering address, we get redirect to the
payment page & suddenly application crush and when we reopen the application we have to
start again from the cart.

2. Inter- System Testing:

➔ Process of checking whether our application is able to sharing the data to other application.
➔ This data communication is happened through XML language.
➔ This type of testing is mostly used in service-based organization & product-based organization.
➔ Ex: suppose we have to make payment for JIO number from Paytm application then Paytm
fetched the information from JIO application. This data sharing gets decided in inter- system
testing.
➔ Ex: example of inter system testing is Bluetooth, Phone pay, Google pay.

3. Installation Testing:
➔ Process of checking installation of our build with existing software into customer life
configuration or user expectation platforms.
➔ When tester installed application, it should create shortcut on desktop.
Set up program execution:
a. To check whether package have all files.
b. To check whether all driver present or not.
c. To check installation of execution file.

Easy Interface:
a. Interface should be user friendly.

Disc Space:
1. Any application requires disc spaces at a time of installation
2. Tester check whether disc spaces is available or not.
3. If there is insufficient disc space then error should be display. i.e., insufficient disc space.

Check Uninstallation:
1. To check whether application can be uninstalled from the system or not.

4. Globalization Testing (Multi language testing):

1. Globalization testing is also known as multilanguage testing.
2. Process of checking whether our application supports different- different languages or not.
3. 2. In globalization testing we check Multilanguage’s features.
4. Mostly service base & product base organization is used globalization testing.
 5. Whenever user Changes languages, languages should be change but number should be in English.
6. In the globalization testing we are going to check the only word letter should be change, but U.I. must
be same & number also should be same.

Application/Software used for Globalization Testing:

1. Google Translator
2. IBM Watson
3. Microsoft Bing Translator

5. Compatibility testing (Portability Testing):

1. Compatibility testing is also known as portability testing.

2. Process of checking whether the build is compatible to different different browser or not.
3. Mostly this type of testing is done in service base organization
4. There are two types of compatibility testing:
Sr No. Forward Compatibility Testing Backward Compatibility Testing
1. If the build is correct but operating system or browser If the O.S. or browser is ok but build do not work properly then it
do not work properly then it is called as forward is called as backward compatibility testing
compatibility testing
2. Less Error in Forward compatibility testing More Error in backward compatibility testing

➔ Generally, we are involved in browser compatibility testing

➔ Browser compatibility testing are two types.

Cross browser compatibility testing Version compatibility testing

It is the process in which tester test the build on different – It is the process in which tester test the build on different –
different browser like: google chrome, Fire fox, internet Explorer different version of same browser.
etc.

Sanitation Testing (Garbage Testing):

➔ Sanitation Testing is also known as Garbage Testing.
➔ Black box tester is involved in this testing.
➔ In this testing we are going to check extra features which are not mentioned in the customer
requirements.
 ➔ When we found any extra features in the build/application we mark as defect & developer have
to eliminate that extra feature.

➔ Example: Suppose any project is going on in the customer requirement and customer want that
below each object there should be a prize like Rs. 400 but developer did Rs. 400.000# This # is the
extra features.

Parallel Testing (Comparisons Testing):

➔ Parallel Testing is Also known as comparison testing.
➔ In this testing we are going to compare our product with other product.
➔ Ex: 1. in a market two mobile companies, like Redmi and Real me compare to each other’s.
Ex: 2. Phone -pe & Google pay.

Usability Testing (Accessibility Testing):

➔ Usability Testing is also called as Accessibility Testing.
➔ In this testing we are going to check whether our build is user friendly or not.
➔ Usability testing is performed by BBT.
➔ For usability testing BA is going to make Test cases as per user’s aspects like Design, color.
➔ For usability testing we used web accessing toolbar. (WAT)
➔ In accessibility testing we do test on new module.
➔ Ex: For user friendless:
➔ In yahoo mail there is a sign-up tab at upper corner and whole page is filled with advertisement
so it is not a user friendly.

➔ In Gmail sign up page and sign in page is at the middle of the page and no advertisement so it is
user-friendly.
 WAT: - Web Accessing Toolbar:
➔ For usability testing business analyst (BA) is write the test cases. Like: -

➔ When we click on sign up button it should open sign up. If we click on sign in then it should open
sign in page.
➔ When we click on name, name tab should be focus.
➔ Execution of these test cases happen in WAT. (Web accessing Tollbar)

Types of Usability Testing:

GUI testing
Manual support testing.
GUT Testing:
➔ GUI testing stand for graphical user interface.
➔ Easy to use: for blind person if he/she click on any tab, system should be given voice feedback
➔ Also, we are going to check images are clearly visible to user or not.
Manual support testing (Regular Expression Testing):
➔ In this testing we are going to check processing of context sensitives to the user manual input.
➔ Manual support testing is also known as Regular expression testing.
➔ Ex: There is a uber app in which we have to enter source & destination, then when we click “p” in
source tab it shows all the location suggestion starts with “p”.

Security Testing:
➔ Process of checking privacy to the user operation.
➔ Both tester & developers are involved in security testing.

Types of Security Testing:

1. Authorization Testing:
→Process of checking whether are user (person) is authorized or not.
→Authorized person is the registered person.

2. Access Control:
Process of checking whether authorized person has permission to access specific operation
or not.

3. Encryption And Decryption:

Process of checking whether the data is converting from encryption to decryption

Performance Testing:
➔ Process of checking speed of processing of our build.
➔ Performance test engineer are involved in performance testing.
➔ Load runner Tool is going to used for checking the performance of the software.

Types of Performance testing:

Load Performance Testing:
➔ suppose the capacity of the software (application) is 100 users and if when more than 100 users
(110 users) is going to use then the software goes into heavy load condition.

Stress Performance Testing:

➔ Stress is nothing but behavioral of the system. When we increase the load more than
expectation level of the system then system is goes in stress condition is known as stress
performance testing.

Testing Terminology:
1. Exploratory Testing:
We are not aware about the application knowledge but we have the test cases and the test
data then we are going to perform exploratory testing.
Ex: before launching the google pay and phone pe if we want to send some amount to our
relatives at that time we used our relatives name, bank branch name, bank account number,
bank IFSC code etc. So, in this example we used all information as test data.
2. Adhoc Testing:
We are aware about the application knowledge but we don’t have test cases and test data
then we are going to perform Adhoc testing.
Types of Adhoc Testing: a. Buddy Testing→ 1 developer + 1 Tester➔Same Modules.
B. Pair Testing→ Two Tester➔ Same Module
 C. Monkey Testing:
In monkey testing we are going to gives random inputs to our application and check whether
our application is breaking or not.

Manual Testing Part-2 (Depth Part of Testing):

Depth Part Of Testing:

Test Policy:
➔ Test policy is a company level document.
➔ Test policy is prepared by CEO of the company.
➔ Using test policy documents, they are going to decide objective of the project. i.e., how we can
earn more money from which domain
 ➔ Domain like: Telecom domain. Investment banking domain, E-commerce domain, Health Care
domain, Insurance
Test Strategy:
➔ Test Strategy is a project level document.
➔ Test strategy is prepared by project manager.
➔ By using test strategy document project manager is going to decide how we achieve the strategy
of the project.
➔ Ex: a. Whether it is implemented automation or not.
➔ b.. K.T. process (if new joiner joins in the teams)
➔ c. Risk management
➔ purpose of the test strategy documents is to clarify, identify, the major task & challenges of the
test projects.
➔ Test strategy documents contains different types of approaches like:
1. Scope & Objectives
2. Business Issue
3. Test Responsibility Matrix
4. Test deliverable
5. Roles & responsibility
6. Communication status reporting
7. Defect tracking & Reporting
8. Implementation of Automation
9. Test Measurement
10. Risk and Mitigation(solution)
11. K.T. Session/ training session

1. Scope And Objectives:

➔ Project manager is going to decide scope and objectives of the particular project.
➔ Scope: In scope what are the functionality we are going to include in our projects.
➔ Objective: In Objective what are the functionality which are going to include in our project are
working fine or not.

2. Business issue:
➔ In business issue they are going to analyze the cost depending upon the domain of the project
and resources required for the project.
➔ 75% cost invest for the developer and 25% for the tester. i.e. 3:1 ratio for DEV: TESTER

3. Test responsibility matrix (TRM):

➔ TRM is a mapping between testing types vs Development stages. Or testing issue or testing
factor.
➔ TRM show who is doing what in a project.
➔ Development stages like Information gathering, BA, Design, Coding, Testing, Maintenance.
➔ Testing issue or testing factor are: Authorization, Access control.
➔
Sr No. Test Factor Testing
1 Authorization Security Testing
2 Access Control Security Testing
3 Correctness Functional testing
4 Continuity of processing WBT Integration Testing
5 Coupling Non-Functional – Inter System
6 Easy to use Usability Testing
7 Easy to operate Installation Testing
8 File integrity Recovery/reliability
9 Performance Performance testing
10 Portability Compatibility Testing
11 Service level Service Level
12 Maintenance Maintenance
13 File Reliability Recovery/Reliability Testing

4. Test Deliverable:
➔ We are going to provide testing related documents to the client.
➔ Ex: Test cases, Test Status report, Test Defect Report

5. Roles & Responsibility:

➔ Name of the task & who is going to perform that particular task.

6. Communication Status Reporting:

➔ How is the communication is going on in the team is taken care by the project manager?
➔ Which types of meeting is required is approve by the project manager?

7. Defect Tracking & Reporting:

➔ In this Project manager is check the proper communication between development team testing
team.
➔ To track the defect, defect management team conduct the defect tracking call.
➔ In this meeting development team & testing Team is involved.
➔ In that meeting as a tester, we are going to decide which defect should we fixed first.
➔ Also, they are going to discuss if any defect is invalid, then they are going to reject that defect.

8. Implementation of Automation:
➔ They are (Project manager) is going to decide whether to implement automation or not.
➔ If automation is implemented then benefits are:
a. High accuracy b. Less Time c. Less resources d. Less Human Errors

b. Test measurement:
➔ We are going to measure the test quality by using DRE.

DRE=A/(A+B)

c. Risk and Mitigation:

➔ Risk means problem in a project
➔ Mitigation means solution of that problem.

d. KT session/ Training Session:

➔ Give KT to new joiner in a project.
➔ When KT session is arranged by the team is called as training session.

Test Methodology:
➔ Test Methodology is a project level document.
➔ Test methodology is prepared by project manager.
➔ Project manager is deciding which type of test and test factor is used in our project.
➔ Project manager used test strategy document to finalize the test methodology.
 STLC: Software Testing Life Cycle:
➔ STLC stands for software testing life cycle.
➔ STLC is a subset of SDLC.
➔ SDLC contain whole process of software development however STLC contain only testing process.
➔ STLC helps to make the software as a defect free.
➔ Phases of STLC are:

1. Test Initiation Testing (Requirement phase) :

➔ In this phase project manager is concentrating on the a. requirement of the project i.e., domain
of the project. B. Scope of the project c. risk involved in the project.
2. Test Plan:
➔ Test plan is a project level document.
➔ Test plan is prepared by Team leader.
➔ In test plan Team Leader mainly focus on:
a. Job allocation: Job location is nothing but what to test and how to test.
b. Resource Allocation: In resource allocation we are going to identify what type of
resources are required for the project like: Manual Resource, Automation Resource & who
has knowledge about manual and automation and database.
 c. Estimation: In estimation we are going to decide release date of our project that mean’s
start and end date of our project.

3. Test Case Scenarios:

➔ Test case scenarios is a testing level documents.
➔ Test scenarios are prepared by Test Engineer (Tester) on the basis of requirements.
➔ Test Scenario is nothing but what to Test.
➔ On the basis of one test scenario, we can prepare multiple test cases.

4. Test Case Design:

➔ Test case Design is a testing level documents.
➔ Test case Design are prepared by Test Engineer (Tester) on the basis of Scenarios.
➔ Test Design is nothing but how to Test any requirements.
➔ On the basis of one test case Design, we cannot prepare multiple test Scenarios.

5. Test Case Execution:

➔ Test case execution is executed by test engineer.
➔ In test case execution after executing the test cases we check how many tests cases pass, fail,
skip, block.
6. Regression Testing:
➔ Regression testing is performed by Test Engineer.
➔ If we add any new functionalities in our application then we are going to check whether added
functionalities do impact on existing functionalities or not is nothing but regression Testing.

7. Test Summary Report:

➔ Test Summary is a testing level documents.
➔ Test summary report is prepared by Test Engineers.
➔ Test summary report is a one type of documents in STLC.
➔ Test summary reports contains summary of all the test activities like:
a. How many test cases are executed/run?
b. How many test cases are not executed/ not run?
c. How many test cases are failed?
d. How many test cases are Skipped?
e. How many test cases are blocked?

8. Test Closure Report:

➔ Test closure report is testing level document.
➔ Test closure report is prepared by Test Lead/Team Lead.
➔ In test closure report team leader check whether all process is correct or not.
➔ Test closure report is a final report from testing team.
 Comparison Between SDLC and STLC

Sr No. SDLC STLC

1 SDLC stands for software development life cycle STLC stands for software testing life cycle
2 SDLC is a superset of STLC STLC is a subset of SDLC
3 SDLC have phases as Information gathering, BA, Design, STLC have phasers as Test initiation testing, test plan, test
Coding, Testing, Maintenance case scenarios, test case design, test case execution,
regression testing, test summary reports, test closure
reports.
4 SDLC covers the entire life of the software STLC covers only testing life cycles.
5 Development teams starts developing the software in the Test engineer work on all testing activities in STLC.
SDLC.
6. SDLC helps in developing the good quality of the software helps in making the software defect free.
7 SDLC phases are completed before the STLC STLC phases are perform after SDLC.

Defect Life Cycle/Bug Life Cycle:

➔ Defect life cycle is also known as bug life cycle.
➔ Defect life cycle is a set of status in which bug travels from one state to other states. (Travelling
throughout its whole journey.)
➔ The main purpose of the defect life cycle is to show the current status of the defect.

New:
➔ When tester found any defect during the testing then tester marks status as “New”

Open:
➔ Open status is an intermediate state between New and Fix.
➔ Developer Starts analyzing and work on the fixing the defect and developer mark states as
“Open”.
Fixed:
➔ Developers makes necessary changes to fix defects.
➔ After fixing defects, developers mark states as fixed.

Retest:
➔ Re-Testing is done by Tester.
➔ By Re-testing tester check whether the defect is fixed or not. Then tester mark those states as Re-
Test.

Closed:
➔ If defect (bug) is not longer exits then tester marks those states as Closed.

Re-Open:
➔ After doing some changes for fixing defects or after fixing defects still defects are there then
tester mark those states as Re-Open.

Rejected:
➔ If Defect is not a valid defect, then developer mark those state as rejected.

Differed:
➔ When defect is a valid defect, but due to low priority, and lack of time and has less time to deliver
a sprint. we are not fixing that defect in current sprint we fix it in next sprint. Then developer
mark those defects as Differed.

Duplicate:
➔ After fixing defect, some defect occur twice then developer mark those states as duplicate.

Review:
A review is a systematic examination of a document by one or more people with the main aim of
finding and removing error early in the software development life cycle.
Review are four types:

1. Self-Review:
➔ Self-review is done by tester. (Himself)
➔ To check whether I missed any test cases or not.
➔ Also, we are going to check all the test cases are as per customer requirements or not.

2. Peer review:
➔ The test cases which is written by me. And review by my colleagues is known as peer review.
➔ Colleagues of my team check all the test cases are as per customer requirements or not.
 3. Internal Review:
➔ In internal Review BA, Product Owner, Development Team, Testing Team Are involved.
➔ BA or product owner is responsible person to review our test cases in internal review.

4. External Review:
→external review performed by UAT team or Customer.

RTM (Requirements Traceability matrix):

➔ RTM stands for requirement traceability matrix.
➔ RTM prepared by Test Engineer.
➔ RTM is a mapping between customers requirement vs prepared test cases.
➔ By using RTM, we are going to check whether any requirements are missing in our documents or
not.
➔ With the help of RTM, we prevent the defect leakage.
➔ There are two types of RTM
a. Forward Requirements Traceability Matrix:
Mapping between customer requirement and prepared test cases.
b. Backward Requirements Traceability Matrix:
Mapping between prepared (Required) test cases vs Defect.
c. Bi-Directional Requirements Traceability Matrix:
Bi-directional requirement traceability matrix is a combination of both i.e., forward and
backward requirement tractability matrix.

Comparison Between TRM And RTM

Sr TRM RTM
No.
1. TRM stand for Test Responsibility Matrix RTM stand for Requirement traceability matrix.
2. TRM prepared by project manager RTM prepared by Test Engineer.
3. TRM is a mapping between development stages vs Testing RTM is a mapping between customer requirement vs prepared
Factors test cases.
4. By using TRM Project manager is going to choose which By using RTM, we are going to check whether any requirement
testing factor and which testing is performed. is missing in our prepared test cases or not.

Test Case Format:

Sr Requirement Requirement Test case Test Test case Test Expected Actual Performed Comments
No. ID Description Scenarios Case Description Steps Result results By
ID

Traceability Matrix:
Sr Requirement Requirement Test case Test Test case Test case Defect Defect
no. ID Description Scenario case ID Description status ID Status

BBT Test Case Design Techniques:

➔ Test case design techniques is nothing but to check the functionalities step by step.
➔ There are five types of BBT test case design techniques
 1. BVA
2. ECP
3. Error Guessing
4. Decision Table Testing
5. State Transition Diagram

Seven Principle of Software Testing:

1. Testing shows presence of defect:
➔ Its helps to finding the defects.

2. Early Testing:
➔ Early testing means testing starts from requirement stage.

3. Testing is Context Development:

➔ Different different websites are tested differently.
➔ Ex: Banking site tested differently than shopping site.

4. Exhaustive testing is impossible:

➔ i.e., impossible to test all possible input combination of data & scenarios.

5. Defect Clustering:
➔ Equal distribution of bugs across the module is not possible.
➔ Defect may be cluster in small piece of code/ module.

6. Pesticide paradox:
➔ Executing same test cases again and again will not helps to identify more bugs. Instead of that
review them regularly and modify it if changes required

7. Absence of errors fallacy:

➔ Finding and fixing defects does not help if the system build is unusable and does not fulfill the
user’s needs and requirements.