====================================================

Tutor: Pavan Kumar

Reference: Youtube
Course: Manual Testing (Full Course)
Content: Manual Testing - Theory
(Manual Software Testing Training Part-1 to Part-9)
====================================================
1. Document prepared by
a. Rajat Verma
i. Github Profile: https://github.com/rajatt95

ii. Github Page: https://rajatt95.github.io

iii. LinkedIn: https://www.linkedin.com/in/rajatt95

iv. Topmate: https://topmate.io/rajatt95

v. Telegram: https://t.me/rajatt95

vi. Instagram: https://www.instagram.com/rajattvermaa95

vii. Youtube: https://www.youtube.com/@rajatt95

—------------------
2. Test Automation Frameworks available on Github
a. WEB

i. Selenium WebDriver + Java

ii. Cypress + (Javascript and Typescript)

iii. Playwright + (Javascript and Typescript)

b. MOBILE

i. Appium + Java
c. API

i. Rest Assured + Java

ii. Requests + Python

-------------------------------------------------------------------------------------------------------------------------------

1
—------------------
3. Documents:

a. Github repository: https://github.com/rajatt95/Documents

b. Google Drive:
https://drive.google.com/drive/folders/1tne9pZjgWvfrS0l9tVHs6k1jnQHpTLoA

4. Last worked on this Document:

a. Dec 26, 2022

5. Learnings from Tutor (Code Repository):

a. This course
i. https://github.com/stars/rajatt95/lists/youtube-pavan-manual-testing
b. Other course(s)
i. https://github.com/stars/rajatt95/lists/youtube-pavan-kumar

—------------------
6. Course content:

a. Manual Software Testing Training Part-1

i. What is Software?
ii. Types of Software?
iii. What is Software Testing?
iv. What is Software Quality?
v. Project vs Product
vi. Why do we need Testing?
vii. Error, Bug & Failure
viii. Why the software has bugs?

—------------------

-------------------------------------------------------------------------------------------------------------------------------

2
—------------------
b. Manual Software Testing Training Part-2
i. SDLC
ii. Waterfall Model (Linear Model)
iii. Spiral Model (Iterative model)
iv. V-Model or VV-Model
v. White Box & Black Box Testing
vi. Static Testing & Dynamic Testing
vii. Verification & Validation

c. Manual Software Testing Training Part-3

i. Static Testing Techniques
ii. QA & QC & QE (Quality Assurance, Control, Engineering)
iii. Different Levels of Sofware Testing
1. Unit Testing
2. Integration Testing
3. System Testing
4. User Acceptance Testing

d. Manual Software Testing Training Part-4

i. System Testing Types
ii. Functional Testing
1. GUI Testing
2. Functional Testing
a. Object Properties Testing
b. Database Testing (Back end Testing)
c. Error Handling
d. Calculations/Manipulations Testing
e. Links existence and execution
f. Cookies and Session
iii. Non-Functional Testing
1. Performance Testing
a. Load Testing
b. Stress Testing
c. Volume Testing
2. Security Testing
3. Recovery Testing
4. Compatibility Testing
5. Configuration Testing
6. Installation Testing
7. Sanitation/Garbage Testing

—------------------
-------------------------------------------------------------------------------------------------------------------------------

3
—------------------
e. Manual Software Testing Training Part-5
i. Regression Testing
1. Unit Regression Testing
2. Regional Regression Testing
3. Full Regression Testing
ii. Re-Testing
iii. Re-Testing vs Regression
iv. Sanity & Smoke Testing
v. Exploratory Testing
vi. Adhoc Testing
vii. Monkey/Gorilla Testing
viii. Adhoc Testing vs Monkey/Gorilla Testing vs Exploratory Testing
ix. Positive Testing
x. Negative Testing
xi. Positive vs Negative Test cases
xii. End-To-End Testing
xiii. Globalization/Internationalization(I18N) and Localization Testing

f. Manual Software Testing Training Part-6

i. Test Design Techniques/ Test Data Design Techniques/ Test Case Design
Techniques
1. Equivalence Class Partitioning (ECP)
2. Boundary Value Analysis (BVA)
3. Decision Table-based testing
4. State Transition
5. Error Guessing

g. Manual Software Testing Training Part-7

i. STLC (Software Testing Life Cycle)
1. Requirements Analysis
2. Test Planning
3. Test Design
4. Test case Development
5. Environment Setup
6. Test Execution
a. Bug/Defect Reporting and Tracking
7. Test Closure

—------------------

-------------------------------------------------------------------------------------------------------------------------------

4
—------------------
h. Manual Software Testing Training Part-8
i. Test Plan
ii. Use case, Test scenario & Test case
iii. Use case vs Test case
iv. Test case vs Test scenario
v. Test Suite
vi. Test case Template
vii. Requirements Traceability Matrix (RTM)
viii. Test Environment
ix. Test Execution
x. Defects/Bugs
1. Report Contents
2. Classification
a. Severity
b. Priority
3. Defect Resolution

i. Manual Software Testing Training Part-9

i. Defect/Bug life cycle
ii. Test Cycle Closure
iii. Test Metrics
iv. QA/Testing Activities
v. Principles of Software Testing

—------------------

-------------------------------------------------------------------------------------------------------------------------------

5
—------------------

1. Learnings from Course (Youtube - Pavan Kumar - Manual Testing (Full course))

a. Learning (Module/Phase wise)

i. Software Testing concepts (Theory - What to Test?)
1. What is Software?
a. It is a collection of computer programs that help to
perform a task.
i. Programs - Instructions are provided for the software
2. Types of Software?
a. System (OS, Device Drivers, Utilities)
b. Programming (Compiler, Debugger, Interpreter)
c. Application (Desktop, Web, Mobile)
3. What is Software Testing?
a. It is a part of the Software Development process.
b. It is an activity to detect and identify defects in the
software.
c. The objective of Testing is to release quality products to the
client.
4. What is Software Quality?
a. Quality is Customer justification
i. How well the software or product is working
5. Project vs Product
a. Specific customer requirements - Project.
b. Multiple customers based on the market requirements -
Product.
6. Why do we need Testing?
a. Bug-free
b. Delivered on-time.
c. Within Budget
d. Meets Requirements/Expectations
e. Maintainable
7. Error, Bug & Failure
a. Error - Incorrect human action
i. Environment - DEV (Identified by Developer)
b. Bug - Deviation of Actual and Expected
i. Environment - TEST (Identified by Tester)
c. Failure - Deviation identified by End User
i. Environment - PRODUCTION

