Introduction

What is Validation?
Validation - “To establish documented evidence which provides a high degree of assurance
that a specific process will consistently produce a product meeting its predetermined
specifications and quality attributes”
-Action of proving, in accordance with the principles of GMP, that any procedure, process,
equipment, material, activity or system leads to the expected results (WHO).
Why Validate?
-Ensure the system performs as intended; provides consistent quality; decreases the risk of
defect costs; decreases risk of regulatory noncompliance
Consequences if We Don’t Validate?
-Form 483; Warning letter; legal consequences
What does this mean?
Any Equipment that will be used in the Pharmaceutical Industry Must be qualified before the
equipment is released for the GMP (production) use
What is Qualification?
 Synonymous to validation, but applicable to Instruments, analytical methods etc.
 For example –Qualifying a HPLC/ Autoclave is nothing but validating them
In CSV What are qualified?
 Any Computerized Systems which support GxP/GMP related Activities.
 Servers, Lab Systems, ERP Systems (SAP), Cloud Systems (SAAS, IAAS, PAAS) QMS apps,
Supply chain management systems, Clinical and Regulatory Systems.
 Analytical Equipment integrated to software which is in scope of Validation.
 Any other Hardware which are used in Regulatory Environment.
Different Validation Types/Approach?
Prospective Validation
o For a system which will be used for production in future
o Will use test data * We currently use Prospective Validation.
Concurrent Validation
o Validating while production
o Using Live data, results
Retrospective Validation
o Validating after production
o Using historical data/results
Which validation approach do you think makes more sense? And why?
Which is used in industry and why

computerized system. Includes hardware, software, peripheral devices, personnel, and

documentation, e.g., manuals and Standard Operating Procedures.
See: computer, computer system.
computer system. (ANSI) a functional unit, consisting of one or more computers and
associated peripheral input and output devices, and associated software, that uses common
storage for all or part of a program and also for all or part of the data necessary for the
execution of the program; executes user-written or user-designated programs; performs user-
designated data manipulation, including arithmetic operations and logic operations; and that
can execute programs that modify themselves during their execution. A computer system may
be a stand-alone unit or may consist of several interconnected units. See: computer,
computerized system.
computer. (IEEE) (1) A functional unit that can perform substantial computations, including
numerous arithmetic operations, or logic operations, without human intervention during a
run. (2) A functional programmable unit that consists of one or more associated processing
units and peripheral equipment, that is controlled by internally stored programs, and that can
perform substantial computations, including numerous arithmetic operations, or logic
operations, without human intervention.
Which System to Validate? How do we ensure regulatory requirements are met?
The first step in the process is to determine if system is a GxP system.
 For non-GxP systems, there is no requirement to validate; however, validation may still
be performed if the business requires. SOX (Sarbanes-Oxley Act)
 Applications or software which have financial data, shares, money spend, money
acquiring, profits, etc.
 Non Gxp Applications.
 Not FDA thing, FDA doesn't audit.
 For GxP systems, or other systems that are to be validated, a determination of the
extent of the validation is made.
GxP Systems
-Processes
-Equipment
-Utility
-Software
 Used to Store data of Manufacturing or the finished product
 Used for Manufacturing of product used by patient
 Used as or on finished product
Internal Audit: every quarter, Government agencies will audit if something else goes wrong.