—------------------

-------------------------------------------------------------------------------------------------------------------------------

6
—------------------
8. Why the software has bugs?
a. Miscommunication or No communication
b. Software Complexity
c. Programming Errors
d. Changing Requirements
e. Lack of skilled Testers
9. SDLC
a. It is a step-by-step process used by the Software industry to
design, develop and test the software and finally, to deliver
quality software to the customer.
b. Phases/Modules
i. Requirements Analysis
ii. Design
iii. Development/Coding
iv. Testing
v. Maintenance
10. Waterfall Model (Linear Model)
a. Every phase is dependent on the previous phase
b. Requirement changes are not allowed
c. Testing will start only after Coding/Implementation phase
11. Prototype Model
12. Spiral Model (Iterative model/ Version Control Model)
a. Testing is done in every cycle before going to the next cycle
b. Requirement changes are allowed after every cycle
13. V-Model or VV-Model
a. Testing is involved in each and every phase
Verification Validation

Checks whether we are building the Checks whether we are building the
right product. product right.

Focus is on Documents Focus is on Software

It involves Static Testing It involves Dynamic Testing

Techniques Techniques (Testing the actual
1. Review software)
2. Walkthrough 1. Unit
3. Inspections 2. Integration
3. System
4. UAT

Takes place after Verifications are

done/completed.
-------------------------------------------------------------------------------------------------------------------------------

7
—------------------
14. White Box & Black Box Testing
15. Static Testing & Dynamic Testing
16. Verification & Validation
17. QA & QC & QE (Quality Assurance, Control, Engineering)
i.
QA QC

Process related People related (Tested)

Actual Testing of the software

Involved in all phases/stages of Involved only in Testing

SDLC phase/stage of SDLC

QA is for entire SDLC QC is only for Testing phase

Focus is on building in quality Focus is on testing for quality

Prevention - Preventing Defects Detection - Detecting Defects

If we follow the process correctly,
we can prevent the Defects in future

Process oriented Product oriented

b. QE - It is a team that contains Automation Testers who are

involved in writing code
18. Different Levels of Sofware Testing
a. Unit Testing
i. A unit is a single component/module of software
ii. Unit Testing Techniques
1. Basis Path Testing
2. Control Structure Testing
3. Conditional Coverage
4. Loops Coverage
5. Mutation Testing

b. Integration Testing
i. It is performed between 2 or more modules
ii. It focuses on checking Data communication
between multiple modules
iii. It is a White box Testing technique
iv. Integration Testing
1. Developers do this at coding level
2. Testers do at the Application level
—------------------
-------------------------------------------------------------------------------------------------------------------------------

8
—------------------

v. Types
1. Incremental Integration Testing
a. Approaches
i. Top Down
ii. Bottom Up
iii. Sandwich/Hybrid
2. Non-Incremental Integration Testing
a. This is not recommended

c. System Testing
i. Testing overall functionality/features of the
application w.r.t. customers’/clients’ requirements
ii. It focuses on aspects
1. User Interface Testing (GUI)
2. Functional Testing
3. Non-Functional Testing
4. Usability Testing

d. User Acceptance Testing

i. Conducted by customers before accepting the
software
ii. Types
1. Alpha Testing
2. Beta Testing

19. System Testing Types

20. GUI Testing
a. Graphical User-Interface Testing
b. It is a process of testing the UI of the application
c. GUI includes elements
i. Textboxes, Links, Checkboxes, Buttons, Colors, Images
d. The End User will interact with the application using the
Front end and all the operations will happen in the Back
end

—------------------

-------------------------------------------------------------------------------------------------------------------------------

9
—------------------
21. Functional Testing
a. Functionality
i. The behavior of the application
b. Types
i. Object Properties Testing
1. Checks the property of the objects
a. Enable, Disable, Visible, Focus
ii. Database Testing (Back end Testing)
1. This is to ensure that the UI operations are
making the required changes in the Database
or not
a. This is Grey Box Testing (a
combination of Black box and white
box)
iii. Error Handling
1. Verifying the Error messages while
performing incorrect actions on the
application
iv. Calculations/Manipulations Testing
v. Links existence and execution
vi. Cookies and Session
1. Cookies are created on the Client side
2. Sessions are created on the Server side

22. Non-Functional Testing

a. Focused on Customer expectations instead of Customer
requirements
b. Performance Testing - Speed
i. Load Testing (Gradually increasing/decreasing the
load)
ii. Stress Testing (Suddenly increasing/decreasing the
load)
iii. Volume Testing (Check how much data an application
is able to handle)
c. Security Testing
i. Authentication
ii. Authorization/Access Control
d. Recovery Testing
e. Compatibility Testing
f. Configuration Testing
g. Installation Testing
h. Sanitation/Garbage Testing
-------------------------------------------------------------------------------------------------------------------------------

10
 23. Regression Testing
a. Unit Regression Testing
b. Regional Regression Testing
c. Full Regression Testing
24. Re-Testing
a. The tester verifies the Bug fix only
25. Re-Testing vs Regression
a. Regression →
i. Validate the whole application (The changed part
should not affect the unchanged part)
b. Re-Testing →
i. The tester verifies the Bug fix only
26. Sanity & Smoke Testing
27. Exploratory Testing
28. Adhoc Testing
29. Monkey/Gorilla Testing
30. Adhoc Testing vs Monkey/Gorilla Testing vs Exploratory Testing
31. Positive Testing
a. Testing the application with valid inputs
32. Negative Testing
a. Testing the application with invalid inputs
33. Positive vs Negative Test cases
34. End-To-End Testing
a. Testing the overall functionalities of the system that
includes data integration among all the modules.
35. Globalization/Internationalization(I18N) and Localization Testing
a. Globalization
i. Application is supported globally
1. Has the support of multiple languages
36. Test Design Techniques/ Test Data Design Techniques/ Test Case
Design Techniques
a. Equivalence Class Partitioning (ECP)
i. Partition/Divide/Classify/Categorize Data into
various classes
1. Select the Data according to class
b. Boundary Value Analysis (BVA)
i. Focus is on the boundaries of the input
c. Decision Table-based testing
i. The decision Table is also known as Cause-Effect
table
ii. Conditions and Actions are considered
—------------------

-------------------------------------------------------------------------------------------------------------------------------

11
—------------------
d. State Transition
i. Used when the application has multiple states
ii. Input conditions are changed on the basis of
application state
1. Positive and Negative input values → To
evaluate the application behavior
e. Error Guessing
i. Based on Testers’ prior experience and Analytical
skills
1. No specific rules
ii. Example
1. Submit the form (Without filling in
mandatory details)
37. STLC (Software Testing Life Cycle)
a. Requirements Analysis
b. Test Planning
c. Test Design
d. Test case Development
e. Environment Setup
f. Test Execution
i. Bug/Defect Reporting and Tracking
g. Test Closure
38. Test Plan
39. Use case, Test scenario & Test case
a. Use case
i. Actor -> User
ii. Action -> Operation
iii. Goal -> Outcome
b. Test scenario
i. What to Test?
ii. 1 test scenario may have n no. of test cases
c. Test case
i. How to Test?
ii. Contains
1. Steps
2. Actual Result
3. Expected Result
40. Use case vs Test case
41. Test case vs Test scenario
42. Test Suite
43. Test case Template
44. Requirements Traceability Matrix (RTM)
-------------------------------------------------------------------------------------------------------------------------------

12
 45. Test Environment
46. Test Execution
47. Defects/Bugs
a. Report Contents
b. Classification
i. Severity
ii. Priority
c. Defect Resolution
48. Defect/Bug life cycle
49. Test Cycle Closure
50. Test Metrics
51. QA/Testing Activities
52. Principles of Software Testing
—------------------

====================================================

-------------------------------------------------------------------------------------------------------------------------------

13
-----------------------------------------
========1_Manual Software Testing Training Part-1==========
-----------------------------------------

1. Learning (Module/Phase wise)

a. Software Testing concepts (Theory)
i. Very basics
ii. What to Test?
b. Testing Project (Practical)
i. How to Test?
c. Agile process
d. JIRA
i. To Track all activities of project
1. From Requirement Gatherings to Sowftare Delivery to the Customer
—------------------

1.
a. Module-1
i. Test Closure
ii. Test Metrics

—------------------
1. The tutor will share SQL videos
a. After completing the Manual Testing basics
—------------------

-------------------------------------------------------------------------------------------------------------------------------

14
—------------------
1. What is Software?
a. It is a collection of computer programs that help to perform a task.
i. Programs
1. Instructions are provided to the software
b. A Mobile is a machine that has Software
i. WhatsApp
ii. Maps
—------------------
2. Types of Software?

a. System software
i. Used to run the system
ii. Example
1. Device Drivers
a. Printer
b. Keyboard
i. If you have connected your keyboard to the computer,
How will the computer be able to identify the
instructions coming from Keyboard?
c. Bluetooth devices
2. Operating Systems
a. On top of the OS, we install other software like
i. MS Office
ii. Outlook
b. OS works as a base
c. OS types
i. Windows
ii. MAC
iii. Linux
3. Servers
4. Utilities

b. Programming software
i. Compilers
1. When we write the code, how can your machine understand that
code?
There is something working internally to understand the inputs and
give the output.
ii. Debuggers
iii. Interpreters
—------------------

-------------------------------------------------------------------------------------------------------------------------------

15
—------------------
c. Application software
i. Desktop applications
1. We can install these applications on our laptop/Desktop
a. Outlook
b. MS Office
c. Browsers
i. Chrome
ii. Firefox
iii. Edge
d. Calculator
e. Paint
ii. Web applications
1. We need the Internet and a Browser to access these applications
2. Actual applications are running on the remote servers
a. https://www.google.co.in/
b. https://www.flipkart.com/
c. https://www.youtube.com/
iii. Mobile applications
1. 2 OS
a. Android
i. Playstore
b. iOS
i. Appstore
2. We can download the applications from these stores
a. Applications
i. LinkedIn
ii. WhatsApp
—------------------
1. What is Software Testing?

a. Example -1
i. You buy a mobile
ii. You install some applications
iii. You start using those applications
iv. But, these applications are not working properly
1. Crashing sometimes
2. Taking a very long time to start
v. How will you feel about the Buggy applications?
1. Worst
vi. Why does this happen?
1. Lack of Testing
2. Testing is not properly conducted
-------------------------------------------------------------------------------------------------------------------------------

16
—------------------
b. Example -2
i. X-Bank reaches an IT company with a specific set of requirements with
Budget and Time
1. Requirements may be
a. To automate their processes/services like
i. Fixed/Recurring Deposit
1. Create
2. Break
ii. Customer support (24*7)
2. These requirements will be reviewed by the IT team
a. Factors like
i. Budget
ii. Time
1. Will be considered for any outcome promise
ii. After all formalities,
1. IT company will
a. Develop the Sofware
b. Test the Software
i. Why?
1. To release/deliver a quality product to the
customer.
c. Deliver the Software to Bank
2. IT Team members
a. Managers
b. Designers
c. Developers
d. Testers
—------------------
c. Software Testing
i. It is a part of the Software Development process.
1. Software Development is not only about writing the code by
Developers
2. We have to understand the customer’s requirements and have to
verify that things are moving in the right direction
ii. It is an activity to detect and identify defects in the software.
iii. The objective of Testing is to release quality products to the client.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

17
—------------------
1. What is Software Quality?
a. Quality is Customer justification
i. How well the software or product is working
b. Parameters
i. Bug-free
ii. Delivered on-time.
iii. Within Budget
iv. Meets Requirements/Expectations
v. Maintainable
—------------------
1. Project vs Product
a. If the software application is developed for
i. Specific customer requirements, then, it is called Project.
1. Working for JetBlue Airlines
ii. Multiple customers based on the market requirements, then, it is called
Product.
1. Flipkart
2. WhatsApp
3. LinkedIn
4. MS Office
b. Companies
i. Service-based
1. TCS
2. Accenture
3. Nagarro
4. IBM
ii. Product-based
1. Google (Products - Gmail, Youtube, Maps)
2. Microsoft (Products - MS Office, WIN)
3. Oracle
—------------------
1. Why do we need Testing?
a. The objective of Testing is to release quality products to the client.
b. Quality is Customer justification
i. How well the software or product is working
c. Parameters
i. Bug-free
ii. Delivered on-time.
iii. Within Budget
iv. Meets Requirements/Expectations
v. Maintainable

-------------------------------------------------------------------------------------------------------------------------------

18
—------------------
1. Error, Bug & Failure

a. Error
i. Human mistake
ii. Incorrect human action
iii. Environment - Development (Identified by Developer)

b. Bug
i. Deviation of Actual and Expected
ii. Environment - Testing (Deviation Identified by Tester)
iii. Example
1. Login
a.
Username Password Result Result