SOX (SOX (Sarbanes-Oxley Act)

Rule 1
Should not alter, manipulate, destroy, and falsify any record
Rule 2
Retain records for at least 5 years
Rule 3
All business records and communications, including electronic communications should be
saved
IF asked in interview
“All business records, including electronic records and electronic messages, must be saved for
not less than five years, and the saved records should not be manipulated, destroyed, falsified.
What is GxP?
GxP is a collection of quality guidelines and regulations created to ensure that
bio/pharmaceutical products are safe, meet their intended use, and adhere to quality
processes during manufacturing, control, storage, and distribution
GxP was Established by FDA and encompasses different standards recognized as:
G – “Good”
P – “practice”
x-variable depending on the application, It can be M for "Manufacturing", C for "Clinical", L for
"Laboratory, S for "Storage D for "Distribution", R for "Review", etc.

Which determine effective research standards for non-clinical laboratory trials and safe
human-subject clinical trials. GxP’s guidelines focus on:
Traceability: the ability to reconstruct the development history of a drug or medical device.
Accountability: the ability to resolve who has contributed what to the development and when.
Data Integrity (DI): the reliability of data generated by the system. DI could be determined by
the following activities: Identifying the data generated by the system during critical processes
(data flow diagram)
Defining the DI requirements (e.g. ALCOA data attributes) during the lifecycle of data
Identifying the risks and mitigation strategies (e.g. technical or procedural controls) to avoid DI
breaches.

Who is Impacted by GxP?

Regulated industries including food, pharma, medical devices, and cosmetics are impacted by
GxP. GxP guidelines and regulations are global; some of the popular regulators include FDA in
the US, TGA in Australia, and HS-SC in Canada. GxP includes varied regulation sets, but the
most common are GCP, GLP, and GMP

 GCP (Good Clinical Practice)

GCP is an international quality standard that is provided by the International Conference on
Harmonization (ICH), an international body that defines standards which governments can
transpose into regulations for clinical trials involving human subjects. It controls
experimentation on humans done for the sake of advancement in medical sciences and serves
as a quality benchmark as well as a moderator that keeps such experimentation in check.
 GLP (Good Laboratory Practice)
GLP is the non-clinical counterpart for GCP. These guidelines apply to non-clinical studies
conducted for the assessment of the safety or efficacy of chemicals (including
pharmaceuticals) to humans, animals, and the environment.
 GMP (Good Manufacturing Practice)
GMP consolidates the practices required to conform to the guidelines recommended by
agencies that control authorization and licensing for the manufacture and sale of food, drug,
and active pharmaceutical products. These guidelines provide minimum requirements that a
pharmaceutical or a food product manufacturer must meet to ensure that the products are of
high quality and do not pose a risk to the consumer or public.
  Good manufacturing practices, along with good laboratory practices and good clinical
practices are overseen by regulatory agencies in the United States, Canada, Europe,
China, and other countries. The most common GMP guidance documents are:
 EU Good Manufacturing Practice (GMP) Guidelines, Volume 4
 US FDA current Good Manufacturing Practice (cGMP) guidelines: 21 CFR Part 11, 210,
211, and 820
 WHO Good Manufacturing Practices for pharmaceutical products,
 Annex 4 to WHO Technical Report Series, No. 908, 2003

Moto of Automation is
“Entire GxP business process should be covered by a Test script or a SOP”
Manual Work:
SOP: Minimize deviation (100% not possible if you ask me)
Automation:
Same Result who ever operated,
E.g., Even God Probably need User ID and Password for Google.
Can Prove by Test Script
Validation can prevent this.

“Same Output/Result”

What are the main FDA regulations come under Validation?

Regulations
21 CFR Parts11, 210, 211 – Pharmaceutical
21 CFR Parts 11, 820 Medical Devices
21 CFR part 11
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-
electronic-records-electronic-signatures-scope-and-application
General principles of Validation

VALIDATION ENGINEER ROLE

 Generating Documented Evidence
 Developing test methods
 Performing Tests
 Analysing Data
 Reporting and documenting issues
 Resolving issues
DATA INTEGRITY WARNING LETTERS
-An FDA 483 Observation is a notice that highlights potential regulatory problems.
-While a warning letter is an escalation of this notice.
EMA – European Medicines Agency
MHRA – Medicines & Healthcare products Regulatory Agency
ANVISA - Brazilian Health Regulatory Agency
Eudralex – European Commission, The Rules Governing Medicinal Products in the European
Union
WHO – World Health Organization
Additional deliverables may be required, depending on complexity. For instance, Data
Migration Plan, Data Migration Qualification, Data Migration Report, Test Plans, Source Code
Reviews, Unit Testing, Retirement Plan, Retirement Report and Validation Master Plan: High
Level System Classification, ERES & DI Assessment Tool, and Functional Risk Assessment.

1.Equipment Validation:
 Project Plan
 Evaluate indented use of the Equipment
 Validation Plan
 Draft URS
 Impact of the system (Direct or indirect impact)
 Validation Approach

Project plan - Details the tasks and timeline for the project (IMPACT ASSESSMENT)
 Does the system have a direct contact with the product or a product contacting surface?
 Is the system used in cleaning, sanitizing or sterilizing product contact surface?
 Does the system measure, have potential to directly impact, or preserve the critical
quality attributes of the product?
 Does the system provide primary container labelling and lot identification?
 Does the system generate critical process parameter data that is used to accept or reject
product?
 Does the system support the performance of a Direct Impact System but does not have
a Direct Impact on product quality?
User Requirement Specification (URS)
Defines clearly and precisely what the User wants the system to do and states any constraints
(e.g. regulatory) under which the system must operate.
Needs to get Approval to start Qualification

VALIDATION PLAN
 Defines the objectives of the Validation and the activities, procedures and
responsibilities for accomplishing the objectives of the Validation.
 The Validation Plan should also deal with the approach for maintaining the Validation
status.
 This will generally involve referencing the organization’s Quality Management System
documentation that deals with such issues as Configuration Management, Change
Control, and System Retirement.

PROTOCOLS
CONTROL SYMBOLS

DCS
A distributed control system (DCS) is a control
system for a process or plant, wherein control
elements are distributed throughout the system.
This contrasts with non-distributed systems, which
use a single controller at a central location. In a DCS,
a hierarchy of controllers is connected by
communications networks for command and
monitoring.
 DATA COLLECTION THROUGH PI HISTORIAN
PI is a real-time data historian application with a
highly efficient time-series database structured and
developed by OSIsoft. PI stands for Process
Information. This application can efficiently record
data from process control systems (ex. DCS, PLC)
into a compressed time series database.

VALIDATION OF BIO-REACTOR
A bioreactor is a vessel in which a chemical process is carried out which
involves organisms or biochemically active substances derived from such organisms. This
process can either be aerobic or anaerobic. These bioreactors are commonly cylindrical,
ranging in size from litres to cubic metres, and are often made of stainless steel.

 IQ activities
 Asset addition
 Hardware review
 Instrumentation Review
 Sanitary Piping review
 Utility supply review
 Continuity verification
 Filter Review
 OQ Activities
 Data Collection testing for new PI points
 Alarm Function Verification
 Interlock Function Verification
 Control Loop Function Verification
 Sequencing
 Operator Interface Verification
 PQ activities procedure verification
 Batch Report Verification
 Procedure Verification

VALIDATION OF UF/DF SKID

 Used for nano-filtration
 Tangential flow trans- membrane filtration
 Depends on pore size of membrane and molecular weight of particle
 Assets being added to the company’s system
 IQ activities
  Hardware review (Main hardware such as pumps, pressure and temperature gages,
product contact surfaces, tubing)
 Sanitary piping specifications (metal piping's coming in contact with product)
 Instrumentation Review (Calibration of critical instruments such as gages and other
monitoring instruments)
 Utility Supply review (electrical and piped services such as instrument air)
 Continuity Verification (Continuity to PLC system)
 Engineering documentation review (Turn Over Package, control drawings, manuals,
maintenance, P&ID)
 OQ Activities
 Control System functional testing (Data Collection through PI Historian)
 Control System Reliability testing
 Control Loop Function Verification
 Operator Interface Verification
 Alarm Verification (Local, PLC based)
 PQ activities
 Job Plans updated
 Procedure Verification
 Process Validation PQ

CLEANING VALIDATION
Objectives
To review:
 General requirements
 Validation protocol requirements
 How to check limits
 Analytical requirements
 Sample methods
Why cleaning validation is so important Pharmaceuticals can be contaminated by potentially
dangerous substances
 Essential to establish adequate cleaning procedures
Possible contaminants
 Product residues
 Cleaning agent residues and breakdown
 Airborne matter
 Lubricants, ancillary material
 Decomposition residues
 Bacteria, Mold and pyrogens
Strategy on cleaning validation
 Product contact surfaces
 After product changeover
 Between batches in campaigns
 Periodic re-evaluation and revalidation
Cleaning validation protocol (1)
Should include:
  Objective of the validation
 Responsibility for performing and approving validation study
 Description of equipment to be used
Cleaning validation protocol (2)
Should include:
 Cleaning procedures to be used
 Any routine monitoring equipment used
 Number of cleaning cycles performed consecutively
 Sampling procedures used and rationale
 Sampling locations (clearly defined)
Results and reports
 Cleaning record signed by operator, checked by production and reviewed by QA
 Final Validation Reports, including conclusions

CLEAN IN PLACE (CIP)

 Uses pressurized cleaning and rinse solutions distributed by an automated CIP skid or a
mobile pump
 Skid consists of a chemical circulation vessel, a circulation pump, acid and caustic
chemical dosing pumps and control instrumentation such as sanitary, valves,
conductivity transmitters, flow switches.
 CIP programs typically consist of the following steps:
 Initial rinse step Caustic wash / rinse step(s)
 Acid wash / rinse step(s)
 Final rinse step(s)
 Air Blow step
 Types of challenge solution
 Salt solution (Sodium Hydroxide)
 CIP 100 (Potassium Hydroxide)
 CIP 200 Solution (Phosphoric Acid)
 Cleaning Process should account for worst case scenario
 Parameters evaluated are Temperature, fluid flow rate, concentration, contact time, line
length, diameter, geometry of the target system.
CIP PROTOCOL
 Circuit Pre-approval (Can be a block diagram or highlighted P&ID)
 Number of Runs (Usually 3 or more)
 Program to be used for each circuit
 Soiling Method
 Sample collection to test the efficiency of the CIP run.
 Testing samples for Endotoxin, Bioburden, Conductivity and TOC
CLEAN OUT OF PLACE (COP)
 Cleaning of a load item in a glass washer and/or cart washer. Eg Hoses, gaskets, clamps,
product handling utensils, pumps, beakers, removable pipes, etc.
 Types of trays and spindle sized available
 Types of parts that can be cleaned
 Engineering runs placing different parts in different spindles
  Program to be run
 Testing using Riboflavin test
 Water sample testing
STEAM IN PLACE (SIP)
 Sterilization in place or Steam in place (SIP) is a method used to clean or disinfect
process equipment and piping without disassembly.
 Protocol preparations similar to CIP
 Placement of Thermocouple and Biological Indicators
o Top, middle, and bottom of a vessel
o Inside filter housings (inside or outside of filter cartridges)
o Low points in piping
o Low points in hoses
o Upstream of steam traps
 The lethality (F0) required by a sterilization cycle using the overkill approach is calculated
as follows:
 F0=D121 (log10A-log10B)
 Where: D121 (decimal reduction value at 121ºC) is the relative heat resistance of a
microorganism at 121ºC.
 It describes the time it takes to reduce a microbial population one log or to be 1/10th of
its previous value at 121ºC. Typical D121 values for microorganisms in the environment
are less than 0.5 minutes, but biological indicators used in SIP validations typically
contain D121 values ranging from 1.5 to 3 minutes (or approximately 2 minutes) providing
a safety factor that ensures worst case conditions for validation testing.
 A is the number of challenge spores in the system (a typical population on a BI spore
strip is 106)
-6
 B is the desired probability of survival (10 for the overkill approach).

 Ensure all the critical instruments associated with the cleaning system are calibrated.
 No production activity is taking place
 Operators are provided with the protocols
 Handle Biological Indicators with sterile forceps
 Care while sampling the water to avoid false failures

P&ID DRAWINGS
COMPUTER SYSTEM VALIDATION
 Computer System Validation is carried out through activities that occur throughout the
entire Software Development Life Cycle (SDLC).
 Software is constantly evolving to keep up with the increasingly complex needs of the
people that use it; therefore, validation is an ongoing necessity.
TYPES OF COMPUTER SYSTEM
 ERP (Enterprise Resource Planning) system
 LIMS (Laboratory Information Management System) system
 Laboratory Instruments
 Automated manufacturing and packaging equipment
 IT systems including those supporting network and infrastructure
 Spreadsheets and databases
WATERFALL MODEL
 The Waterfall Model was first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed fully before the next phase can begin.
This type of model is basically used for the for the project which is small and there are
no uncertain requirements. At the end of each phase, a review takes place to determine
if the project is on the right path and whether or not to continue or discard the project.
In this model the testing starts only after the development is complete. In waterfall
model phases do not overlap.
 The sequential phases in Waterfall model are:
 Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
doc.
 System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
 Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed
and tested for its functionality which is referred to as Unit Testing.
  Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system: Once the functional and non-functional testing is done, the
product is deployed in the customer environment or released into the market.
 Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.

V MODEL
 Users are involved in every step of the process (deeply involved for custom
development, less for package based systems)
o The Installation Qualification or IQ focuses on testing that the installation has
been done correctly
o The Operational Qualification or OQ focuses on testing of functionality in the
system installed at the User site
o The Performance Qualification or PQ focuses on testing that users, administrators,
and IT support people trained in the SOPs can accomplish business objectives in
the production environment even under worst case conditions.
VERIFICATION PHASES IN V-MODEL
 Business Requirement Analysis: This is the first phase in the development cycle where
the product requirements are understood from the customer perspective. This phase
involves detailed communication with the customer to understand his expectations and
exact requirement. This is a very important activity and need to be managed well, as
most of the customers are not sure about what exactly they need. The acceptance test
design planning is done at this stage as business requirements can be used as an input
for acceptance testing.
  System Design: Once you have the clear and detailed product requirements, it.s time to
design the complete system. System design would comprise of understanding and
detailing the complete hardware and communication setup for the product under
development. System test plan is developed based on the system design. Doing this at
an earlier stage leaves more time for actual test execution later.
 Architectural Design: Architectural specifications are understood and designed in this
phase. Usually more than one technical approach is proposed and based on the
technical and financial feasibility the final decision is taken. System design is broken
down further into modules taking up different functionality. This is also referred to as
High Level Design (HLD)
 The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood and defined in this stage. With this
information, integration tests can be designed and documented during this stage.
VERIFICATION PHASES IN V-MODEL
 Module Design: In this phase the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD). It is important that the design is
compatible with the other modules in the system architecture and the other external
systems. Unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. Unit tests can be designed at this
stage based on the internal module designs.
CODING PHASE
 The actual coding of the system modules designed in the design phase is taken up in the
Coding phase. The best suitable programming language is decided based on the system
and architectural requirements. The coding is performed based on the coding guidelines
and standards. The code goes through numerous code reviews and is optimized for best
performance before the final build is checked into the repository.
VALIDATION PHASES IN V-MODEL
 Unit Testing: Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and helps eliminate
bugs at an early stage, though all defects cannot be uncovered by unit testing.
 Integration Testing: Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and communication of the
internal modules within the system.
 System Testing: System testing is directly associated with the System design phase.
System tests check the entire system functionality and the communication of the system
under development with external systems. Most of the software and hardware
compatibility issues can be uncovered during system test execution.
 Acceptance Testing: Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user
environment. It also discovers the non-functional issues such as load and performance
defects in the actual user environment.

AGILE METHOD
Defect/Bug Life Cycle
 What is a bug?
o A defect is an error or a bug, in the application which is created. A programmer
while designing and building the software can make mistakes or error. These
mistakes or errors mean that there are flaws in the software. These are called
defects/bug.
o When actual result deviates from the expected result while testing a software
application or product then it results into a defect. Hence, any deviation from the
specification mentioned in the product functional specification document is a
defect. In different organizations it’s called differently like bug, issue, incidents or
problem.
o In software development process, the bug has a lifecycle. The bug should go
through the life cycle to be closed. A specific life cycle ensures that the process is
standardized. The bug attains different states in the life cycle.
 Defects and failures basically arise from:
o Errors in the specification, design and implementation of the software and system
o Errors in use of the system
o Environmental conditions
o Intentional damage
o Potential consequences of earlier errors
 Errors in the specification and design of the software:
o Specification is basically a written document which describes the functional and
non – functional aspects of the software by using prose and pictures. For testing
specifications there is no need of having code. Without having code we can test
the specifications. About 55% of all the bugs present in the product are because
of the mistakes present in the specification. Hence testing the specifications can
lots of time and the cost in future or in later stages of the product.
 Errors in use of the system or product or application may arise because of the following
reasons:
o Inadequate knowledge of the product or the software to the tester. The tester
may not be aware of the functionalities of the product and hence while testing
the product there might be some defects or failures.
o Lack of the understanding of the functionalities by the developer. It may also
happen that the developers may not have understood the functionalities of the
product or application properly. Based on their understanding the feature they
will develop may not match with the specifications. Hence this may result into the
defect or failure.
 Environmental conditions
o Because of the wrong setup of the testing environment testers may report the
defects or failures. As per the recent surveys it has been observed that about 40%
of the tester’s time is consumed because of the environment issues and this has a
great impact on quality and productivity. Hence proper test environments are
required for quality and on time delivery of the product to the customers.
 Intentional damage:
 o The defects and failures reported by the testers while testing the product or the
application may arise because of the intentional damage.
 Potential consequences of earlier errors:
o Errors found in the earlier stages of the development reduce our cost of
production. Hence, it’s very important to find the error at the earlier stage. This
could be done by reviewing the specification documents or by walkthrough. The
downward flow of the defect will increase the cost of production
STATES OF A BUG
 The different states of a bug can be summarized as follows:
o New
o Open
o Assign
o Test
o Verified
o Deferred
o Reopened
o Duplicate
o Rejected
o Closed
o Not a Bug
DESCRIPTION OF VARIOUS STAGES
 New
o When the bug is posted for the first time, its state will be ‘New’. This means that
the bug is not yet approved.
 Open
o After a tester has posted a bug, the lead of the tester approved that the bug is
genuine, and he changes the state as ‘Open’.
 Assign
o Once the lead changes the state as ‘Open’, he assigns the bug to corresponding
developer or developer team. The state of the bug now is changes to ‘Assign’
 Test
o Once the developer fixes the bug, he must assign the bug to ‘Test’. Before he
releases the software with bug fixed, he changes the state of bug to ‘Test’. It
specifies that the bug has been fixed and is released to testing team.
 Deferred
o The bug, changed to deferred state means the bug is expected to be fixed in next
releases. The reasons for changing the bug to this state have many factors. Some
of them are priority of the bug may be low, lack of time for the release or the bug
may not have major effect on the software.
 Rejected
o If the developer feels that the bug is not genuine, he rejects the bug. The state of
the bug is changes to ‘Rejected’.
 Duplicate
o If the bug is repeated twice or the two bugs mention the same concept of the
bug, then one bug status is changes to ‘Duplicate’.
  Verified
o Once the bug is fixed and the status is changed to ‘Test’, the tester tests the bug.
IF the bug is not present in the software, he approved that the bug is fixed and
changes the status to ‘Verified’.
 Reopened
o If the bug still exists even after the bug is fixed by the developer, the tester
changes the status to ‘Reopened’. The bug traverses the life cycle once again.
 Closed
o Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no
longer exists in the software, he changes the status of the bug to “closed”. This
state means that the bug is fixed, tested and approved.

DEFECT REPORT
 When a tester finds a bug or defect it’s required to convey the same to the developers.
Thus, they report bugs with the detail steps and are called as Bug Reports, issue report,
problem report, etc.
o Defect ID – Every bug or defect has its unique identification number
o Defect Description – This includes the abstract of the issue.
o Product Version – This includes the product version of the application in which
the defect is found.
o Detail Steps – This includes the detailed steps of the issue with the screenshots
attached so that developers can recreate it.
o Date Raised – This includes the Date when the bug is reported
o Reported By – This includes the details of the tester who reported the bug like
Name and ID
o Status – This field includes the Status of the defect like New, Assigned,
Open, Retest, Verification, Closed, Failed, Deferred, etc.

o Fixed by – This field includes the details of the developer who fixed it like Name
and ID
o Date Closed – This includes the Date when the bug is closed
o Severity – Based on the severity (Critical, Major or Minor) it tells us about impact
of the defect or bug in the software application
o Priority – Based on the Priority set (High/Medium/Low) the order of fixing the
defect can be made. (Know more about Severity and Priority)

BUG LIFE CYCLE – FLOW CHART