Valid Valid Able to login PASS

Valid Invalid Able to login FAIL

Invalid Valid Able to login FAIL

Invalid Invalid Able to login FAIL

c. Failure
i. End User action
ii. Environment - Production (Deviation Identified by End User)
1. We delivered the product to the customer (We developed and tested
it)
2. And, the product is being used by customers in their environment
—------------------
1. Why the software has bugs?
a. Miscommunication or No communication
i. Business Analysts - Developers - Testers
ii. Everyone should be in sync
iii. Requirements should be very very clear
b. Software Complexity
c. Programming Errors
i. Developers’ responsibility
d. Changing Requirements
e. Lack of skilled Testers

—------------------
-------------------------------------------------------------------------------------------------------------------------------

19
-----------------------------------------
========2_Manual Software Testing Training Part-2==========
-----------------------------------------

1. SDLC
a. Life Cycle for any Product (Not specific to IT only)
i. Example - Pharmaceutical company
1. Raw materials (taken as input) -> Processing -> Release the product
2.
b. The full form of SDLC is Software Development Life Cycle
i. IT companies
1. They take customer requirements
2. Based on the requirements gathered, they design the software
3. They implement/develop the code
4. Conduct Testing
5. Release the software and deliver it to the Client

c. SDLC
i. It is a step-by-step process used by the Software industry to design, develop
and test the software and finally, to deliver quality software to the customer.

d. 3 pillars for any company

i. P - People
ii. P - Process
iii. P - Product (we deliver the software/product to the customer)

e. Phases/Stages in SDLC

i.
1. Requirements Analysis
a. Collect and understand the requirements of the customer
b. Project/Products Managers are included in this phase
c. They prepare the documents such as
-------------------------------------------------------------------------------------------------------------------------------

20
 i. SRS (Software Requirement Specification)
1. Every requirement from the customer must
be listed here
2. Design
a. Designers will design the software based on the documents
prepared in the Requirements Analysis phase
i. High-Level Design
ii. Low-Level Design
b. Example
i. Build a house
1. We prepare a blueprint
3. Development/Coding
a. Software Developers will write the different types of
programs based on the design documents
b. The design phase will work as an input for
Coding/Implement phase
4. Testing
a. Types
i. Functional
ii. Non-Functional
b. After completion of Development, Testing teams start doing
Testing for product
5. Maintenance
a. We deploy the software in the customer’s environment
b. And, the customer starts using the software
—------------------
1. All models come under SDLC
—------------------

-------------------------------------------------------------------------------------------------------------------------------

21
—------------------
1. Waterfall Model (Linear Model)

a.
i. The waterfall model is the
1. First and initial model (Software industry started)
ii. Every phase is dependent on the previous phase
1. The requirement Specification document will be the input for Design
phase
2. Design documents will be the input for the Implementation phase

b. Advantages
i. Product quality will be good
1. We have detailed documentation (Activities are documented)
ii. Since Requirement changes are not allowed, chances of finding will be less
iii. The initial investment is less since the Testers are hired at a later stage
iv. Preferred for small projects where requirements are frozen

c. Disadvantages
i. Requirement changes are not allowed
ii. If there is a defect in the requirement phase, it will be continued in later
phases/stages
iii. Total investment is more because the time taken for Re-Work on defects is
time-consuming which leads to high investment
iv. Testing will start only after the Coding/Implementation phase

—------------------

-------------------------------------------------------------------------------------------------------------------------------

22
—------------------
1. Prototype Model
a. Prototype - Blueprint of the software
b. We get the initial requirements from customer
c. We only develop the Prototype instead of the whole product
i. If the customer is satisfied, then, will for Design → Develop → Test phases
ii. Example 1 - Gmail has modules such as
1. Log in to the application
2. Compose an Email
3. Send an Email
4. Receive an Email
iii. Example 2 - Banking
1. Login
2. Check balance
3. Fund Transfer
4. Request statement
5. Add Beneficiary
d. This model comes in between Waterfall and Spiral model
i. Waterfall → Prototype → Spiral

—------------------
1. Spiral Model (Iterative model/ Version Control Model)

a.
i. Terminologies
1. Requirements Analysis
a. Planning
b. Risk Analysis
2. Design and Development

-------------------------------------------------------------------------------------------------------------------------------

23
 a. Engineering & Execution
3. Testing
a. Evaluation

ii. Software is delivered in different versions

1. All phases/stages will be followed for different versions
2. V1 -> V2 -> V3
3. In every cycle, all the stages/phases are repeated
iii. This model is recommended for Product based companies
1. We get the updates (v1 -> v2 -> v3)
2. Functionalities are added/updated

iv. Spiral Model

1. It is an Iterative model
2. It overcomes the drawbacks/limitations of the Waterfall model
a. Requirement changes are allowed in Spiral model
3. We follow the Spiral model whenever there is a dependency on
module
4. In every cycle, the new software will be released to the customer
a. Software will be released in multiple versions
i. So, it is also called Version Control model

b. Advantages
i. Testing is done in every cycle before going to the next cycle
ii. Customers will get to use the software for every module
iii. Requirement changes are allowed after every cycle

c. Disadvantages
i. Requirement changes are not allowed in between cycles
ii. Every cycle of the Spiral model looks like the Waterfall model
iii. There is no Testing in the Requirement and Design phase

—------------------

-------------------------------------------------------------------------------------------------------------------------------

24
—------------------
1. V-Model or VV-Model
a. Verification and Validation model

b.
i. In every phase of Software Development, we conduct Testing
1. SRS document will work as an input at the time of performing
System Testing
ii. Terminologies
1. BRS - Business Requirements Specification
2. CRS - Customer Requirements Specification
3. URS - User Requirements Specification
iii. BRS/CRS/URS is a document that contains the Business/Customer/User
requirements
1. The business Unit team will prepare the document
a. Those people interact with the customer → Collect the
requirements → Prepare the document
2. This document will work as an input for performing UAT (User
Acceptance Testing)
a. This document is not understandable by Technical Team
i. Developers
ii. Testers
iv. So, there is another document (SRS - Software Requirement Specification)
prepared
1. Certain diagrams are used in SRS
2. SRS is prepared by Product/Project Managers
v. Now, based on the SRS document,
1. Designers will prepare the Designs
a. HLD (High-Level Design)
-------------------------------------------------------------------------------------------------------------------------------

25
 b. LLD (Low-Level Design)
vi. To perform the Testing on these documents
1. There are Software Techniques
a. Review
b. Walkthrough
c. Inspection
i. These are
1. used to verify the documents.
2. Static Testing
a. Testing the Project related documents
b. We are not testing the software, we
are testing the documents in the form
of Review, Walkthrough, and
Inspection.
e. Validation has 4 levels of Testing
i. Unit Testing
1. Module developed by Developer → Tests the single module
ii. Integration Testing
iii. System Testing
iv. User Acceptance Testing

f. White Box Testing Techniques

i. We have to know the internal logic of the programs
ii. Has to be performed by Developers
1. Unit Testing
2. Integration Testing

g. Black Box Testing Techniques

i. Don’t need to be skilled in programming
ii. Testers have to check the
1. Functionalities
2. Workflows
a. Working as per the customers’ requirements or not
iii. This has to be performed by Tester
1. System Testing
2. User Acceptance Testing

h. Dynamic Testing
i. Testing the actual software using techniques
1. Unit Testing
2. Integration Testing
3. System Testing
4. UAT
-------------------------------------------------------------------------------------------------------------------------------

26
 i. Verification vs Validation
i.
Verification Validation

Checks whether we are building the Checks whether we are building the
right product. product right.

Focus is on Documents Focus is on Software

It involves Static Testing It involves Dynamic Testing

Techniques Techniques (Testing the actual
4. Review software)
5. Walkthrough 5. Unit
6. Inspections 6. Integration
7. System
8. UAT

Takes place after Verifications are

done/completed.

j. Advantages
i. Testing is involved in each and every phase

k. Disadvantage
i. Documentation is more
ii. Initial investment is more

—------------------

-------------------------------------------------------------------------------------------------------------------------------

27
-----------------------------------------
========3_Manual Software Testing Training Part-3==========
-----------------------------------------

1. Static Testing Techniques

a. Review
i. Conducted on Documents to ensure
1. Correctness
2. Completeness
ii. Types of Review
1. Requirements Review
a. Every requirement is listed/mentioned or not
b. To understand the requirements better
2. Design Review
a. Will be conducted on the Design documents
3. Code Review
a. Coding standards
b. Logic
4. Test Plan Review
5. Test cases Review
iii. Review can be done by anybody anytime

b. Walkthrough
i. It is an Informal Review
ii. Author (person who created the document) reads the documents/code →
Discuss with peers
1. Peers -> Team members
iii. It is not pre-planned
iv. Can be done whenever required

c. Inspection
i. It is the most formal review type
ii. At least 3-8 people will sit in meeting
1. Reader (Author of the document)
2. Writer
a. Will write the Questions/Issues/Clarifications raised by
the team members
3. Moderator (Meeting Organiser)
iii. Inspection will have a proper schedule
1. Intimated via Email to the concerned DEV/Tester
—------------------

-------------------------------------------------------------------------------------------------------------------------------

28
—------------------
1. Dynamic Testing Techniques
a. Unit Testing
i. Separate modules will be tested with the help of unit test cases written by
Developers
b. Integration Testing
i. Modules will be integrated and then, tested by Developers
ii. Will check the Data flow between the components
c. System Testing
i. Testers will do the testing
1. Deviation from Actual and Expected
2. Software should work as per the customers’ requirements
3. Functionality is working fine or not
d. User Acceptance Testing
i. By Testers and Customers
—------------------
1. QA & QC & QE (Quality Assurance, Control, Engineering)
a. QA vs QC
i.
QA QC

Process related People related (Tested)

Actual Testing of the software

Involved in all phases/stages of Involved only in Testing

SDLC phase/stage of SDLC

QA is for entire SDLC QC is only for Testing phase

Focus is on building in quality Focus is on testing for quality

Prevention - Preventing Defects Detection - Detecting Defects

If we follow the process correctly,
we can prevent the Defects in future

Process oriented Product oriented

b. QE
i. Quality Engineering
1. Developers → SDE → Write the code → To develop the software
2. Testers → SDET → Write the code → To test the software
a. Quality Engineer
b. Automation Tester
3. It is a team that contains Automation Testers who are involved in
writing the code
-------------------------------------------------------------------------------------------------------------------------------

29
—------------------
1. Levels of Software Testing

a. Unit Testing
i. A unit is a single component/module of software
ii. Unit testing conducts on a single program/module
iii. It is conducted by Developers in their environment
iv. It comes under White Box Techniques
v. Unit Testing Techniques
1. Basis Path Testing
2. Control Structure Testing
3. Conditional Coverage
4. Loops Coverage
a. For, for each, while
5. Mutation Testing
a. With different inputs
—------------------
b. Integration Testing
i. Combining multiple units/modules as a single unit
ii. Will check the Data flow and communication flow between those modules
iii. It is performed between 2 or more modules
iv. It is a White box Testing technique
v. Integration Testing
1. Developers do this at coding level
2. Testers do at Application level
vi. Types
1. Incremental Integration Testing
a. Incrementally adding the modules and testing the data flow
between modules - Modules are added one after another
b. Approaches
i. Top Down
1. Ensure that the module added is the child of
the previous module.
2. Example - Gmail
a. Compose mail –> Sent mail → Deleted
Items
ii. Bottom Up
1. Ensure that the module added is the parent
of the previous module.
iii. Sandwich/Hybrid
1. Combination of Top-Down and Bottom-Up
approach

-------------------------------------------------------------------------------------------------------------------------------

30
 2. Non-Incremental Integration Testing
a. Adding/Integrating all the modules in a single shot and
testing the data flow between modules
b. This is not recommended
i. Drawbacks
1. We might have Data flow between some of the
modules
2. If you find any defect, we can’t understand the
root cause of the defect

—------------------
c. System Testing
i. Testing the overall functionality of the application
1. Whether it is working as per customers’ requirements or not
ii. Will cover this in detail in later sessions
iii. Overview
1. Testing overall functionality/features of the application w.r.t.
customers’/clients’ requirements
a. Example - WhatsApp is an application that has features
i. Send Image(s)
ii. Send Location (Current, Live)
iii. Send Contact
iv. Update profile pic
2. It is a Black box Testing technique
3. Conducted by Testing team
4. After completion of the component and integration level, -> System
Testing has to be done
5. It focuses on aspects
a. User Interface Testing (GUI)
i. Look and Feel of the application
b. Functional Testing
i. Functionalities - Banking application
1. Login
2. Money Transfer
3. Account Statement
4. Create/Break Deposits (Fixed, Recurring)
c. Non-Functional Testing
i. Security
ii. Performance
iii. Compatibility
—------------------

-------------------------------------------------------------------------------------------------------------------------------

31
—------------------
d. Usability Testing
i. User manuals
1. Have all required content in the proper
format or not
ii. Checks how easily the end user is able to understand
and operate the application
—------------------

d. User Acceptance Testing

i. Testers + Customers (End Users)
ii. Conducted by customers before accepting the software
iii. Types
1. Alpha Testing - Customers test the application in a
development/testing environment
2. Beta Testing - Customers test the application in customers’
environment
iv. After completion of Alpha and Beta Testing, we push the application in the
production environment

—------------------

-------------------------------------------------------------------------------------------------------------------------------

32
-----------------------------------------
========4_Manual Software Testing Training Part-4==========
-----------------------------------------

1. System Testing Types

a. Testing overall functionality/features of the application w.r.t.

customers’/clients’ requirements
b. After completion of Integration Testing, System Testing starts
i. GUI Testing
ii. Usability Testing
iii. Functional Testing
iv. Non-Functional Testing
c. Testers will have a separate environment to perform the System Testing
i. QA/Testing
—------------------
1. GUI Testing
a. Graphical User-Interface Testing
b. It is a process of testing the UI of the application
c. GUI includes elements
i. Menus
ii. Textboxes
iii. Links
iv. Checkboxes
v. Buttons
vi. Colors
vii. Fonts
viii. Sizes
ix. Icons
x. Content
xi. Images
d. The End User will interact with the application using the Front end and all the
operations will happen in the Back end

-------------------------------------------------------------------------------------------------------------------------------

33
 e.
i. For testing the elements, Testers refer to Design documents
1. Design docs - Wireframes
a. CSS Properties like position, height, width, font color, font
size → Listed/Mentioned in the Wireframe
2. Before starting writing the actual code for the application, the design
of the application is prepared
—------------------
1. Usability Testing
a. Checks how easily the end user is able to understand and operate the application
—------------------
1. Functional Testing
a. Functionality
i. The behavior of the application
ii. It talks about how the features of an app should work
b. Types
i. Object Properties Testing
1. Checks the property of the objects
a. Example
i. Enable
ii. Disable
iii. Visible
iv. Focus
b. Textbox/Checkbox -> Enable/Disable
c. Radio buttons -> Can only select one at a time
d. Dropdown -> Can select only one option
—------------------

-------------------------------------------------------------------------------------------------------------------------------

34
—------------------
ii. Database Testing (Back end Testing)
1. DML operations (Data Manipulation Language)
a. SELECT
b. INSERT
c. UPDATE
d. DELETE
2. Perform the operation via UI and validate at the Database level
a. SQL -> Table
b. No SQL -> Documents
3. This is to ensure that the UI operations are making the required
changes in the Database or not
a. This is Grey Box Testing (a combination of Black box and
white box)
4. Database Testing Checklist
a. Table Level Validations
i. What kind of data can be added in Table
ii. Column Type
iii. Column Length
iv. No. of columns
v. No. of rows
b. Relation between the Tables
i. Normalization
c. Functions
d. Procedures
e. Triggers
f. Indexes
g. Views
—------------------
iii. Error Handling
1. Incorrect action on the UI should give a proper message to User
2. Verifying the Error messages while performing incorrect actions on
the application
a. Error messages should be
i. Readable
ii. User understandable/Simple language

—------------------

-------------------------------------------------------------------------------------------------------------------------------

35
—------------------
iv. Calculations/Manipulations Testing
1. Example - Banking application
a. Total Balance - 5000
b. Money transferred - 2000
c. The remaining balance should be 3000 (Total Balance -
Money transferred)
2. More Data-centric
3. Verifies the calculations
—------------------
v. Links existence and execution
1. Where exactly links are placed
2. Links are navigating to the proper page or not
3. Links
a. Internal -> Click -> Different section of same page
b. External -> Click -> Different Page
c. Broken -> Click -> No action (No target)
—------------------
vi. Cookies and Session
1. Example
a. Login - Provided credentials
b. The user is logged in
c. Browser stores some Data so that when the User access the
application again, the user does not need to provide the
credentials, he/she is already logged in
2. Cookies are created on the Client side
a. Cookies are the temporary files
b. Created by the browser while browsing the pages through
Internet

3. Sessions are created on the Server side

a. Example - Login to HDFC net banking
i. Do not do anything for 2 minutes
1. This means the User is inactive
ii. Then, try to navigate to some link
1. Your session will be expired
2. The user will be logged out and the
application will ask to Re-Login
4. Sessions are time slots created by the Server.
a. Session will be expired after some time.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

36
—------------------
1. Non-Functional Testing
a. Focused on Customer expectations instead of Customer requirements
b. Types
i. Performance Testing
1. Check the speed of the application
2. Tools
a. LoadRunner
b. JMeter
3. Parameters
a. Response Time
b. Throughput
c. Process time
d. Performance Metrics
ii. Types of Performance Testing
1. Load Testing
a. Gradually increasing/decreasing the load on the application
slowly, then, checking the speed of the application
i. 1 user
ii. 10 users
iii. 100 users
iv. 1000 users
v. 10000 users
2. Stress Testing
a. Suddenly increasing/decreasing the load on the application
slowly, then, checking the speed of the application
i. 1 user
ii. 1000 users
3. Volume Testing
a. Size
b. Check how much data an application is able to handle
—------------------
iii. Security Testing
1. How secure an application is
2. Authentication
a. Only valid Users should be able to access the application
3. Authorization/Access Control
a. Permissions to the valid user
b. Users
i. Normal
ii. Admin
—-------------------

-------------------------------------------------------------------------------------------------------------------------------

37
—------------------
iv. Recovery Testing
1. Example
a. Delete some files -> Goes to Recycle Bin
i. We can still recover these deleted files by using
Restore option
b. Gmail -> Composing an Email
i. The system got shut down
ii. We can still find our changes in Drafts section
2. Checks the system change from abnormal to normal.
—------------------
v. Compatibility Testing
1. Forward compatibility
a. V 2.0 of the software should be compatible with the devices
on which Software V 1.0 was working fine
2. Backward compatibility
a. Machine is compatible with both newer and older versions of
software
3. Hardware compatibility/Configuration Testing
a. Supports multiple OS or not
b. 4 GB RAM is sufficient or not
—------------------
vi. Configuration Testing
1. Supports multiple OS or not
2. 4 GB RAM is sufficient or not
—------------------
vii. Installation Testing
1. Check screens are clear to understand
2. How screens are navigating
3. Simple or not
4. Un-installation should also be clear
—------------------
viii. Sanitation/Garbage Testing
1. If any application provides extra features/functionality, then, we
consider them as BUG
—------------------

-------------------------------------------------------------------------------------------------------------------------------

38
—------------------

—------------------

-----------------------------------------
========5_Manual Software Testing Training Part-5==========
-----------------------------------------

1. Regression Testing
a. To ensure that the changed part has not affected the unchanged part
i. Existing functionalities should not be broken because of new changes or bug
fixes
ii. Example
1. There are 4 modules in an application
2. The tester found an issue in Module 2 and reported
3. The developer resolves the Bug and comes up with a new build for
application
4. For Regression Testing, the Tester needs to verify the functionality
for all modules to make sure that the fix has not affected the other
modules.
a. This is Full Regression Testing
b. Regression Testing is conducted on Modified builds to make sure that there is
no impact on the existing functionality because of changes like
i. Adding
ii. Deleting
iii. Modifying features

-------------------------------------------------------------------------------------------------------------------------------

39
 c.

d. Types of Regression Testing

i. Unit Regression Testing
1. Done by DEVs
2. Tests only changes/modifications
ii. Regional Regression Testing
1. Tests the modified module along with impacted module
iii. Full Regression Testing
1. Tests the main feature and remaining part of the application
—------------------
1. Re-Testing

a.
b. Re-Testing →
i. The tester verifies the Bug fix only

—------------------

-------------------------------------------------------------------------------------------------------------------------------

40
—------------------
1. Re-Testing vs Regression

a.
b. Regression →
i. Validate the whole application (The changed part should not affect the
unchanged part)
c. Re-Testing →
i. The tester verifies the Bug fix only
—------------------
1. Sanity & Smoke Testing

a.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

41
—------------------
b. Smoke Testing
i. It is BVT (Build Verification Test)
ii. It is performed at early/initial stages
iii. Development started → Build v1.0 –> Tester starts Testing with Smoke
Testing
iv. Can be done by both DEV and Tester

c. Sanity Testing
i. Done by Tester
ii. Focus is on the main functionalities of the application without going deeper

d. The tester can reject the build as well

i. If Smoke Testing and Sanity Testing are not up to the mark

e.
i. Build (1) -> Smoke Testing (Initial Build)
ii. Build (2) -> Smoke Testing
iii. Build (3) -> Smoke Testing
iv. Build (..) -> Smoke Testing
v. Build (..) -> Smoke Testing
vi. Build (..) -> Smoke Testing
vii. Build (n) -> Sanity Testing(Stable Build)

—------------------

-------------------------------------------------------------------------------------------------------------------------------

42
—------------------
1. Exploratory Testing
a. Tester has to test the application by exploring the functionalities
i. Understand the application
ii. Identify all possible scenarios
iii. Document it
1. And, use it for Testing
b. It is conducted when the application is ready, but with no requirements
c. Drawbacks/Limitations
i. The tester might misunderstand
1. Any feature as a Bug
2. Any Bug as a feature
ii. Time-consuming
—------------------
1. Adhoc Testing
a. Testing the application randomly
i. Without any test case(s)
ii. Any Business requirements
b. It is an informal testing type
i. Unplanned activity
c. The tester should have knowledge of the application
i. Previous experience

d.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

43
—------------------
1. Monkey/Gorilla Testing
a. Testing the application randomly
i. Without any test case(s)
ii. Any Business requirements
b. It is an informal testing type
i. Unplanned activity
c. The tester does not have knowledge of the application
d. Suitable for gaming applications
—------------------
1. Adhoc Testing vs Monkey/Gorilla Testing vs Exploratory Testing

a.
—------------------
1. Positive Testing
a. Testing the application with valid inputs
i. Checks the behavior (Is application working as expected or not - Positive
inputs)
b. Example:
i. Textbox -> Allows only numbers
1. Testing it by giving input as a number only

-------------------------------------------------------------------------------------------------------------------------------

44
 c.
—------------------

1. Negative Testing
a. Testing the application with invalid inputs
i. Checks the behavior (Is application working as expected or not - Negative
inputs)
b. Example:
i. Textbox -> Allows only numbers
1. Testing it by giving input as a Aphabets/Spaces/Special
characters only

c.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

45
—------------------
1. Positive vs Negative Test cases

a.

—------------------

1. End-To-End Testing
a. Testing the overall functionalities of the system that includes data integration
among all the modules.

b.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

46
—------------------
1. Globalization/Internationalization(I18N) and Localization Testing

a. Globalization/Internationalization(I18N)
i. Application is supported globally
1. Has the support of multiple languages
ii. Example:
1. Web application - Google, Facebook
2. Mobile application - Paypal, WhatsApp

b. Localization
i. Application is supported locally (Country specific)
1. Country - China, Japan
a. Although, these applications are not even accessible from
outside the country

c.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

47
-----------------------------------------
========6_Manual Software Testing Training Part-6==========
-----------------------------------------

1. Test Design Techniques/ Test Data Design Techniques/ Test Case Design Techniques
a. These techniques are used to prepare the Test Data.
i. Test Data - Data for Testing
ii. This data must cover the different scenarios
iii. Example
1. Login functionality test
2. Data
a. Valid Username, Valid Password
b. Valid Username, Invalid Password
c. Invalid Username, Valid Password
d. Invalid Username, Invalid Password
b. Important factors
i. Reduce Data
ii. More Coverage
c. Techniques
i. Equivalence Class Partitioning (ECP)
ii. Boundary Value Analysis (BVA)
iii. Decision Table-based testing
iv. State Transition
v. Error Guessing

—------------------

-------------------------------------------------------------------------------------------------------------------------------

48
—------------------
1. Equivalence Class Partitioning (ECP)
a. Partition/Divide/Classify/Categorize Data into various classes
i. Select the Data according to class
b. Benefits
i. It reduces the number of test cases
ii. Saves time for Testing

c.

d.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

49
—------------------
1. Boundary Value Analysis (BVA)
a. Focus is on the boundaries of the input
i. Minimum value
1. Min - 1
2. Min + 1
ii. Maximum value
1. Max - 1
2. Max + 1

b.

—------------------
NOTE:
1. Equivalence Class Partitioning (ECP) and Boundary Value Analysis (BVA) are Input Domain
Testing Techniques.
a. The provided value will be verified in the input fields.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

50
—------------------
1. Decision Table-based testing
a. Decision Table is also known as Cause-Effect table
b. Conditions and Actions are considered
i. Action - Reaction combination

c.

d.

e.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

51
—------------------
1. State Transition
a. Used when the application has multiple states
b. Input conditions are changed on the basis of application state
i. Positive and Negative input values → To evaluate the application behavior

c.

d.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

52
—------------------
1. Error Guessing
a. Based on Testers’ prior experience and Analytical skills
i. No specific rules
b. Example
i. Submit the form (Without filling in mandatory details)

c.
—------------------

-----------------------------------------
========7_Manual Software Testing Training Part-7==========
-----------------------------------------

1. SDLC (Software Development Life Cycle)

a. Requirements Gathering and Analysis
b. Design
c. Coding
d. Testing
e. Deployment
f. Maintenance

—------------------
2. STLC (Software Testing Life Cycle)
a. Requirements Analysis
b. Test Planning
c. Test Design
d. Test case Development
e. Environment Setup
f. Test Execution
i. Bug/Defect Reporting and Tracking
g. Test Closure

-------------------------------------------------------------------------------------------------------------------------------

53
 h.

i.
i. Test Planning
1. Inputs
a. Project Plan - How and When to Test?
b. Functional Requirements - What to Test?
2. Activities
a. Identify the resources
i. Who will be responsible for
1. Manual Testing
2. Automation Testing
b. Team formation
i. Recruit people having enough experience
c. Test Estimation
-------------------------------------------------------------------------------------------------------------------------------

54
 i. Time is taken for application Testing
d. Preparation of Test Plan
i. The test plan is the document that contains all the
planning activities
1. What to test
a. Different types of Testing
b. When will it be conducted
c. Team members allocation
2. What not to test
e. Reviews on Test Plan
f. Test Plan Sign-off

ii. Test Designing

1. Input
a. Functional Requirements
i. What all features/functionalities have to be tested?
2. Activities
a. Preparation of Test scenarios and Test cases
i. We can create n no. of test cases for 1 test scenario
1. Example - Login is one scenario
a. Test case - 1 (Valid Username, Valid
Password - Should be able to log in)
b. Test case - 2 (Invalid Username, Valid
Password - Should not be able to log
in)
c. Test case - 3 (Valid Username, Invalid
Password - Should not be able to log
in)
d. Test case - 4 (Invalid Username,
Invalid Password - Should not be able
to log in)
b. Requirements Traceability Matrix (RTM)
i. Mapping of test cases with Requirements

—------------------
1. Priority
a. P0 -> Critical
b. P1 -> Major
c. P2 -> Medium (Normal Priority)
d. P3 -> Minor

—------------------

-------------------------------------------------------------------------------------------------------------------------------

55
-----------------------------------------
========8_Manual Software Testing Training Part-8==========
-----------------------------------------

1. Test Plan

a.
—------------------
1. Use case, Test scenario & Test case

a.

—------------------
-------------------------------------------------------------------------------------------------------------------------------

56
—------------------
i. Use case
1. Describes the requirement clearly using diagrams and data flows
2. Major
a. Actor -> User
b. Action -> Operation
c. Goal -> Outcome
ii. Test scenario
1. What to Test?
2. Scenario to be tested
3. 1 test scenario may have n no. of test cases

iii. Test case

1. How to Test?
2. Step-by-Step operation performed to validate the functionality
3. Contains
a. Steps
b. Actual Result
c. Expected Result
4. A test case is a set of actions executed to validate the
feature/functionality of software/application.

5.
—------------------
1. Use case vs Test case
a. Use case
i. Describes the functional requirement
ii. Prepared by Business Analyst (BA)
b. Test case
i. Describes Test steps
ii. Prepared by Tester
—------------------

-------------------------------------------------------------------------------------------------------------------------------

57
—------------------
1. Test case vs Test scenario

a.
—------------------
1. Test Suite

a.
b. Example
i. Smoke Test cases
ii. Sanity Test cases
iii. Regression Test cases
—------------------

-------------------------------------------------------------------------------------------------------------------------------

58
—------------------
1. Test case Template

b.
—------------------
1. Requirements Traceability Matrix (RTM)

a.

-------------------------------------------------------------------------------------------------------------------------------

59
 b.
—------------------
1. Test Environment

a.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

60
—------------------
1. Test Execution

a.

b.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

61
—------------------
1. Defects/Bugs

a.

b.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

62
—------------------

c.

d.

—------------------

-------------------------------------------------------------------------------------------------------------------------------

63
—------------------

e.

f.

g.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

64
—------------------
h. Defect Resolution

i.
1. This is the Developers’ opinion
2. JIRA - Resolution Type
—------------------

-----------------------------------------
========9_Manual Software Testing Training Part-9==========
-----------------------------------------

1. Defect/Bug life cycle

a. Status of the Defect/Bug
i. New
ii. Assigned
iii. Open
iv. Closed
v. Fixed
vi. Duplicate
vii. Rejected
1. DEV -> Defect is not a genuine defect.
2. Reasons
a. Enhancement
b. Need more information
c. Not reproducible
d. As Designed
viii. Deferred
1. DEV -> Not of higher priority and can be solved in the next release,
then the status changes to Deferred.
-------------------------------------------------------------------------------------------------------------------------------

65
—------------------

b.

c.
i. https://www.javatpoint.com/jira-bug-life-cycle

—------------------

-------------------------------------------------------------------------------------------------------------------------------

66
—------------------
1. Test Cycle Closure

a.

—------------------
1. Test Metrics

a.

-------------------------------------------------------------------------------------------------------------------------------

67
 b.

c.
—------------------

-------------------------------------------------------------------------------------------------------------------------------

68
—------------------
1. QA/Testing Activities

a.
—------------------
1. Principles of Software Testing

a.

—------------------

====================================================

-------------------------------------------------------------------------------------------------------------------------------

69
=======================================================================

1. Documents

a. Github repository: https://github.com/rajatt95/Documents

b. Google Drive:
https://drive.google.com/drive/folders/1tne9pZjgWvfrS0l9tVHs6k1jnQHpTLoA

2. Learnings from Tutor (Code Repository)

a. This course
i. https://github.com/stars/rajatt95/lists/youtube-pavan-manual-testing
b. Other course(s)
i. https://github.com/stars/rajatt95/lists/youtube-pavan-kumar

1. To connect

a.
=======================================================================

=======================================================================

-------------------------------------------------------------------------------------------------------------------------------

70