Syllalus

New
SPU A
Book 0f
SOFTWARE TESTING
AND
QUALITY ASSURANCE
: -

For MCA(Management) Semester III

[Course Code- IT33: Credit
CBCS Pattern
As Per New Syllabus, Effective from June 2019

Dr. Satish Ambike

Dr. Jyoti J. Malhotra

Assuufe Frofesso, Uep.t u! t

MIT Art Design and Iecnnology Unity, fun"

Price 300.00

ONIRAL! ADVANCEMENT OF KNOWLEDGE

N4831
Syllabus
1 SOFTWARE QUAUITY ASSURANCE FUNDAMENTALS
(WEIGHTAGE 20, HPS.
6)

17

2. SOFTWARE TESTING FUNDAMENTALS

(WEIGHTAGE 17, HRS. 10)

(:0, ,f /ftMste f4lture Ofinitior

f Error, tun f.it. Gfeurt ani failure,
24

Softst |ectin; Life cylr

?7 Laid.tron Vonfiration Conept V!Aodol ar:d
22 Adel
29
291 Unit Conponent)
*tin9
292 Iitegratiori Testrg
2.9.3
Syetern Testing
2.94 User Acceptance Testng (UAT,
2.10 Test Types
2.10.1 Functional testing
(Black-D0)
2.10.2 Non-functional
testing (Testing of software product characteristics)
2.10.3 Structural testing
(V/hite-bo)
2.104 Testing related to changes -Confirrmnation
2.11 Non-Functional (Re-testing) and Regression Testing
Testing Types
2.11.1 Performance (Load
a Stress)
 2.11.2 Usability
2.11.3 Maintainability
2.11.4 Portability
5. TEST MANAGEMENT
2.11.5 Security WEIGHTAGE 25, HRS. 101:
5.1 Test Organization - Roles & Skills
2.11.6 Localization & Internationalization of Tester, Test Lead, Test Manager
5.2 Test Planning - Test Plan as per IEEE
2.12 Concept of Smoke testing and Sanity Testing 829 STANDARD TEST PLAN TEMPLATE
5.3 Test Process Monitoring
STATIC TESTING & Control
3. [WEIGHTAGE 5.3.1 Test Monitoring through - Test Log (IEEE
3.1 Static Techniques - Review 8,
HRS. 829: TEST LOG TEMPLATE to
be
discussed) and Defect Density
3.1.1 Review Process (nformal & Forma)
5.3.2 Reporting Test Status (1EEE 829: TEST SUMMARY
3.1.2 Desk Checking. REPORT TEMPLATE to
discussed) be
3.1.3 Technical or Peer Review
5.3.3 Test Control
3.1.4 Walkthrough 5.4 Requirement Traceability Matrix (Horizontal
3.1.5 Inspection & Vertical), Test Scenario, Test
Cases (both Positive & Negative Test Suite, Test
Static Techniques- Static Analysis Cases, as per IEEE 829: TEST CASE SPECIFICATION
3.2 TEMPLATE)
3.2.1 Data flow analysis 5.5 Configuration Management - Configuration
Control flow analysis, Management support for Testing
3.2.2 5.6 Risk and Testing - Project Risk
Product Risk
3.2.3 Static Analysis by Tools (Automated 5.7 Incident/ Defect
Static Analysis) Management
Case Study on Preparation of Inspection Defect Life Cycle
Checklist 5.7.1
4
DYNAMIC TESTING 5.7.2 Defect/ Incident Report (IEEE 829: TEST INCIDENT
Test DesignTechniques - Black
WEIGHTAGE REPORT TEMPLATE to be
4.1 Box Testing Techniques: 15, HRS.7 discussed)
4.1.1 Equivalence Partitioning Case Study on Test Plan for applications
and Case study on Test Cases for different
4.1.2. within applications features
Boundary Value Analysis
Extra Reading: Version Control
4.1.3 Decision Table Testing Tool: SVN, Defect Tracking Tool:
Bugzilla, JIRA
4.14 State Transition Testing 6. TOOL SUPPORT FOR TESTING
[WEIGHTAGE 15, HRS. 9)
4.2 Test Design Techniques 6.1 Types of Test tools CAST (only
-White Box Testing Techniques type & their purpose should be covered)
based) (coverage based and fault 6.2 Effective Use of Tools: Potential Benefits
and Risks
4.2.1 Statement coverage 6.3 Introduction of a tool into an organization
4.2.2 Branch 8&
6.4 Testing tools
Decision coverage
4.2.3 Path coverage 6.4.1 Selenium - WebDriver and Test NG
4.2.4 6.4.2 Appium
McCabe's Cyclomatic Complexity
Metric (Computation of Cyclomatic
Complexity to be covered) 6.4.3 IMeter
4.2.5 Data Flow based Testing Extra Reading: Functional Test Automation
Tools: Quick Test Professional (QTP), IBM Rational
Robot, Non-functional Test Automation Tools:
4.2.6 Mutation Testing Load Runner, Test Management Tools: Test
4.3 Test Design Techniques - Director, Test Link, Bugzilla, Redmine, API Testing Tool:
Experience based techniques: Postman, ETL Testing Tool, Big Data
Testing Tool,Al based Testing Tool: Test Craft, UI Testing,
4.3.1 Error Guessing Website Testing: TestRal
4.3.2 Exploratory
Testing
oblems based on Black Box and White
Box Testing Techniques
to be covered
 Contents.

1. Softwaro Quallty Assuranco

Fundamentals
1.1-1.24 i...
2. Softwaro Testing Fundamentals

3. Static Testlng
2.1 - 2.58
Software Quality
3.1-3.34 |Assurance Fundamentals
4. Dynamic Tosting

4.1 - 4.26 Objectives...

5. Tosting Managomont () To lcarn about basic System
Development Cycle.
(] Toknow about different appro0aches
5.1-5.42 and rmodels for System Deveupment.

6. Tool Support 1:1 SOFTWARE QUALITY ASSURANCE

for Tosting FUNDAMENTALS
6.1-6.15 Software Quality Assurance (SQA) a
is set of activities for
software engineering processes ensuring quality in
that ultimately results, or at least gives
the quality of software products. confidence, in
For any engincered product, are
there many desired qualities
project. The section explains software relevant toa particular
proccsscs: Quality Assurance, quality fundamentals, including
the main SQM
Verification, Validation, Review,
and Audit.
111 Definition of Quality
Quality means constantly meeting customer
requirements in terms of service,
delivery schedule and cost.
Quality software is a bug-free, within
budgct, delivered on time, mects customer
requirements, and is maintainable.
Software quality is also defined in terms
of three factors:
1, Failures

2. Reliability
3. Customer satisfaction.
A software product is said to have good quality if:
It has a few post-release failures.

(1.1)
 ST & QA - MCA (Mgt.): Som I! 1.2 Softwarc Quality
Assurance Fundamentale
It is reliable, meaning that hardly crashes or behaves
it

unexpectedly when ST & QA - MCA (Agt.) : Sem

by the customer. used ll 1.3 Software Quality Assurance Fundamentals
It keeps majority of customers satisfied and happy.
Table 1,1: Quality Control Vs Quality Assurance
There are two kinds of quality:
1.
Quality of design: It refers to characteristics Sr. No. Quality Control (Qc) Quality Assurance (QA)
product to be constructed. It specified by designers,
includes requirements, specifications, forthe end Product Oriented. Process Oriented.
of the system. and the dosio 2 QC aims to identify defects in the QA
2. Ouality
aims to prevent defects with a
of conformance: The Degree to final product. focus on the process used to make the
are maintained which the design specifications (It is a reactive process)
in manufacturing product.
the product. It primarily
implementation. focuses on (It is a proactive quality process)
Definitions: 3. The goal of QC is to identify defects The goal
of QA is to improve
Ouality consists of all after a product is developed and development and test processes so
those product features which meet before it's released.
thereby provide product the needs of customers and that defects do not arise when the
satisfaction. Quality consists (Find the defects) product is being developed.
of freedom from deficiencies.
A
predictable degree of uniformity - (Prevent the defects)
and dependability at low cost Juran 4 It focuses on the activities or It focuses
market. and suited to the Prevention of quality
techniques used to achieve and problems through
planned and
- Dr. maintain the product quality. systematic activities including
1.1.2 Quality Assurance Edward Deming process and service. documentation.
5. It involves a series of Inspections It is a complete
Quality Assurance (QA) aims to system to assure the
prevent defects with a focus on and reviews to ensure that product quality of products or
make the product. the process used to meets it specifications.
services;
involves audits, reviews and proper
The goal is to provide confidence
that a product is of the quality expected testing tools to meet the customer
customer. by the satisfaction.
QA consists of auditing
and reporting procedures, which are
necessary data to management used to provide 1:2 SOFTWARE QUALITY ASSURANCE
in order to make proactive decisions.
If there is a problem in the data provided Software Quality Assurance (SQA) is the function of software quality that assures
management's responsibility to address through quality assurance, it is
the problems and apply the necessary that the standards, processes, and procedures are appropriate for the project and are
resources to resolve it. correctly implemented.
1.1.3 Quality Control SQA assures that standards and procedures are established and are also followed
throughout the software life cycle.
Quality Control (QC) aims to identify defects SQA is a systematic pattern of all actions necessary to provide enough confidence
in the final product.
Quality control focuses on operational techniques that the product meets its technical requiremnents.
and the activities used to fulfill and
verify quality requirements. SQA is an umbrella ac+i-ity applied throughout the software process.
Inspections, reviews, and tests are done Objectives of SQA:
throughout the software process to ensure
that each product meets its specifications/requirements. The objectives of SQA refer to .1e functional, managerial and economic aspects of
Key concept of quality control is
that - "all work products have defined and software development and maintenance.
measurable specifications", which are compared SQA objectives for Software Development (Process Oriented) and Software
with the output of each process.
1.1.4 Difference between QA and Qc Maintenance (Product Oriented) are:
Table 1.1 summarizes the difference 1. ASsuring an acceptable level of confidence that the software and its maintenance
between QC and QA.
activities will conform to functiona! technical requirements.
 - MCA
ST&Q4 Myt): $one Cuslity Assursnce
Fundamenia's
2 ASunng an 2pae levelof coafidence that the sofwae
sw!l nform to "anaernal schculina.and budgctaryandits maintCnance ST & QA - MCA (Mgt.): Sem
3. inibatirg and manging atiitics to imprOve nquiremcnts l 1.5 Software Qual.ty Assurace Funcsmena'
and increase
sw drlpment and swaN mainterane. the efficiency 4. SQA Actions and Tasks.
4
Ime the svae Raquirements Quality by
removing ambiguity Defines what reviews or audits are to done.
achieing Ompletenes.
and When and how they will be done?
S
Npiane issues that cannot be resolvd
within the team What further actions are required?
a3is bysenior management. should be
For example. Software requirements
ipve Design and Code quality: by focusing more reviews, Design review, Final sofware
Complety, Maintainability. Reusability on quality and doumentation review.
and Documentation. factors like
5. Tools and Methods supporting SQA
L21 SQA Planning S Standards Formal Technical Review.
Actions and Tasks.
L2.12 SQA Planning
Review reporting and record keeping.
Plansing is one of the most
important aspects of SQA The Review guidelines.
team depends on how well entire operation of the SOA
SQA plan proides a
their planning is done. 6. Software Configuration
Management (SCM) Procedures for
rozd map for establishing 7. Methods for assembling, maniging change.
The plan saves as a software quality assurance. preserving and maintaining all SQA-related
template tor various SQA i.e. securing SQA documents. records.
software projet. actiities that are instituted for each
I: defiaes the techniques, 8. Organizational roles
procedures, and methodologies and responsibilities
relative to product quality.
tinely delivery of the software that will be used to assure 1.2.12 SQA Standards
resources. that meets specified requirements Standards are the criteria to which
within project the sottware products are compared.
SQA Plan helps everyone standards are used to define the development Specified
involved in the project manner in which the software is criteria that are used to guide the
appication will vork in the actual to know in advance how
environment. the engineered.
IEEE (IEE94] Types of Standards include:
has published a standard for SQA
A structured SQA plans.
plan identifies: 1. Documentation
Standarcs: Specify the form and content
1 The pupose and scope of the plan. product documentation and provide for planning, analysis.
consistency throughout a project.
This section list the 2. Design Standards: Specify
software covered by SQA the form and content of the design product. Also
Also state portion plan. provide rules and methods for
of software life cycle covered. translating the software requirements
2. A description of all software and for representing it in the design into design
engineering documentation.
Models, documents work products. 3. Code Standards: Specify
(software requirements the language in which the code is to
and design specification, user restrictions on use of language features. Also be written and
manual) and source code. focuses on style conventions, rules
3. Al applicable standards and guidelines for data structures, and code documentation.
ife cycle. that are applied during 4. Proceau. *• Procedures are
the software documented procedures are established steps
in
3 Design, Coding and testing which the deve.ped processes are-
standards. compared. In software engineerirg.
ISO 9001: 2000-A quality assurance procedures are needed for configuration nanagement,
standardthat is applied to non-conformance
engineering. It is a special software reporting andcorrective action, testing, and formal inspections.
set
organization to understand of rules which are meant to be followed by an
formal quality management
customer needs
and expectations. ISO defines 1.3 SQA ACTIVITIES
system in order to the SQA activities are planned. The Software
satisfaction. enhance the customer Engineering Institute (SEI) recommends a
o Six Sigma set of SQA activities that address quality assurance
planning. record keeping
analysis, and reporting.
 Software Quality Assurance Fundamentals Fundamentals
1.6 Software Quality Assurance
& OA - MCA (Mgt.): Sem Il ACA (Agt.)
: Sem ll 1.7
ST
by an independent SQA group are ST& OA
which are performcd
Various SQA activities, Control:
a) Baseline to go to the next phase.
mentioned below: Basc lining is done when
the product is ready are
of SQAplan for the
project.
and further changes to the product
1. Preparation state of product is preserved
Current product.
The plan identifies: in version of the
done along with change
Evaluations to be performed. Configuration Identification: accurate with respect to
b)
Audits and reviews to be
performed. identification is constant and
Software configuration modules, and its associated
Standards applicable to the project. or naming of programs, software
the numbering
Error tracking and reporting
procedures. software documents. - CvS (Concurrent
Documents to be produced by the SQA
group.
Example of tools for
configuration management Win
process description. Version System), VSS (Visual
Source Safe).
2. Participate in the development of the project's software revievIs,
process sQA group reviews the SQA assures Verification and
Validation by monitoring technical
a
The software team selects work to be performed.
process description for compliance with organizational policy, internal and inspections, and walkthroughs.
external software standards. SQA
3. Review software engineering activities (Analysis, Design, Construction.
1.4 BUILDING BLOCKS OF ensure an acceptable level of quality.
SQA building blocks or
components
Verification and Management) to verify compliance with the defined software Software Quality Assurance Systerm
are classified into
The Components used by the maximumn quality and ensures the
process. guarantees
six different categories; each of which
4. Audit designated software work products to verify compliance with those
execution with the standards and procedures.
defined as part of the software process. blocks are:
The six different components of SQA building
SQA group also verifies that corrections have done and reports the results to the
1. Pre-project SQA Components.
project manager.
2. Project Life Cycle SQA Components.
5. Ensure that any deviations in software or work products are documented and
3. Quality Infrastructure Components.
handled according to a documented procedure.
Deviations may be encountered in the project plan,process description, applicable 4. Software Quality Management Components.
5. Standardization, Certification and SQA Assessment Components.
standards, or technical work products.
6. Organizing SQA- the human Components.
6. Record any evidence of noncompliance and report them to management.
Noncompliance items are tracked until they are resolved. 1. Pre-project SQA Components:
been effectively defined and the
7. Configuration Management Monitoring. This component ensures that the project has
resources, software requirements are not misunderstood by the
available budget and
o Configuration Management is also called as Change Control Management. It is a
client or the organisation.
systematic way of controlling the changes of software items. It also helps to store component; Contract Review and Quality plans.
and retrieve the configurable items (i.e. Software Code, Defect log, Test Reports, There are two key concepts to this
etc,). a) Contract Review:
SQA assures that SCM activities are performed in
accordance with the The Contract Review activities include:
Configuration Management plans, standards, and procedures. SQA reviews the A systematic assessment of the proposed project draft.
Configuration Management plans for compliance with SCM policies and Clarification of the customer requirements.
requirements and provides follow-up for non-conformances.
Reviewing the project schedule.
The Configuration Management activities are monitored proposed
and audited by SQA, it Evaluation of the staff's capacity for the implementation of
includes:
project.
 ST& QA - NCA(Mgt.): Sen M 1.8 Software Quality Assurance
Fundamentals
Dvaluation of the customer's capacity to
fulfil his requirement
Evaluation of development risks. ST & QA - ICA (Mgt.) : Sem l!l 1.9 Sottware Quality Assurance Fundamentals
Outcome: ii Adaptive maintenance in which maintenance occurs to
tWell documented contract between to be adapted.
the system it needs
the company
projects requirements, budgets and so on and client statine .
to ensure that nO new iii
Functionality improvement where the system is modified for additional
been added to the contract draft. changes have
improvements.
b) Development and Quality Plans: 3. Quality Infrastructure Components:
: The development plan is a plan The main goal of this component is to reduce
of the project. the number of errors in the system and
Issues covered in the Project Development improve productivity. This is achieved through following
Plan are: sub-components:
Development Schedule. (i) Procedures and Work
Instructions: A procedure describes how the process is
Manpower and hardware resources. performed and is generally applicable and used
in entire organization. A work
Organizational issues; such as instruction is mnore specific and provides detailed
forming a team and delegating methods. directions for the use of
and responsibilities. their roles
(iü)
Supporting Quality Devices: 'Quality Devices'
Deciding Project methodology such as templates or checklists
(Spiral or Waterfall) are used to enhance
Java/PHP/AJAXINet) and development tools. efficiency and quality.
Template provides easier integration
Quality plan is a plan for quality assurance between team members; while Checklist
activities. helps developers to carry a self-check
Four main elements of document and software code.
of quality plan are: (iüi) Staff Training, Instruction
and Certification: Well trained professional
Quality Goals ie. goals enables efficient and high quality staff
of the product. produce. New staff has to be trained respect
in
List of Planned reviews to the professional knowledge
(Design Reviews and Code about standards and procedures of
software tests. Inspections) and various organisation. the
Criteria for starting and (iv) Preventive and Corrective
ending of each project stage. Actions: A study of existing data for
and failures enables them to be solved similar faults
Planned testing at the time easily in future either by correcting
or by preventing
2 Project Lifecycle SQA Components: of
deployment of developed them from happening. them
software.
4. Software Quality Management
This coponent has two mnain Components:
stages: Quality management focuses on
1 The Development Life cycle stage (To product quality and ways to achieve it. Components
detect design and programming used for quality management are: Project
2 The Operation-Maintenance stage (To improve errors). Progress Control, Software Quality Metrics
and Quality costs.
The main components are: functionality).
The main objective of Project Progress
Control is to monitor the progress
1 Reviews: Reviews are taken place during to ensure that it does not deviate of the project
from its initial plans. It also focuses on
design
review and Peer review. and
categorised as Formal coding phase. Reviews can resource usages, schedules, monitoring
be risk management activities and the budget.
2. Expert Opinions: Review A Software
Quality Metric is a measurement used to
done by external reviewer evaluate software quality in a
in-house development. to strengthen the system.
quality of
3. Software Testing: The Software Quality Costs are prevention,
According to D. Galin, appraisal, internal and external failure
carried out by a specialized Software Testing is a
team in which formal process Costs.
programs. software is examined 5.
by executing the Standardization Certification, and Assessment
4. Software Maintenance: Components:
It specifies following This component focuses on using external
i. Corrective Maintenance three categories: tools to achieve the goals of SQA. Therr ar
in which the corrections three main objectives:
software. are done 1. Utilization of international professional knowledge.
for failed
2. Improvement of coordination with other
organizations quality systems.
 STS QA - HCA (Mgt.) : Sem Itl 1.10 Software Quality
Assurance Fundamcntal
3.
Objective professional evaluation and measurement of the achievements
of ST & OA - MCA (gt.) :
Sem l
organizations quality systems. the 1.11 Software Quality Assurance Fundamentals
The standards are classified into two sub-classes: Organizing SQA- The Human
1. Quality Management SQA Unit
Standards focusing on "what" is required? Components
2. Project Process Standards focusing on "how" SQA trustees
it is done?
6. Organizing for SQA -The Human Components Committees
SOA cannot be directly Forums
applied to an organization; instead an
required. The organizational organizational bato i
base is made up 15 SOFTWARE QUALITY FACTORS
committees along with the management support.of the SQA Unit, SQA trustees a
Main objective of SQA organizational Quality factors are the overall attributes
base are: Rur time behavior (availability,
that affect:
1 To support the development and reliability)
implementation of the SQA system. System design behavior (testability, reusability)
2 To detect and prevent deviations fromn User experience (usability)
SQA standards and procedures.
3. To suggest improvements
to SQA components. Quality attributes are categorized as shown
in Fig. 1.1 by McCall, which focuses on
SOASystem is a very three important aspects of software product:
important element in any software
provides a mechanism to development project. It 1. Product Operation -
reduce the number of errors operational characteristics.
Various SQA components are summarized and prevent them in future 2. Product Transition -
in Table 1.2. ability to undergo change.
3. Product Revision - adaptability to new
Table 1.2: SQA Components environments.
SQA Components Maintainability
Sub-components Flexbilty Portability
Reusability
Pre-project Testability
Interoperability
Contract Review
Development and Quality Plans
Project Life Cycle Product Revision Product Transition
Reviews
Expert Opinions
Software Testing
Software Maintenance Product Operation
Quality Infrastructure
Procedures and Work Instructions Correctness Reliability Usability Integnty Efficiency
Supporting Quality Devices(Templates Fig. 1.1: McCall's Software Quality Factors
and
checklists)
1. Correctness:
Staff Training, Instruction and Certification
Preventive and Corrective Actions The extent to which a prograrmn specification is
satisfied and the customer's
Software Quality Management objectives are met.
Project Progress Control
System correctness refers to the fulfilment
Software Quality Metrics of the program code with its
specifications.
Software Quality costs
2. Reliability:
Standardization, Certification Quality Management
andsQA Assessment Standards The extent to which a program is expected to perform its intended
Project Process Standards function with
required correctness.
Contd. Reliability of a software system is derived from Correctness and Availability.
 Software Ouality Assuronco Fundamental.
1.12
-
ST & QA MCA (Mgt.)
: Sem M
1,13 Softwaro Quality Assurance Fundamentals
ST& QA
- MCA(Mgt.):Sem lll
as the probability that the system fulfils a function for a
o Reliability is defined
a
specified number of input trials under specified input conditions in specified 7. Interoperability:
time interval. Effort rcquired to pair one system to another.
Interoperability is the ability of
a
system to operate successfully by
3. Usability:
communicating andexchanging information with other external systems written
o This factor focus on
efforts required for learning. preparing input, using, ana
and run by external parties. With
an interoperable system, exchanging and
interpreting output of software.
IIsability also defines how well the application meets the user requirements by reusing information beComes casy.
being spontaneous, easy to localize and globalize, providing good access for 8. Efficiency:
It is the ability of a software system to fulfil its purpose with the best possible
disabled users, and resulting in a good overall user experience.
4. Integrity:
utilization of all necessary resources (time, storage, transmission channels, and
o This factor peripherals).
controls the unauthorized access to software.
9. Flexibility:
5.Portability:
oEfforts required to transfer the program from one Effort required modifying a working program.
environment to another. 10. Reusability:
comfort with which software can be
A

adapted to run on computers other than

the one for which it was designed. Extent to which a program or its part can be reused in other applications.
o The
portability of software is dependent on: 1.5.1 Software Quality Metrics
1 Degree of hardware independence.
2. Implementation
language.
e Software Quality Metrics required measuring Quality Factors:
3. Extent
of exploitation of specialized system functions. Auditability: The ease with which conformance to standards can be checked.
4. Hardware properties. Accuracy: The precision of computations and control.
6. Maintainability: Completeness: The degree to which full implementation is achieved.
Consistency: The use of uniform design and documentation techniques.
The ability of system to
undergo changes with an ease. These Error Tolerance: Damage that occurs when the program encounters an error.
damage the existing services, changes could
features, and interfaces while adding or Hardware Independence: Degree to which the software is detached from
the functionality, fixing errors, in changing the
order to meet new business requirements. hardware on which it operates.
It is an effort used in locating
and fixing an error in a program. Instrumentation: Degree to which the program monitors its own
Maintainability is equal to identifies errors that do Occur. operation and
suitability for debugging and
extenslon of functionality. modification, and o Operability: The ease
of operation of a program.
The maintainability a
of software system depends on its Security: Availability of mechanisms that protects the program
and Testability. Readability, Extensibility,
Simplicity: Degree to which a program can be understood
and the data.
easily.
i. Readability: Readability of system depends on The relationship between software
its: quality factors and these metrics is as shown
Form of representation. below:
Programming style. Table 1.3: Software Quality FactorS
Consistency. and Metrics
Quality Factors
Readability of the programming Metrics
languages. Correctness Completeness, Consistency
Quality of the documentation
and tools available Reliability
i. Extensibility: Extensibility alows for inspection.
required modifications
Accuracy, Consistency, Error
tolerance, Simplicity
appropriate locations to be made at Integrity
without undesirable the Auditability, Instrumentation,
ii. Testability: Effort required for testing side effects. Maintainability
Security
a program Instrumentation, Self-documentation,
correctly. ensuring that it performs Simplicity
Testability
Auditability, Self-documentation,
Usability Simplicity
Operability, Training
 ST& QA - MCA (Mgt.) : Sem ! 1.14 Software Quality
Assurance Fundamental
1.5.2 FURPS Model
ST & QA - MCA(Mgt.) : Sem lll
Robert Grady developed a set of software quality 1.15 Software Quality Assuranco
FURPS
factors which is called Fundamentals
stands for Functionality, Usability, FURPS. The key Elerments of TQM system are
Reliability,
Supportability. Perfornance, Table 1.4:
shown in the Fig. 1.3 and summarized below
and in
Functionality is assessed by evaluating
program, generality of functions and the feature set and capabilities Table 1.4: Key Elements
security of of the of TQM System
Usability is assessed by considering the system. Sr. Key Element
human Objective
documentation. factors, consistency No Includes
Reliability is evaluated and
by measuring frequency 1 Customer Focus To achieve
Time to Failure and Accuracy and severity of the failure, Mean total customer Study of customer's needs
Performance of the program. satisfaction.
ismeasured by processing speed, response and requirements.
efficiency. time, throughput and
Supportability combines Measuring and Managing
Computability, Configurability, customer's satisfaction.
Installability. Serviceability, and 2 Process TO reduce process variations
Improvement and to achieve continuous Business Process
Process Improvement Product development
Supportability
3
Human side of Process
To createea
: companywide
quality Focus areas include:
Functionality
quality culture.
Leadership, Management
Perforamance
Commitment, Total
FURPS
Participation, Employee
Empowerment and
other
4. Metrics, Models, Social and human
To drive continuous factors.
Usability Measurement and Measurement and
Reliability improvement in all quality Analysis
Analysis
parameters.

Fig. 1.2: FURPS Model

Total Quality Management
1.5.3 Total Quality Management Continuous Improvement
TQM is a management (TQM)
Six fundamental
approach to improve
steps of Quality the quality.
1. Characterize Improvement Paradigm
the project and its are:
2. Set the goals. environment. Customer
3. Choose Focus ProceSS
the appropriate processes. Improvement Human Side of
Quality
4. Execute
the processes.
5. Analyze Motrics, Modols,
the data. Measurements and
6. Package Analysis
the experience for reuse.

Fig, 1.3: Key Elements

of TQM
 ST& OA - MCA (Mgt.):Sem Ill 1.16 Software Quality
Assurance Fundamentals
1.6 SoFTWARE QUALITY METRICS: PROCESs
METRICS & ST & OA - MCA (hgt.) : Sem
METRICS PRODUCT ll 1.17 Software Qualily Assurance Fundamentals
Software metrics are classified into Table 1.5: Product Quality Metrics
three categories:
Metrics. Product, Process, Product
1) and Project
Prodct Metrics describe Quality Details
of code and Function the product characteristics such as size in terms Metrics
points, Cyclomatic of linee
Performance, and Quality level. complexity, Design
2) Process features Defect
Metrics are used to Density Number
example, defect removal inprove software development Defect Rate = of defects
effectiveness, testing and maintenance. For Metric Size X K
3) Project Metrics defect arrival, etc. Where, Kis specific time frame
describe the project and
number of software developers, characteristics and execution. o Size is
cost, schedule, For example software size measured in Lines
Software quality and productivity. lines of code (KLOC) or of Code (LOC) or Thousand
metrics are a subset in the number of function points.
aspects of the of software metrics that focus on
Product, Process,
closely associated with and Project. the quality
Process and Product Software quality metrics are more Thus, defect rate can
be defined as the number
1.6.1 Product Quality Metrics Metrics. KLOC ina given of valid defects per
time unit.
The metrics that covers For example,
product quality and customer o Defects in one year
Mean time to failure. satisfaction are: after
o Defect the product availability
Defect density. since the creation
o of module.
Customer problems. Defects found during an
inspection.
Customer satisfaction. From customer's perspective,
Product quality is
measured by the number release-to-release improvement goal of defect rate can be set for
software or by how of the product.
long the software can run of "bugs" (functional defects) in A good defect rate
target should lead to a
In operational before encountering a the release-to-release
definitions, the two "crash". inthe total number reduction
Defect Density (rate). metrics are Mean of defects, regardless of size.
The two metrics are Time To Failure (MTTF) Customer Measures the problems
1. MTTF: correlated but are different. and Problemns identified by customers
The problems metric using the product.
MTTF is Metric is measured in terms
also used to measure (PUM): of problems per user
working. how longa process or month
software is expected PUM =
In other words, measures to stay
it the time Total problems that customers
2. Defect Density between failures.
(rate): (true defects and non-defect-oriented reported
Measures the
defects related Total number of license-months problems) for a time period
functions. to the software of the software during
size in terms
of code lines or where, the period
According to IEEE o
An error is a
/ American National
Standards Institute
mber of license-months =
Number of installed licenses
human mistake (ANSI) standard Softwai of the
The resulting that results in incorrect (982.2):
o Total problems
..ber ...unths in
the calculation period.
fault is an accidental software. reported by customer's covers
fail to function as condition causes all valid
required. that a unit of defects. Invalid defects can and invalid
A
failure occurs the system to documentation, or even user be usability problems, unclear
when a functional errorS.
longer perform
its required function orunit of a software-related system o Approaches to
achieve a low PUM include:
cannot perform can no
it within specified Improve the development process
limits. to reduce the numerator
PUM. of

Contd.
 ST& QA- MCA (Mgt.) : Sem ll 1.18 Software Quality
Assuranco Fundamenta.
Improve upon factors such as usability,
customer education, and support documentation, ST & QA - MCA (Mgt.) : Sem IlI 1.19 Software Quality Assurance Fundamentals
to reduce the numerator
PUM. of
Cyclomatic This is a measure to control complexity of a program.
Increase the sale (the number of
installed Complexity
product to increase the denominator PUM. licenses) of the
of Software Test cost (in %) = Cost of testing / total cost "10o
Customer Customer satisfaction is
measured with the help Testing
Satisfaction the five-point scale: of survey data vis Cost to locate defect = Cost of testing / the number of defects located
Metrics 1) Very satisfied
Metrics Defects detected in testing = Defects detected in testing/total system
2) Satis fied defects
3) Neutral Defects detected in production = Defects detected in production/system
4) Dissatis fied size
5) Very dissatisfied Defect Defcct removal efficiency can be defined as follows:
Customer Satisfaction Removal Defects removed during a development phase
DRE =
functionality, usability, is monitored with factors such as Efficiency x
Defects latent in the product 100%
performance, reliability, maintainability.
-
(Process
documentation and many more. This gives approximated value, because
the total number of latent
Example metrics can be: Quality (hidden) defects in the product at any given
phase is not known in
Metric) advance.
Percent of completely
satisfied customers It is usually estimated by: Defects
Percent of satisfied customers removed during the phase +
(satisfied and completely defccts found later.
Percent of dissatisfied satisfied)
customers (dissatisfied Effectiveness of development process
dissatisfied) and completely increases with the higher value
of metric; which results in fewer defects
Percent of nonsatisfied for the next phase.
customers (neutral,
completely dissatisfied) dissatisfied, and
17 SOFTWARE RELIABILITY
RELIABILITY
FACTORS: ROCOF, MTTE, MTTR, MEASUREMENT
MTBF, POFOD, AVAILABILITY
Customer
Satisfaction 1.74 Software Reliability
Customer
Problems Software Reliability is the probability
of failure-free software operation for a
specified period of time in a specified
environment.
It is a broad concept and can
Defects be measured directly and can
historical and developmental data. be estimated using
There are three phases in the life
of software. i.e. Testing, Useful life(i.e. actual usage)
and Obsolescence(where software is no
longer in use).
In testing phase, failure rate is
Fig. 1.4: Scopes quite high. During software usage,
Good customer of Quality metrics approximately constant and it either stays constant or failure rate is
satisfaction is directly with the time. (Refer Fig. 1.5)
starts decreasing gradually
which in turn is proportional to
directly proportional reduced customer
the Fig.1.4. to decrease in problems: Software reliability depends on two
number of defects as factors, namely,
illustrated in (i) The number of faults present in the software.
(ii) The ways users operate
Contd.
the system.
 ST& QA - MCA (MgL): Sem 1.20 Software Quallty
Assurance Fundarnental.

Testing
ST & QA - MCA (Mgt.) :
Sem ll 1.21 Software Quality Assurance Fundamentals
phase
Useful ife
It is obtained by observing a large number of failures in the software
Obsolescence product.
Failure To measure MTTF, failure data for n failures is recorded.
rale ...
If the failures occurat the time instants T1, T2, Tn then MTTF can be
calculated as:
MITE = ((T2- T1) + (T3 - T2) + ... + (Tn+1-
Tn))/ (n-1)
2. Mean Time To Repair (MTTR):
Time It is the average time needed for system to repair a failed
software nodule.
Fig. 1.5: Software Reliability 3. Mean Time Between Failure (MTBE):
Curve
Key concepts in discussing It is the average time between system breakdowns.
reliability:
1. Fault: Fault can cause a program to It is calculated as, MTBF= MTTF + MTTR
perform in an un-intended manner. Problerm with MTBF: It projects a
2. Failure: A
failure is said to occur time span between failures, but does not
from the expected one.
if the actual outcomne of a program provide a projected failure rate.
is different
4. Rate of occurrence
3. Time: Time is a
key concept in the formulation
of failure (ROCOF):
between two successive of reliability. If the time gap It is the number of failures appearing
failures is short, we say ina unit time interval. The number of
o Three that the system is less reliable. unexpected events over a specific time
of operation. ROCOF is the frequency
forms of time are considered as follows: of occurrence with which unexpected role is likely appear.
() Execution time (): The execution
A ROCOF of 0.02 mean
to
time for a software system that two failures are likely to occur in each 100
time spent by a processor in executing is the actual
operational time unit steps. It is also called
(iü) Calendar
timne (t) : Calendar
the software system. the failure intensity metric.
time is the time more commonly 5. Probability of Failure on
Demand (POFOD):
followed by everyone understood and
(iii) Clock time:
in everyday life. POFOD is the possibility
Clock time refers that the system will fail when service request
end of program execution.
the elapsed time between made. It is the number of system is
It also includes the wait
the start and the deficiency given several systems inputs.
system and execution time of the software This attribute does not involve time measurements
times of other software systems. like the other attributes.
4. Intervals (MTTR, MTTF, A POFOD of 0.1 means
MTBF), that one out of ten service requests may fail. POFOD
an essential measure for is
1.7.2 Reliability Measurement safety-critical systems. POFOD is relevant
for
Reliability attributes are Factors protection systems where services are demanded
occasionally.
the measure of software 6. Availability (AVAIL):
reliability requirements reliability. There many
common reliability for different software o Availability is the probability that the system
measures. Reliability but all the software some is applicable for use at a given
software products may be attributes for different have time. It takes into account the repair
time & the restart time for the system.
different. categories of An availability of 0.995 means
There are six reliability that in every 1000 time units, the system is
attributes which can
ofa software product. be used to express
the reliability
feasible to be available for 995
of these.
1. Mean Time The percentage of time that a system
To Failure (MTTF): is applicable for use, taking into account
It is abasic measure planned and unplanned downtime. If a system
is down an average of four
of reliability for non-repairable hours out of 100 hours of operation, its AVAIL
time expected untilthe systems. It is is 96%.
first failure of a product. the mean This plays a vital role in telecommunication
systems and operating systerms.
These systems need to run even during
the repair time.
 ST &OA - MCA(lgt.): Sem I/ 1.22 Software Quality Assuranco Fundamenlals

Summary ST & OA - MCA (Mgt.): Sem Ill 1.23 Software Quality Assurance Fundamentals
Software Quality Assurance (SQA) is a set of activities for ensuring qualit,
software engineering processesthat ultimately results,,or at least gives confidence,
: 4. Size and Complexity are a part of
(a) Product Metrics (b) Process Metrics
the quality of software products. in
(c) Projcct Metrics of the mentioned
(d) All
Ouality Assurance (OA) aims to prevent defects with a
focus on the process ueod. 5. Percentage of modules that were inspected is a part of
make the product.
(a) Product Metrics (b) Process Metrics
Quality Control (QC) aims to identify defects in the final product.
(c) Project Metrics (d) All of the mentioned
SQA plan provides a road map for
establishing software quality assurance. The nl 6. Which is not McCall's software quality factor?
serves as a template for various SQA
activities that are instituted for each softuwa. (a) Product Revision
project. (b) Product Transition
(c) Product Operation (d) Product Generation
Software quality assurance (SQA) is
the process of checking the quality
based on adefined set of standards. of the product 7
Which of the foilowing is not a SQA plan for a project?
These standards are
of the development stage and are used as guidelines established at the beginning (a) Evaluations to be performed
for testers before the product's (b) Amount of technical work
release.
SQA building blocks or components ensure an (c) Audit and reviews to be performed
acceptable level of quality. The (d) Documents to be produced
Componentsused by the SQA System are by the SQA group
classified into six different categories; each
of which guarantees maximum quality 8. TQM stands for
andensures the execution with the standards
and procedures. (a) Time Quality Management
(b) Total Quality Management
Software metrics are classified (c) Time Quantity Management
into three categories: Product, Process, (d) Total Quantity Management
Metrics. and Project 9. Which of the following
is/are SQA standards?
Software Reliability is the probability (a) Documents standards
of failure-free software operation (b) Design standards
specified period of time in a specified for a (c) Code
environment. standards (d) All of the above
Reliability attributes are the measure 10. Quality control (Qc) is
of software reliability. oriented.
Check Your Understanding (a) Process
(b) Procedure
1. According to components FURPS (c) Program
of model, which of the following (d) Product
to S? does not belong
(a) Testability ANSWERS
(b) Speed Efficiency
(c) Serviceability 1. (b) 2. (b) 3. (b) 4. (a) 5. (b)
(d) Installability 6. (d) 7. (b) 8. (b)
2. How many product
quality factors are proposed 9. (d) 10. (d)
(a) 2
in McCallquality model?
(b) 3
(c) 11 Practice Questions
(d) 8
3. What is MTTF?
QIAnswer the following questions
(a) Maximum time to in short.
failure (b) Mean time to 1, What is SQA?
(c) Minimum time to failure failure
(d) None 2. What is Software Reliability?
of the mentioned.
3. Write any 2 SQAactivities.

4. Write any 2 Software quality factors.

 Software Quality Assurance Fundaments!.
- MCA
(Mgt.):Sem Ill 1.24
ST& OA
metrics?
S.What is Proccess and Product
components of SQA building blocks?
Q.II Answer
6. Which are different

1.
the following questions.
Explain various SQA attributes.
2..
2. What are the building blocks of SQA?
3. Explain various quality factor of
SQA. Software Testing
4. What does SQA ensure? What are the goals of an SQA activity?

6.
5. What is meant by Software Quality Control?
Describe the various level of CMM.
Fundamentals
7. Explain with an example the six sigma measure of software quality.

Q.III Write a short note on:

Objectives...
1. ROCOF
To understand the definition and objectives of Testing, Role of testing and its cffect on
2. Quality control
quality.
3. Cost of quality
To learn causes of Software Failure.
4. MTTF
I To study economics of Testing and Testing Principles.
5. MIBF To learn Software Testing Life cycle and Validation & Verification Concepts.
O To know the Agile Testing.
To study levels of testing and testing types.
To learntheconcept of Smoke Testing and Sanity Testing.

2:1 DEFINITION & OBIECTIVES OF TESTING

Software testing is a process to identify the completeness, correctness and quality of
developed software.
Testing is the process of evaluating a system or a module by manual or automated
means to verify that it satisfies the specified customer requirements.
Testing is a process of executing a program with the intention of error(s) finding.
It is a process of discovering every -nssible fault or weakness in the product.
The primary role of testing is not the
. monstration of correct performance, but
the exposure of hidden defects. Glen Myers
Testing is concerned with errors, faults, failures and incidents. It is an act of
exercising the software with an objective of- Finding failure(s) and Demonstrating
correct execution. - Paul Jorgensen
When testing detects an error, debugging is an action that results in finding the cause
of failure and removing it.

(2.1)
 ST &
QA MCA (Mgt.) : Scm lIl 2.2 Software Testing
Fundamental,
It determines why a system doesn't meet one or mnore of its specifications -
Softwarc Testing Fundamentals
c ST& QA MCA (Mgt.) : Sem || 2.3
requirements and making it meet those specifications.
Debugging is not testing but testing can be a part of debugging. CAUSES OF SOFTWARE FAILURE: DEFINITION OF ERROR, BUG,
There are two basic functions of software
testing: Verification and Validation FAULT, DEFECT AND FAILURE
2.1.1 Testing Objectives Testing is the process of identifying defects, where a defect is any variance between
Key objectives of Software Testing are: actual and expected results. "A mistake in coding is called Error, an error found by
To expose undiscovered error(s). tester is called Defect, defect accepted by development team then it is called Bug,
To
establish a confidence build does not meet the requirements then it is Failure."
that a program does what
functions correctly. it is supposed to do and Causes of System Failure:
To ensure that Miscalculated time and Budget frames
software is error free.
To measure quality
Lack of Communication
of software. o No End-user involvement
To confirm that a program
performs its intended functions Unfocused Executive Spornsors
o To identify correctly.
the difference between o Lack
of Quality Testing
expected result and actual
To ensure result.
that a system is ready to use. Let us see definitions of Error, Bug, Fault, Defect
and Failure.
To evaluate and
verify the documents 2.3.1 ERROR
troubleshooting, and user such as online help,
training for correctness. installation and The system is in a state such that further processing
by the system will lead to a
2.2 ROLE OF TESTING AND ITS EFFECT failure,
ON QUALITY An error is a mistake, misconception or
Testing is an activity misunderstanding on the part ofa software
that occurs on a deliverable, developer. It might be typographical error, a
misleading of specifications, a
quality. Testing helps in order to measure
support the delivery a its perceived misunderstanding of what a subroutine does.
part of a quality process. of quality product provided
it is run as The errors may be:
Testing needs a strategy,
approach, Programming errors.
that the product quality delivery and plan derived from quality processes to ensure Incorrect implementation of the requireme:ts or
is robust. functional specifications
Role of Software because of misunderstandings and/or incomplete
Testing: requirements or functional
1. Testing systematically uncovers specifications.
time and immediately different classes of errors Incorrect human action that produces erroneous step, process,
flags these errors in a minimum amount or inaccurate
2. Testing for investigation of result.
demonstrates that and fixes.
the software appears User interface errors.
specifications. to be working as
stated in the Calculation errors.
3 Good testing covers
Instalation, Functionality, Errors in handling or interpreting data.
the system. and operational ease
to learn and use Documentation - The user does not observe the operation
4. More importantly, described in manuals.
as Software Testing errors.
business perspective, Testing is a part of every
major benefit organization. From a 2:3:2 Software Bug
software; and better quality of testing is that
software sells better. it produces good
quality A software bug is the common term used to describe an error, flaw,
or fault in a computer program or system mistake, failure
that produces an incorrect or unexpected
result, or which causes the program to perform
in an manner.
un-intended
 ST& QA - MCA (Mgt.) : Senm
ll 2.4 Software Testlng
Fundamentx.
Most bugs arise from mistakes and errors in either a program's source
code or ST & QA - MCA (gt.) :
Sem I| 2.5 Softwaro Testing Fundamentals
design, but the main cause can be traced to the specification. its

2.3.3 FAULT Failures can be discovered both before and after system delivery, as they can occur in
testing as well as in operation.
fault occurs vhen a human error results in a mistake in some
A

A
software product{s). Faults are seen by the developer, while failures are scen by the users.
fault is the difference between an incorrect program
and the correct version Ideally the life of a bug ends when it is uncovered in testing and fixed.
A single error can result in one or more
faults.
For example, a developer
might misunderstand a user-interface Lead to Lead to
therefore create a design that includes requirement
misunderstanding. The design fault can Error Fault Failure
result in incorrect code, as well as l
incorrect instructions in the user
manual
Lead to Incorrect Code
Logical Error Unable 10 procoSs
Human Error
Fault
Fig. 2.2 Relation betwcen Error, Fault
and Failurc
Misunderstanding GUI For example, consider an operation on ATM
Design Fault Incorrect code machine: A developer might have
requirements forgotten to fire an update query on the database when
Incorrect instructions the user changes the pin
.Fig. 2.2: in number, and the screen displays the message "Your PIN
Errors Lead to Fault User manual number has been changed"!
When the user tries to access the system
with new PIN numnber.... The system gives the
One fault can message "Sorry unable to process".
result in multiple changes to one
sections of a piece code) or product (such as changing
of multiple changes to multiple several
2:4% ECONOMICS OF TESTING
to requirements, products (such as change
design code and test plans,etc.).
2.3.4 DEFECTS There isa definite economic impact
of software testing. One economic impact
the cost of defects.This isa very real and very is from
Abnormal behavior tangible cost. Another economic impact
of the software i.e. deviation is from the way we perform testing. It is
It is a fault in program from the expected result. possible to have very good motivations
which causes the program testing goals while testing in a very inefficient way. and
manner. to perform in an un-intended
A
Software bug occurs The Cost of Defects:
when one or more of following Most defects originate in
The Software rules is true: requirements and design, but most of the
doesn't do something occurs in a traditional testing effort
do, that the product specification says "testing" phase toward the end of the project.
it should well known facts about software
One of the most
The Software does defects is that the longer they go undetected,
something that the product the
For example, Requirements specification says it should more expensive they are to fix.
and Specification defects, not do.
or Testing defects. Design defects, Coding If you want to make testing more efficient
defects and reduce the overall cost of testing and
defects, test early in the project and continue
2.3.5 FAILURE testing throughout the project.
A
fault (bug) can go
undetected until a
failure occurs. Failure can
2:5 SEVEN TESTING PRINCIPLES
follows:
be defined as Testing is a crucial element of software
Deviation of the system development. It can also be a complex activity
from its expected behavior to structure correctly, and in a way
The inability a or service. that supports maximum efficiency. Because of
of system or module to this complexity, it is always helpful to review processes
specified performance perform its required and guidelines to ensure you
requirements. function as per the are following best practice.
The ISTQB (International Software
Testing Qualifications
Board), lists seven fundamental
principles of testing.
 ST&QA - MCA (Mgt.) : Sem II
2.6 Softwarc Testing1Fundamenta
The Seven Principles of Testing:
1. Testing shows the presence of defects ST & QA - MCA (Mgt.) :
and not their absence: Sem I| 2.7 Software Testing Fundamenlals
o
Testing shows the presence of
defects in the software. The goal whole system. The more complicated a component, or
make the software fail. Sufficient
testing reduces the presence of of testing is the more third-party
testers are unable to find dependencies there are, the more likely it is that there will be defects.
defects defects. Inheriting
after repeated regression testing In case legacy code, and developing new features in certain components
that the software is bug-free. doesn't
m
that are
undergoing frequent changes and are therefore more volatile, can also cause
It is important to remember defect clustering.
however that while
bugsand not their absence, testing shows the presenea.
detailed testing willgive everyone 5. Beware of the Pesticide Paradox:
software will not fail. Having a confidence that
test plans, reports comprehensive test strategy that includes detailo Pesticide Paradox in software testing is the process
and statistics along with cases again and again, of repeating the same test
this. This strategy reassures testing release plans can eventually, the same test cases will no longer
all help wih bugs. So to overcome find new
confidence that the right areas are cients as to testing progress this Pesticide Paradox, it is necessary to review the test cases
being tested.
and providine regularly and add or update them to find more defects.
2. Exhaustive
testing is imnpossible: 6. Testing is context dependent:
Exhaustive Testing Testing approach depends on the context
is testing all the functionalities we develop. We do test
of the
inputs and preconditions are using
known as Exhaustive testing. all valid and invalia the software differently in different contexts.software
The software execution For example, online banking
time and costs will rise we application requires a different approach of testing compared to an e-commerce
test conditions. So
instead of doing exhaustive if keep on testing all possible site.
taken into consideration testing, risks and priorities 7. Absence-of-errors a
while doing testing will be is fallacy:
3. Early testing saves and estimating testing If wrong requirements were incorporated
time and money: efforts.
into the software, 99% of bug-free
Testing early is fundamentally software may still be unusable and
even mean inportant in the software the software is not addressing the
testing requirements lifecycle. needs. business
before coding has This could
testing reduces the cost started. So conducting The software which we built not a
of fixing defects. early only be 99% bug-free software
but also it must
Assume two situations, fulfill the business needs otherwise
first one is you have identified it will become an unusable software.
in the requirement
gathering phase and an incorrect requirement 2.6 SOFTWARE TESTING LIFE CYCLE
bug in the fully developed the second one is you
functionality. It is have identified a Once the project is confirmed to
requirement compared cheaper to change start, project development can
to fixing the fully
working as intended. developed functionality the incorrect following phases: be divided into the
4. Defects cluster which is not
Software Requirements Phase.
together:
Defect Clustering Software Design Phase.
in software testing means
contains most of the that a small module or Implementation Phase.
bugs or it has the most functionality
This is the idea operational failures. Testing Phase.
that certain components or
the most number modules of software Maintenance and Support Phase.
Therefore, testing of issues, or are responsible for most usually contain
The process of testing software
should be focused on operational in a planned and systematic way
expected - and these areas (proportionallyfailures. is known as
later observed - defect to
Software Testing Lifecycle (STLC).
Testing life cycle defines the steps or
based on "Pareto density of these areas). the testing stages in
Principle" which Defect Clustering the software. There is no fixed standard STLC,
of the defects found are is also known as is of different organizations have
due to 20% of the 80-20 rule. It means different phases; However, generic phases involved in testing,
This is particularly modules in the that 80% Software Development Life Cycle are: with regard to the
the case with large application.
can vary and complex systems,
for a range of reasons. but defect density
1. Requirements Analysis.
Issues are not evenly
distributed throughout 2. Test Planning.
the
3. Test Design.
 ST& QA - MCA (Mgt.) : Sem l 2.8 Softwaro Testingi Fundamenta

4. Test Implementation. ST& QA - MCA (Mgt.) : Sem l! 2.9 Software TestingFundamentals

S. Test Debugging.
development process such as design components, software modules, test cases,
6. System Testing.
and test results. t can be implemented in a Spreadsheet, Word processor table,
7. Acceptance Testing. Database, or Web page.
8. Operations and Maintenance. In this phase, testers analyse the customer requirements and work with
Fig. 2.3 shows the Waterfall Test Process for Software Testing.
developers during the design phase to see which requirements are testable and
Requirements how they are going to test those requirements.
Analyss
It is very important to start testing activities from the requirements phase
because the cost of fixing defect is very less if it is found in requirements phase
Test
Plannng rather than in later phases.
2. Test Planning:
Test A test plan document
Design
should be preparcd after the requirements of the projcct are
confirmed.
Test planning includes determining the scope, approach, resources,
Test and schedule
Implementation of the intended testing activities.
The requirements traceability matrix is a useful tool
Test
in the test-planning phase
Debuggng because it can be used to estimate the scope of testing
necded to cover the
cssential requirements.
System In this phase, all the planning about testing is done like:
Testing
What needs to be tested?
How testing will be done?
Acceptance
Testing Mapping of tests to the requirements.
Testing strategies to be followed.
Operatons & The testing methodologies.
Mantenance
Fig. 2.3: Software Testing
Life Cycle Number of man-hours required.
1. Requirements Analysis: Process
Resources required for the whole testing process.
When analyzing software
requirements, the goals The testing tools that are to be used.
development team are of the test team and the
different. Both teams need a What will be the test environment?
requirements specification as input to clear, unambiguous
their jobs. An assessment of test-related risks and a plan
The development team for their mitigation.
wants a complete set 3. Test Design:
generate a system functional of requirements that can
specification, which will be used to
code the software. allow them to design In this phase various test design
techniques (Black Box or White Box) are used to
and
The test team, needs a design the test cases for testing.
set of requirements
plan, develop test cases, that will allow A test case represents the set
and run their system and acceptance them to write a test of operations that are defined to run. Test cases need
to be designed, written, and debugged
A
useful output of the requirements tests. before they can be used.
teams analysis phase for both A test design consists of two components:
isa
a document
requirements traceability
matrix. A
development and test Test Architecture and Detailed Test
that maps each requirement requirementstraceability matrix is Designs.
to other work products The Test architecture organizes the tests
in the into groups such as functional tests,
performance tests, security tests, and so on.
 ST& OA - MCA (Mgt.) : Sem lll 2.10 Softwaro
TestingFundamenty.
The Detailed test designs describe the objective of each test,
data necded to conduct the test, the expected result for
the equipment ST & QA - MCA (Mgt.) : Sem I| 2.11 Software Testing Fundamentals
cach test, and tracesa
test back to the requirement being validated by the test. ths Acceptance Test:
Detailed test cases can be developed from the test designs. The When system testing is completed, the product can be sent to the users for
level
neededfor a written test procedure depends on of detal
the sskill and domain knowledge acceptance testing. If the users are internal to the company,the testing is usually
tester. Test cases should be prepared based on of called alpha testing. If the users are customers who are willing to work with the
the following scenarios:
Positive scenarios product before it is finished, the testing is called beta testing. The system is
Negative scenarios installed on an experimental basis for the purpose of finding bugs.
Boundary conditions When the testing is done, the customer gives feedback about - which
requirements are not satisfied or which requirements need to be changed in order
Real World scenarios
to proceed to the final testing.
4. Test Implementation
andDebugging: The final type of acceptance test is the installation test, which involves installing a
Once the test cases are written,
they are debugged by testing them a
completed version of the product at the user sites for the purpose
of obtaining
of the product software, which gives the final test cases. against buila
customer agreement that the product meets all requirements
and is ready for
Test cases are executed and delivery.
defects/bugs are
execution reports are created and circulated reported in bug tracking tool. Tec 7. Maintenance:
to project stakeholders.
After developers fix the bugs Maintenance of a product is a challenging task for the development
raised by new build with fixes are
testers, testers do re-testing to ensure testers' given to test team.
team and the
affected any other areas software. that the defect has been fixed and nct
of Maintenance for the developer consists of fixing
bugs that are found during
After tester assures that defects customer operation and adding enhancements to
have been fixed and no more product functionality to meet
remain in software the build is critical defects the evolving customer requirements.
given for final testing.
5. System Test: A document is prepared to
handle similar problems in future releases.
A
set of finished, debugged test cases For the test organization, maintenance means
can be used in verifying bug fixes, testing
test. The purpose system the next phase i.e. the system enhanced functionality, and running regression tests on new
of testing is to ensure that the releases of the
customer expects it to do. software does what the product to ensure that the previously working functionality has not been
There are two main types system
tests and Performance tests. of tests: Functional disturbed by the new changes.
Functional testing requires no The testing process is an iterative process. Once
knowledge of the internal the bugs are fixed, the testing has
software, but it does require workings to be done repeatedly. Thus the testing process an
knowledge of the system's of the is unending process.
It consists of aset tests functional requirements. 2. VALIDATION & VERIFICATION CONCEPTS -
of that determines if the system
to do from the
user's perspective. Once does what it is supposed V MODEL AND
the basic functionality WMODEL
O

ensured, testing can turn to of a system is

how well
Performance testing is performed the system performs its functions. Tagline of Verification and Validation is
the assurance that a software system meets a
a particular workload. to determine how user's needs.
system performs under
It also validates and verifies fast
system, such as scalability, other quality attributes the Verification and Validation (VSv) is a disciplined
reliability and resource usage. of approach to assess software
products throughout the product life cycle.
Inaddition to functional and performance
tests that may need to tests, there are a A VEV process ensures quality
be performed during variety of additional product (software) and also satisfies user
security tests, installation tests, the system test phase. These requirements.
compatibility tests, include
Two principle objectives of VSV:
tests. If any failures occur, usability tests, and upgrade
the bugs should be reported The discovery of defects ina system.
immediately to get them fixed. to the developer
The assessment of whether or not
the system is usable in an operational
situation.
 Fundamentals
Software Testing Fundamena, Sottware Testing
:
2.12 2.13
ST& QA- MCA (Mgt.) Sem ll QA MCA (Mgt.) Sem
&
:1|
ST
executing
reviewing/ It the process of
is
Verification: meot.. It is the process of to see how it behaves.
process of confirming whether the software something
2
throughout
Verification is the inspecting deliverables
specifications. the life cycle.
It is the process of reviewing/
inspecting deliverables throughout the
Verification is examining Product Requirements,
Specifications,
life cycle
Design, Code . 3 It examines -
It exatmines -
Ready product for
errors, fault
Product requirements failures.
errors, faults and failures. and
, Specification, design
Verification is usually performed statically, i.e. inspecting
without execution on
Code for errors, faults and
computer. failures
are examples of verification techniques. i.e.
Inspections, Walkthroughs and Reviews It is performed dynamically
a particular phase in the It is performed statically i.e. on
Verification is the assurance that the products of 4. on a testing with execution
phase. inspecting without execution
development process are consistent with the requirements of that computer.
computer.
It is a low level activity. assurance that the
Verification is the assurance that Validation the
For S.
In simple terms, verification makes sure that the "product is being built right". final product satisfies the system
the products of a particular phase in
example, one of the purposes of system testing is to give assurance that the
system
process arc requirements.
the development
design is consistent with the requirements of system design phase.
consistent with the requirements of
Validation: that phase.
Validation is the process of confirming whether software meets user's requirements. It is a high level activity.
6. It is a low level activity.
The process of executing something to see howit behaves.
7. Verification Methods: Validation methods:
Unit, Integration, System, and Acceptance testing are examples of validation
Inspections White box testing
techniques.
Walkthroughs Black box testing
Validation is usually performed dynamically ie. testing with execution on a

Computer. Reviews
Validation is the assurance that the final product satisfies the system requirements. 8. Verification makes sure that the Validation makes sure that the
It is a high level activity. "product is being built right". "right product is being built".
In simple terms, validation makes sure that the "right product is being built".
2:7.1 V Model
The purpose of validation is to ensure that the system
has implemented all
requirements, so that each function can be traced back to a A contemporary of traditional software development model is 'V-Model'. V-Model also
particular customer
requirement. referred to as the Verification and Validation Model. This is an extension of
Table 2.1 summarizes the difference
between Verification the Waterfall model.
and Validation.
In this, each phase of SDLC must complete before the next phase starts. It follows a
Table 2.1: Difference between
Verification and Validation
sequential design process same as the waterfall model. Testing of the device is
Sr, No.
Verification planned in parallel with a corresponding stage of development.
Validation
1, It is the process of confirming The crux of V model establishes an association between each phase of testing with
It is the process
whether software meets of confirming that of development. The phases of testing are categorised as "Validation Phase" and
its whether software meets
specifications. user's that of development as "Verification Phase". Therefore for each phase of development
requirements.
there's a corresponding test activity planned in advance.
Contd..
 - : 2.14 Software Testing Fundamental,
ST& QA MCA (Mgt.) Sem !
Architecture of V Model: ST & QA- MCA (Mgt.) : Sem ll 2.15 Software Testing Fundamentals

Developer's life cycle Tester's lifo cycle

build isoptimized for better performance, and the code goes through many code
reviews to check the performance.
Business req. Acceptance
specification Testing
Phases of Validation Phase of V-model:
1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are
developed during the
module design phase. These UTPs are executed to eliminate errors at code level or
System Req. System
specification Integration unit level. A unit is the smallest entity which can independently exist, e.g., a
Phase
Testing program module. Unit testing verifies that the smallest entity can
function
dldation correctly when isolated from the rest of the codes/ units.
High level Component 2. Integration Testing: Integration Test Plans are developed during
Design Testing the
Val Architectural Design Phase. The term 'integration testing' refers to collaborate
pieces of code together to verify that they perform as a single
entity.
Low level 3. System Testing: System Tests Plans are developed
Unit Testing during System Design Phase.
Design
Unlike Unit and Integration Test Plans, System Tests
Plans are composed by the
client's business team.
System Testing is performed when the complete system is
Coding ready, the application
is then run on.the target environment in which must operate,
is drawn to figure out whether the system is
it and a conclusion
Fig.: 2,4: Architecture ofV and V Model capable of performing efficiently
Phases ofV Model: with least response time.
Phases of Verification Phase of V-model: 4. Acceptance Testing: Acceptance testing is related to
the business requirement
analysis part. It includes testing the software
1. Business Requirement Analysis: This is the first step product in user atmosphere.
where product Acceptance tests expose the compatibility problems
requirenents understood from the customer's side. This phase contains detailed with the different systemns,
which is available within the user atmosphere. It discovers
communication to understand customer's expectations the non-functional
and exact requirements. problemns like load and performance defects
2. System Design: In this stage, system engineers within the real user atmosphere.
analyze and interpret the business When to use V-Model?
of the proposed system by studying the user requirements document. System The V-shaped model should be used when
design is aimed at writing a detailed hardware and the requirement is well defined and not
software specification. ambiguous.
3. Architectural Design: Architectural
design is concerned with drafting the The V-shaped model should be used for
technical methodologies to be adopted with small to medium-sized projects where
regard to completion of software requirements are clearly defined and fixed.
development objectives. Architectural design is
often termed as 'high-level The V-shaped model should be chosen when sample
design' which is aimed at providing an
overview of solution, platform, system, technical resources are available
with essential technical expertise.
product and service.
Advantages:
4. Module Design: In the module
design phase, the system breaks down
modules. The detailed design into small 1. Easy to understand.
of the modules is specified, which is
Level Design. known as LOW 2. Works well for small plans where requirements are easily understood.
5. Coding Phase: After 3. Testing Methods like planning, test designing happens well before coding.
designing, the coding phase is started. Based on
requirements, a suitable programming the 4. This model avoids the downward flow of the defects.
language is decided. There are some
guidelines and standards coding. 5. This saves a lot
for Before checking in the repository, of time. Hence a higher chance of success over the waterfall
the final model.
 ST & QA- MCA (Mgt.): Sem ll 2.16 Software Testing Fundanenta

Disadvantages: ST QA - MCA (Mgt.): Sem Ill

&
2.17 Software Testing Fundamentals
1. Very rigid and least flexible.

2. Not a good for a complex project. The product is then sent for testing using various testing methodologies such as
3. Ifany changes happen in the midway, then the test c documents Unit testing, Integration testing and Specification-based testing, etc.
along with the
required documents, has to be updated. i Once the product is tested thoroughly then it undergoes regression test cycles and
user acceptance testing.
4. Software is developed during theimplementation stage,
sO no carly prototypes Advantages:
the software are produced. of
1. Tackles all those aspects that are skipped in the V Model of so ftware development.
2.7.2 W Model 2. It is one such software development model which is designed to achieve various
This model introduced by Paul Herzlich. demands and requirements ofa developer.
It indicates the one-to-one
exists between the documents and test activities. relationship th.. 3. The importance of the tests and the ordering of the individual activities
for
testing are clear.
W model is a sequential approach to test a
development of the product is complete
product. It can be done only once ..
4. During the test phase, the developer is responsible for the rermoval of
with no modifications required to be donein defects and
between. the correction of the implementation.
W-Model is a variant of the V-Model. 5. The testing process is carried out parallel to the development process. It is not
It is specifically focused on identifying produet
risks and concentrates on points where testing can first started after the development is complete.
be most effective.
Disadvantages:
Write Tost the 1. This model is difficult to implement.
Requirements Install Acceptance
Requirements System Test 2. In the most of the cases, resource allocation
might not be sufficient.
28 AGILE TESTING -TEST DRIVEN SOFTWARE DEVELOPMENT
Specify Test the
System Build System
Speclficalions Agile testing is a software testing process
Systom Test that follows the principles of Agile
Software Development. Agile testing methodology aligns
with iterative
Development Methodology in which requirements develop
Design Test the Bulld Integration customers and testing teams. gradually from
System Design Software Test
In this approach, every iteration has its own
testing phase. The regression tests can be
run every time new functions or logic are
released.
Write Unit Test Driven Development is the prOcess in which test cases are
Code Test code that validates those cases. It depends on
written before the
repetition of a very short development
cycle.
Fig. 2.5: W Model
Phases of W-Model: 2.8.1 Types of Testing in Agile
Using W-model helps in 1. Acceptance Test-Driven Development (ATDD):
ensuring that each phase
verified and validated. W-model of the product development is ATDD isa form of TDD (Test Driven
can be divided Development). It holds the collaborative nature of
Building test plan and test into a number of stages Agile testing, bringing together customers,
strategy to ensure that includes: developers and testers to create
rigorously before delivery. that the product delivered acceptance tests from the customer's point of view. Only once
is tested these tests have been
Identifying the scenario for created is the corresponding functionality developed. It's easy to create
the product. test cases
o Preparing with this style of workflow.
the test cases using specification
Reviewingthe test cases and design documents. This gives developers direct insight into what customers
want and how the product
and sharing an update on will be used, removing ambiguity from the process
the basis of review comments. and reducing the chances of large
errors being made.
 ST & QA - MCA (Agt.) : Sem 2,18
Il Softwaro Tosting
Fundameru
2. Behaviour-Driven Development (BDD):
ST & QA - MCA (Mgt.) : Sem )
BDD based on and enhances test-driven development
is 2.19 Software Testing Fundamenlals
and acceptance test-drivet
development. Business Facing
The primary purpose of
this development is to emphasize the identification
business nceds and outputs. And c
the development should be consistent a busines, Functional Tests Exploratory Tests
output. to Programming

Acceptance Tests Usability Tests

enbnuo
3. Exploratory Testing
in Agile:
Exploratory testing is a very
important part of the agile test as
unknown risks from the
software that a simple it helps discover ih. Support
pnpud

noticed. testing approach could not ha. Unit Tests Performanco Tests
Integration Tests Load Tests
To explore each aspect Compornent Tests Stress Tests
of the software functionality, the test System Tests Security Tests
test cases, executes different tests, engineer creates varion.
and records the process to learn
itsparticular flow. it and understam) Technology Facing
4. Session-based Testing:
Fig. 2.6: Four Quadrants of
It is mainly is created on Agile Testing
the values of exploratory Quadrant 1:Unit Level, Technology
Though session-based testing. Facing
testing contains some structure It supports the developers
exploratory testing is and on the other hand and can be automated.
performed unexpectedly Ouadrant 2: System Level,
help usidentify the hidden without any planning. Business Facing
bugs and defects in the It is used to
The session-based particular software. It validates product behavior
testing structure is prepared and Automated or Manual testing.
sessions where test by executing the tests Quadrant 3: System or User Acceptance
engineers must report in continuous o It focuses on
Level, Business Facing
process. the tests, which took place real-timne scenarios and uses
throughout the Manual testing.
Quadrant 4: System or Operational
2,8.2 Extreme Programming (XP) Acceptance Level, Technology
It focuses on software stabilities Facing
We will use this and uses Automated testing tools.
methodology when
requirements. there is a continuous
modification in the user
2.8.4 Agile Testing Model
The XP will help us
deliver a quality Create tho test code
requirements that are product, which meets
made clear throughout the customer's
the process of development
2.8.3 Four Quadrants and testing.
The following are
ofAgile Testing Write or modify the function
code
the four
It enlists the different quadrants of Agile Testing, as introduced
types of software by Brian Marick.
development process. testing that fit Create additional tosts
the various stages
Brian Marick discovered of the
a way to categorize
two dimensions: the different types
1. Tests
by using following Test the funcional code
that support programming
2. Tests or the team and tests
that are technology that critique the product.
facing and tests Refactor the code
that are business facing.
Fig. 2.7: Agile Testing Model
 ST&QA - MCA (Mgt): Sem Il 2.20 Software Testing
Fundamen
1. Create the Test Code: The developer creates
the test code using an automated -
framework even beforethe actual code is written and tary ST& OA MCA (Mgt.) :Sem lI 2.21 Software Testing Fundamentals
these test codes
to thetest team. The functionality of the software is developed based on aresubmitt
thetest code. 3. System Testing: It evaluates both functional
and non-functional needs for the
2. Write or Modify the Function Code:
The functional code is written testing. Testing the fully integrated application is also called as an
that have cleared the test case. The actual for the test end to end
functional code is not written code; scenario testing.
case requirements are met
with. Once the functional untilthe
code is written it 4. Acceptance Testing: It checks the requirements of a specification or
checked using the test case. The
functional code module is completed is agaia contract are
met as per its delivery. Types of Acceptance
clears the test cases. only after Testing are Alpha, Beta
& Gamma
Testing.
3. Create Additional Tests: In i
this step the tester tests the module
input. The tester develops various for various ttmos 2.9.1 Unit (Component) Testing
test conditions depending on The primary goal of unit testing is to
module. the complexity of th take the smallest piece (unit) of testable
software in the application, isolate it from the
4. Test Functional Code:
The remainder of the code, and determine
functional code is tested based on whether it behaves exactly as you expect.
in step 3 and step 1. The steps 2 to are the test case develnne) It focuses on
4 repeated until the code clears the smallest testable unit of software design.
S. Refactor
the Code: In this step, some all the test Caser component or mnodule. Hence Synonyms This unit can be a software
easy to maintain changes to the code are for unit testing are: Component testing,
and extensible. This enables made to make the coda Module testing.
particular module without the developer to make changes to a
Unit testing is white-box oriented. It is
affecting the entire application. used to verify control flow and data flow
added to the existing application Any new can he of
any duplicate code or easily, without major modifjcations. feature the code.
unused code and reduces It also removes It requires knowledge of the code
Thus, in Agile method the code complexity hence is performned by the developers
testers have a strong subjecting the code to more extensive before
role to play in development code coverage testing. This can
software. adding dummy code. happen by
of efficient
For example, for modules with
2.9 LEVELS OF TESTING complex logic or conditions, the developer can
"debug version" of the product by build a
There are many putting intermediate print statements
different making sure that the program is passing through the right loops and
performance for software testing levels which help to check behavior right number of iterms. It is impc and iterations the
testing. These testing and stant to remove the intermediate
missing areas and reconciliation levels are designed after the defects are fixed. print statements
between the development to recognize
In SDLC models life cycle states. Unit testing on the part of the component
there are characterized will not really help in deciding
analysis, design, coding or phases such as requirement working of the same component the final
execution, gathering, in the entire system.
through the process testing,
of software testing levels. and deployment. AIl these phases go Unit testing is normally performed
by software developers themselves or
Each of these testing Unit Tests Considerations: their peers.
levels a
the software development has specific purpose. These testing level
lifecycle. provide value to
Levels of Testing:
There are mainly Module to be Interface
four Levels Testing
1. Unit Testing: It checks of in software testing: tested Local data structures

working properly. whether the individual Boundary Conditions

i.e. testing each modules of the source
the developer in and every code are Independent Paths
the developer's environment.unit of the application separately Error handling Paths
2. Integration by
Testing: It checks
is subdivided into the data flow from one
the Top-Down Approach, module to other
Approach (Combination Bottom-Up Approach, modules. It
of Top-Down and Bottom-Up). and Sandwich
Test Cases
Fig. 2.8: Unit Tests
 ST & OA - MCA (Mgt.) : Sem IlIl 2.22 SoftwareTesting
Fundam
damenta
Tests carried as part of unit tests are as shown in Fig. 2.8.
o
Module ST& QÂ - MCA (Mgt.) : Sem 2.23 Softwaro Testing Fundamentals
Interface: Tests data flow across the module interface
information properly flows in and out of the program. to ensure
th: Stubs simulates called unit.. It replaces missing modules
Local data structures: Examines local
that are called by the
data structures i.e. data stored temporarily modulc to be tested. It uses the subordinate mnodule's interface,
to ensure does minimal
data maintains integrity during all steps an data manipulation, and returns control to the module undergoing
o Boundary in algorithm's execution testing.
conditions: Are tested to ensure Let us consider the example
of DB queries, which is having different modules for
boundaries established to limit. This is an that the module operates pronerl. implementing select query, update query, insert query, etc. as
important task, as software often f shown in Fig. 2.10.
at its boundaries. For e.g. when
the maximum or minimum allowable valiue
encountered, or when the nth element n : Main
of dimensional array is being processoa Program
dbQuery.java Module for Module for
Independent Paths: All Independent SelectQuery
Paths are examined to ensure displayResult
statements in a module have been that all
executed at least once.
Unit Tests Procedures:
Unit Testing is normally considered as
an add-on to the
level code has been developed coding step. After sourre
unit test case design begins. As
tested is not a standalone programn the component to ba Module for
and is isolated from the rest UpdateOuery
and Stub software must be developed of the system Drivere
illustrated in Fig. 2.9. for cach unit test. This environment it
Fig. 2.10: Database queries
having Select, Update and Display Module
Above figure illustrates
that SelectQuery(query) calls displayResult(array)
i.e.
Funct ion SelectQuery (query)
Driver Interface
Localdata structures
Boundary Conditions
Independent Paths displayResult (array);
Module to bo Error handling Paths
Module displayResult() can be stubbed as
tested follows:
Function displayResult{array)

return tre;

Stub Stub Unit Testing Tools:

Test Cases Unit Testing may be manual but there are
several Unit Testing Frameworks/Tools
used to create accurate unit tests. We will see some
Results of them:
1. JUnit: JUnit is an open-source
unit testing framework designed for Java
Programming Language. It is supportive for the
Fig, 2.9: Unit Test test-driven environment. Test
Module to be tested can Environment data is first tested and then inserted in the piece
be an operation, a class, a for test method identification, an assertion
of code. It provides annotation
Driver simulates calling software package, or a for testing expected results and test
unit. It is nothing more subsystem. runners. It is simplest tool and helps to
accepts test case than a "main program" write code easily and faster.
data, passes it to the that 2. NUnit: NUnit is a unit testing framework based on.NET
results. module to be tested plat form. It is a free tool
and prints relevant
allows to write test scripts manually but not automatically.
It works in the same
way as JUnit works for Java. It supports
data-driven tests that can run in parallel.
 ST & QA
-MCA(Mgt.) : Sem Il 2.24 Software Testing
Fundament
3.PHPUnit: PHPUnit is a unit testing tool
for PHP programmer. It takes
portions of code which is called units and tests each of ST& QA - MCA (Mgt.) : Sem Il 2.25 Sottware Testing Fundamentals
them separately. ThissTa.
also allows developers to use pre-define assertion to
methods to assert that Integration testing is done by developers / quality assurance teams. These members
behave in a certain manner. asysten
test both normal processing and exceptions. Defects can be:
4. JMOckit: JMockit
is an open-source tool for Unit Testing with Interface incompatibility
tools and API. Developers can use the collection
or JUnit. It is considered as an
these tools and API to write test using ci Incorrect parameter values
TestNG
alternative to the conventional use of Resource problems
object. This tool provides 3 types the
of code coverage such as Line Coverage. D, Run-time exceptions
Coverage, and Data Coverage.
5. EMMA: It is an open-source Navigation problems
toolkit for analyzing and reporting Data flow errors
Java language. EMMA support coverage code written in .
types like method, line, basic
Java-based tool. block, It ie. Types of Integration Testing:
Advantages of Unit Testing: Fig. 2.11 illustrates various types
of Integration Testing.
1. Much easier to make sure
that small pieces of a system are Integration testing
debug the entire thing at once. working right than ta
2. Unit testing is also good
for catching "rare" bugs
sets of inputs are fed to a module. that only occur when specifir
3. In order to make Non - Incremental
unit testing possible, codes need to Incremental
are easier to reuse. be modular. This means codes
4. The cost of fixing a
defect detected
that of defects detected at higher during unit testing is lesser in comparison to Top-down Bottom-up Sandwich
5. Debugging is easy.
levels. ntegration integration integration
When atest fails, only
Disadvantages of Unit Testing: the latest changesneed to be debugged.
Fig. 2.11: Types of Integration
1. Unit testing cannot 1. Big Bang Approach
Testing
catch each and every an (Non-incremental):
2. It cannot evaluate every bug in sofrware application.
execution path. In this type all components are
3. There is a limit to combined at once to form a program.
the number of scenarios all components in isolation, That means test
to verify a source and test data that a then mix themn all together. It works as
code. After having developer can use Fig. 2.12. shown in the
but to stop unit testing and merge exhausted all the options,
the code segment with
there is no choice
2.9.2 Integration Testing other units. Unit Test
The integration testing GUI
emphases on finding
combining various components defects which mainy
arise because of
is to take unit tested componentsfor testing. The main objective Unit Test
and build a program of integration testing Login
Integration testing a structure. Integration
more units is logical extension
that have already been of unit testing. In its simplest Tost
Shopping9
interface between tested are combined form, two or Unit Test
them is tested in into a component Cart Cart
components operate order to assure and the
properly when combined that the software
Integration testing together. units/
works to expose Unit Test
between the integrated components defects or errors in the interfaces Billing
(modules). and interaction
Fig. 2.12: Big Bang Approach
 ST & OA - MCA (Mgt.) :Sem ll 2.26 Software Testing
Fundamert,

This approach is great with smaller systems, but it can end up ST& QA - MCA (Mgt.) : Sem ll
taking a lot of 2.27 Software Testing Fundamentals
larger, more complex systems. timef;
However, this approach is not recommended as both On the other hand, Breadth-first integration incorporates all components directly
drivers and stubss are
Biggest disadvantage of this approach is requirei subordinate at each level. For example, in example 2, components M1, M2, M3 and M4
that Debuggingis not easy, as it would be integrated first. The next control level (M5, M6) would be integrated, and so
to trace the cause of any failure since all
components are merged all is diffic
at once, whic. on.
results in complexity of correction.
A second disadvantage Example 2: Based on Breadth-first integration:
is thatyou cannot start integration
modules have been successfully testing until alh.
unit tested. Some modules that work together m A
completed early, but they cannot
be integration tested until all
application are completed. the modules i Test
Test A
A, B, C,D
2. Top-down Integration:
It is an incremental approach
to construction of a program
Modules/Components are structure. G
integrated by moving downward Test Test
hierarchy, beginning with through contst A, B, C,
the main control module (main D, E, F D, E, F, G
Modules/Components program).
subordinate to the main Fig. 2.14: Top-down integration (Breadth-first)
either control modle are integrated
i: Procedure of Top-down
Depth-first Manner Integration:
1. The main control module is used as a test
Breadth-first Manner driver, and stubs are substituted for all
components directly subordinate to
Example 1: Based on the main control module.
Depth-first integration: 2. Depending on the integration
approach selected, subordinate stubs are replaced
one at a time with actual components.
M1 Main Module 3. Tests are conducted as each component
is integrated.
4. On completion
of each set of tests, another stub is replaced
EK component. with a real
M2 M3 M4 Subordinate Modules to M1 5. Re-testing may be conducted to ensure new errors
that have not been introduced.
6. The process continues
from step 2 until the entire program structure
MS M6 Subordinate Modules Advantages: is built.
M7 to
upper level
1. Any design faults or major questions
about functional feasibility can be
addressed at the beginning of testing instead of the end.
M8
Disadvantages:
Fig.2.13:Top-down Integration 1. Writing stubs can be difficult- Stubs must allow
(Depth-first) all possible conditions to be
In Fig. 2.13, Depth-first tested.
integration would integrate 2. Large number of stubs may be
of the structure. For example, all components on required, especially if the lowest level of the system
selecting the lert hand control path
would be integrated path, components M1, contains many methods.
first. Next M8 or M6 M2, MS
right hand control paths are wold be integrated. Then 3. Stubs replace lower-level
modules at the beginning of top-down process; so no
built. the central and
With Depth First
Integration, a complete significant data can flow upward.
demonstrated. function of the software 4. The stubs themselves can have
is implernented faultssince they are written by people.
and In this situation, the tester is left with 3 choices:
0) Delay many tests until stubs are replaced with
actual modules.
 ST & OA - MCA (Mgt.)
:Sem il
2.28 Software
(ii) Develop TestingFundamer.
stubs that perform limited
(iii) Integrate functions that simulate
the software from the actual modt. ST& QA MCA (Mgt.): Sem I|
Integration) the bottom of the hierarchy 2.29 Software Testing Fundamentals
upwards (Bottom... 4.
3. Bottom-up Sandwich Integration:
Integration: In sandwich integration
Bottom-up integration testing, both top-down and
simultaneously and testing is built up bottom-up is
is just the opposite
from both sides. This approach is also started
components
for a new product
starting from the
bottom. That is,
of top-down integration,
development become where
available in reverse
."Bi-directional integration
The system is viewed as
testing".
having three layers:
called as

components this approach begins ord..

at the lowest levels construction and A target layer
1
in the middle,
As the components in the program structure. testing wi%
2. A layer above
are integrated the target,
components from the bottom, 3. A layer below
subordinate to a processing required the target.
eliminated. given level is always for the
available and Testing converges at the target layer.
Procedure of Bottom-up the need for stubsie! Top-down approach is used
Integration: for the uppers layers.
1. Low-level Bottom-up approach is used
components are for the subordinate layers.
the test case input tested individually, Example 4: Based on Sandwich
and output. by writing a driver to coordinate Integration:
2. Drivers are
removed
program structure. and tested components
are Test E
integrated moving
3. Tests are upward in the
conducted as each Test B, E,F
4. This is done component is integrated.
repeatedly until Test
Example 3: Based on all entire program Test F A, B,C,
Bottom-up structure is built. D, E, F, G
Integration: Test A
A
Test E
Test G Test D, G
Test B, E, F
Fig, 2.16: Sandwich
Test F
Integration
Test Advantages:
Test C F,G 1 Top and Bottom Layer Tests can
be done in parallel.
2. Allows integration to begin
early in the testing phase.
Test G Disadvantages:
Test D, G 1 It does not test the individual
subsystems thoroughly before
integration.
Disadvantages:
Fig. 2.15: Bottom-up
Integration 2.9.3 System Testing
Once the entire system has
1. The program as an been built then it has to be
entity does not exist Specification" to check if it delivers tested against the "System
2. Badfor functionally until the last module is addea the features required.
decomposed systems as it System testing verifies the
last. tests the most entire product, after integrating
important hardware components and validates all software and
3. Interface errors are mnodule it according to the original project
discovered late. A testing group performs system requirements.
testing before the product is made available
customer. to the
It also verifies the software operation
from the perspective of the end user
different configurations or setup. with
 ST& OA - MCA (Mgt.) : Sem
l 2.30 Software Testing
Fundamentah
It can begin whenever the product has sufficient functionality
to execute some ST & QA - MCA (Mgt.) : Sem II
tests or after unit and integration testing are complete. ofthe 2.31 Software Testing Fundamentals
System testing should be carried out by a QA team testers. b. Non-functional System
of software Testing:
System testing is a series of di fferent tests Non-functional testing involves testing the
whose primary purpose is to av
product's quality factors such as
the computer-based system. System testing comprises of main fullv reliability, scalability, etc. It is conducted for
illustrated in Fig. 2.17. two types non-functional requirements.
as Non-functional requirements are global
constraints on a softvare system.
Non-functional testing requires the expected
results to be documented in qualitative
System Testing and quantifiable terms. It requires a large amount
different for different configurations of resources and the results are
and resources.
Types of Non-functional system
testing:
Functional System Testing 1. Usability
Non-functlonal Systom Testing testing
2. Recovery testing
3. Installation testing
Requirements based - Usablity
testing testing 4. Security testinE
Specification based Recovery testing 5. Performance
Installation testing testing
testing 6. Configuration testing
Black box testing Security testing
Security testing Performance testing 2.9.4 User Acceptance Testing (UAT)
Stress testing
Acceptance Testing is often
Configuration testing the final step before rolling out
- Reliability performed to determine whether the application. It is
testing the system meets user requirements or not.
- Interoperability Usually the end users, who
will be using the applications, test
'accepting' it. This type of the application before
Fig. 2.17: Types testing gives the end users the
of System
Testing application being delivered to confidence that the
a. Functional them meets their requirements.
System Testing: end-user(s) performs an Acceptance Test. In other words, the
Functional testing involves Acceptance tests can range
testing a product's functionality from an informal "test drive" to a
conducted for functional and features. It is systematically executed series of tests. planned and
requirements.
Functional requirements With respect to the website or application
affect the functionality produced, the clients or end users "review"
Functional requirements of the system. and "test" the application for any
describe at the system nonconformity to the requirements
In other words, it is should do. or any updates which are not specifications
the process of validating an application or included in original specifications.
each feature complies Web site to verify that The customer may write the acceptance
with its specifications test criteria and request the
functions. This involves a and correctly performs execute these,or the organization may organization to
series of tests, which tests all its required produce the acceptance testing criteria,
range of normal
and erroneous input data. This canthe functionality by using a wide are to be approved by
the customer.
which
user interface, involve testing of
APls,
on an automated or database management, security, etc.
thenrodcts2.9.4.1| Acceptance
manual basis using black box Testing can be performed Criteria
methodologies. There are three Acceptance criteria:
Types of Functional System Testing:
1. Requirements
1. Acceptance
Criteria - Product acceptance:
based testing
2. Specification based
During the requirements phase, each requirenment
testing is associated with acceptance
criteria. Whenever there are changes to
3. Security testing requirements, the acceptance criteria are
accordingly modified and maintained.
While accepting the product,
execute all existing test cases to end users
determine whether they meet the requirements.
 ST & QA - MCA (Mgt.) :
Sem ll
2.32 Software Testing
Fundamerta
2. Acceptance -
Criteria Procedure acceptance:
Acceptance ST & QA - MCA (Mg.) : Sem l1
criteria can be defined based on 2.33 Software Testing Fundamentals
Some of the examples the procedures followed for
of acceptance criteria can be: delvery
User manuals,
administration and troubleshooting
210 TEST TYPES
the release. documentation should There are different kinds of testing that focus on finding
bepart different kinds of Software
errors as shown in Fig. 2.18.
Along with executable
file(s), the source code
CD. of the product should be delivered Testing
i.
A minimum
of 10 to 15 employees should be trained on
deploynent. the product usage prior . Static Dynamic
3. Acceptance
Criteria-Service Level agreements:
Service level agreements can
Agreement is a document orbecome a
part of acceptance criteria.
A Service Level Reviews Functional Structural
contract signed by two
organization and the customer. parties: the produe Inspections (Functionality of (Logic of the Program)
Example contract items Walkthrough the program)
All major defects related to defects can be:
that come up during the first
be fixed free cost; six months of deployment
of need to
Black Box Testing Whitc Box Testing
All major defects are to
be fixed within 48 hours
2.9.4.2 Types ofAcceptance Testing
of reporting.
Fig. 2.18: Types of testing
There are two kinds 2:10.1 Functional Testing (Black-box)
of acceptance testing:
1, Alpha test: Black Box testing, also known as Behavioral
Testing. It is a
A customer conducts in which the internal structure/design/implementation software testing method
it at the developer'ssite. not knOwn to the tester. of the item being tested is
It is the first test of a newly Black Box (or functional) testing
developed hardware or checks the functional requirements
setting in the presence software in a laboratory and examines
of a developer. Errors and usage the input and output data of these requirements.
recorded. problems are When Black Box testing is performed, only
the sets of legal' input and corresponding
"Alpha tests are conducted a outputs should be known to the tester
in 'controlled environment" and not the internal logic of the program to
When the first round produce that output. Hence, to determine
of bugs has been fixed, the product goes the functionality, the outputs produced for
2. Beta test: into beta test. the given sets of input are observed.
In Black Box testing, the tester is concentrating on
It is conducted at one or more what the software does, not how it
customer's site by the end-user does.
Generally the developer is not present. of software. Purpose of Black Box Testing:
It is a "live" application
in an environment that cannot of the software 1. To test the functionality of software.
be controlled by the developer.
Customer records all the 2. Concerned with testing the specifications and does not ensure
problems (real or imagined) that all the
during beta testing and reports that are encountered components of software that are implemented are tested.
these to the developer at regular
As a result of the problems intervals. 3. Addresses validity, behavior and performance of software.
reported during beta tests,
make modifications and then software engineers Black Box testing techniques attempts to find errors
of the following categories:
release the software product to
customer base. the entire 1. Incorrect or missing functions.
2. Interface errors.
 ST &QA - MCA
(Mgt.) : Sem Ill
2.34 Softwaro Testing
3 Errors in data structures Fundamk
4. Behavior or
or external database access.
performance errors. ST &OA
-
MCA (Mgt.)
:
Som lll
5. Initialization 2.35 Software Testing Fundamentals
Example:
and termination errors.
Technigues used in Black Box Testing:
A tester without Following are some techniques that can be used for designing Black Box tests:
knowledge of
by using a browser; theinternal structures a 1. Equivalence Partitioning: It is a software test
design technique that involves
providing inputs (clicks, of website, tests the weh
against the expected keystrokes) dividing input values into valid and invalid partitions and selecting
outcome. and verifying the outn. representative values from each partition as test data.
2. Boundary Value Analysis (BVA): It is a software test design
technique that
involves determination of boundaries for input values
Input ,Executable are at the boundaries and just inside/ and selecting values that
Program Output outside of the boundaries as test data.
3. Cause Effect Graphing: It is a software test
design technique that involves
Black Box Test identifying the cases (input conditions) and effects
(output conditions),
producing a Cause Effect Graph, and generating test cases
accordingly.
Advantages Black Box Testing:
Fig. 2.19: Black Box 1. In Black Box testing,
Testing the code access is not required.
Fig. 2.19 shows 2. This testing is well
Black Box testing. A suited and efficient for large code segments.
and output of the software black-box test takes into account 3. In this technique large numnbers
without regard to the only the ino of moderately skilled testers can test the
Black Box test cases are internal code of the program. application without knowledge of
written implementation, programming language, or
black box test cases, we first and white box operating systems.
need requirement document, test cases later. In order to write 4. It clearly separates user's view
Black Box testing a design or project from the developer's view through visibly
specifications. is testing strategy which is based plan. roles. defined
solely on the requirements Disadvantages
and Black Box Testing:
This testing requires no 1. Inefficient
implementation knowledge of testing, due to the fact that the tester
of the software under test. the internal paths, structure, only has limited knowledge
or about an application.
In this testing, we 2. In this testing, the test cases are
check the overall functionality difficult to design.
of the application. 3. Black Box testing
has limited coverage, since only a selected
Inputs causing scenarios are number of test
actually performed.
Input test data anomaloUs behaviour 4. Black Box testing blind coverage,
since the tester cannot target specific
segments or error-prone areas. code
2.10.2 Non-functional testing (Testing
of software product
characteristics)
System In non-functional testing the quality
characteristics of the component or system is
tested. Non-functional refers to aspects
of the software that may not be related to a
specific function or user action such as scalability or
many people can log in at once? security. For example, How
Non-functional testing is also performed at all levels
Outputs which like functional testing.
Output test the presence reveal
defects
of Non-functional testing includes:
result
1. Compatibility Testing: Compatibility testing is basically
the testing of the
application or the product built with the computing environment. tests
It whether
Fig. 2.20: Process the application or the software product built is compatible
of Black Box Testing with the hardware,
operating system, database or other system software or not.
 Software Tosting Fundamentah Software Testing
Fundamentals
ST& QA- MCA (Mgt.) :Sem I 2.36
- (Mgt.) : Scm Il 2.37
fo ST& QA MCA
2. Documentation Testing: As per the IEEE Documentation describing plans
a system or component, Types include test
results of, the testing of
test ren
specification, test incident report, test log, test plan, test procedure, Qulput
Hence the testing of all the above mentioned documents is known Input

documentation testing.
3. Performance Testing: Performance testing is performed to determine how
..
some aspectof a system performs under a particular workload. Testing
Fig. 2.21: White Box
4. Internationalization Testing and Localization Testing: Internationalization is,
process of designing a software application so that it can be adapted to varioy; White Box testing is the detailed investigation
of internal logic and structure of the
languages and regions without any changes. Whereas Localization is a process ! code.
adapting internationalized software for a specific region or language by addir This Testing is done by developers
as they know the internals of the application.
to know the
local specific components and translating text. In order to perform White Box testing on an application, a tester needs
5. Usability Testing: In usability testing, basicaly the testers tests the ease with internal workings of the code. The tester needs to have a look inside the source code
which the user interfaces can be used, It tests that whether the application or the and find out which unit/chunk of the code is behaving inappropriately.
In White box, we do code reviews, view the architecture, and
remove bad code
product built is user-friendly or not.
6. Installation Testing: Installation Testing helps to verify the software applicatio, practices and component level testing.
is working correctly or not after installation. It helps to validate whether i.
it
Example of White Box testing and Black Box testing is shown in Fig. 2.22
performing well or not if any updates or modifications have been done.
Black Box
7. Security Testing: It is a process to determine that an information system protects
data and maintains functionality as intended. Accounting
Result
2.10.3 Structural Testing (White-box) Application
White Box testing isalso called Structural Testing and Glass Box Testing, White Box is
a testing technique that takes into account the internal mechanism of a system or Toster

component. White Box

White Box test cases cannot be started in the initial phase of the project because it
more TEST
needs architecture clarity which is not available at the start of the project. with
It is also known as structure-based testing technique because here the testers require TEST Webforms
Result
knowledge of howthe software is implemented, how it works. Database TEST
Sourco
For example, a structural technique may be concerned with exercising loops in the COde
Tester
software.
Purpose of White Box Testing:
1. To test the internal structure of software.
Fig. 2.22: White Box Testing and Black Box Testing
2. Test the software
but does not ensure the complete implementation of all the White Box methods can be used for test generation and test adequacy analysis.
specifications mentioned in user requirements. These test cases are written after black box test cases are written.
3. Addresses flow and control structure of a program. Techniques used in White Box Testing:
Example: A tester, usually a developer as weL, Studies the 1. Basis Path Testing: Basis path testing
on implementation code ofa enables to generate test cases such that
rtoin feld awebpage, determines alu legal (valid
and invalid) and illegal.inputs every path of the program has been exercised at
Rd srorifesthe outputs
against the expected outcomnes, which is also
least once. This technique is used
determined to specify the basic set of execution paths that are required
studying the implementation code.
by to execute all the
statements present in the
prograrm.
 ST & QA - MCA
(Mgt.) : Sem
Il 2.38
2. Path Testing: Software Testing
Fundamertay
A path through
minimum of one new the program, which
set specifies a new
possible paths of processing statements. condition o sT QA - MCA (Mgt.) : Sem I!
&

2.39 Software Testing Fundamentals

through the code are Path testing
is where
task. defined and covered. Confirmation
It is a time consumi 2.10.4:1 (Re-testing)
3. Data Flow
Testing (DFT): In Confirmation Testing or Retesting is done when we execute the test again to confirm
through each possible this approach, tester
tracks the that the defect has indeed been fixed.
through the code. DFT calculation,thus defining the set of specific variabl. When doing confirmation testing, it is important to ensure
sequences tends to reflect dependencies intermediate path, that the test is executed in
of data manipulation. In but is exactly the same way as it was the first time, using
is verified. This short, each data variable it mainly throusk the same inputs data and
approach tends to uncover is tracked and its tr:. environment.
initialize, or declared bugs like variables In retesting those test cases are included which were
4. Control Structure
but not used, and so on. used but nrs failed earlier.
Testing: Control structure Definition:
coverage area testing is used to
by testing various enhance the Retesting a previously tested program to ensure
structures and loops) control structures (which as a result of the changes made.
that faults have not been introduced
are derived to present in the program. include logica
determine whether the logical In condition testing, the test caset Important points about Re-testing:
are free from errors. conditions and decision statement: It is a planned testing with proper steps
Advantages of White of verification.
Box Testing: Retesting is done by replicating the same scenario
It helps in optimizing with same data in new build.
the code. In some cases, the entire module is reguired
2. As the tester to be re-tested to ensure the quality
has knowledge of the source the module. of
find which type of data can help
out code, it becomes very easy
and simple t: In retesting we ensure earlier
3. Due to in testing the application faults are really repaired. Retesting is testing
the tester's knowledge about effectively. particular bug after it has been fixed. of a
during test scenario writing. the code, maximum coverage
is attained 2.,10.4:2
4. In this testing, extra Regression Testing
lines of code can be removed Whenever software is corrected some aspect
defects. which can bring in hidden of softvware configuration is changed.
Regression Testing is the activity
5 White Box tests are easy that helps to determine whether the changed
to automate. component has introduced any error
Disadvantages of White Box in the unchanged components.
Testing: In other words, before a new version
1. It is difficult to
maintain White Box testing, as of a software product is released, the old test
cases are run against new version to make sure
code analyzers and debugging tools. it requires specialized tools like
the that all the old capabilities still
work.
2 Due to the fact that a skilled
tester is needed to perform In this testing, Re-running previously
Costs are increased. White Box testing, the conducted tests to ensure that unchanged
3. Sometimes, it is components function correctly.
impossible to look into every nook
errors that may create problems, as many and corner to find out hidden Regression testing is a style of testing
that focuses on retesting after changes are
paths will go untested. made. In traditional regression testing, we reuse
2.10:4 Testing related to changes - Confirmation the same tests. In risk-oriented
regression testing, we test the same areas as before,
(Re-testing) and but we use different (complex)
Regression Testing tests.
Change-related testing is designed to verify In Integration testing, adding a new module or
that a change to the system has changing an existing module impacts
fixed correctly and does not have any adverse effects on been
the system as:
the system as a consequence.
There are two subtypes of Change-related testing: Confirmation New data flow paths are established.
testing (Re-testing)
and Regression testing. New I/O may occur.
New control logic is invoked.
 ST &
QA -ACA
(Mgt.) : Sem
I
These changes 2.40 Software Testing
may cause Fundamerta
In context of problems with functions
integration test strategy, that previously worked
"Re-execution Regression testing perfectly ST& QA - MCA (Mgt.) : Sem | 2.41 Software Testing Fundarmentals
of the subset of is:
changes have tests that have
not propagated already been conducted When to doRegression Testing?
Regression Approaches: unintended side
effects". toensure Whenever changes happen to the software, regression testing
h is done to ensure that
It may be conducted these do not affect adversely the existing functionality.
by: It is necessary to perform
Manual Testing: By regression testing when -
re-executinga subset of 1. A reasonable amount
of initial testing is already carried out.
Automated Capture/Playback alltest cases.
2. A good number of defects have been
version of a system Tools : Capture fixed.
the operation 3. Defect fixes
under test. and then of an existi. that can produce side effects are take care of.
automatically on later the operation can be a
When developer fixes a defect, the
versions of the system played bai defect is sent back to the test engineer for
reported. and any differences verification. The test engineer needs to take
in behavior ax. the appropriate action of closing the
Regression Test suite: defect if it is fixed or reopening it if it has not been fixed
properly. In this process,
Regression test suite regression testing needs to be done to avoid
bad side effects. To ensure
(subset of tests to be executed) are
cases: contains following
no side effects, some more
test cases are selected and defect fixes are that there
classes of te regression test-cycle. verified in the
Representative sample tests
of Regression testing can be performed
Additional tests that focus on that exercises all software functions. the Fig. 2.23 summarizes the concept
irrespective of which test phase the product
is in
functions that are affected of regression testing.
Tests that focus on components by change.
Types of Regression Testing: that have been changed. Types
- REGRESSION TESTING
Regular regression
When test teams or customers - Final regression
begin using a product, they
defects are examined by a report defects. Thece
developer who makes individual
developers then do appropriate defect fixes., Tha
unit testing and check the defect
Configuration Management system. fixes into a
The source code for the complete What ?
compiled and these defect product is then -Select ro Why ?
fixes along with the existing lesting to When ?
build. Thus, a build becomes "an features get merged into the ensure defect fixes Defect fixes may When set of defect
aggregation of all the defect fixes cause existing fixes arrive after
are present in the product". and features that work.
- No functionality to fail formal testing for
side effects.
There are two types of regression testing: completed areas.
1. Regular regression
testing: It 1s one between test Fig. 2.23: Regression Testing
defoct fixes that are done cycles to ensure that the
and the functionality that were Difference between Regression Testing
working with the earlier and Retesting:
test cycles continue to work. Regression testing differs from retesting.
2.
Retesting means only the certain part
Final regression testing: is done to validate
It
(module) of an application is tested again
the final build before without considering how it will affect the
Configuration Management engineer delivers release. The other part in the whole application. Whereas, in
the final build Regression testing the entire
exactly as it would go to the customer. and other contents application is tested after a change in a module or
part of the application, to ensure
The final regression test cycle is conducted that the code change does not affect existing functionality
for a specific period of of the application.
which is mutually agreed between the development duration, How to do Regression Testing ?
and testingtearns. There are several methodologies for regression testing
The final regression is more critical than any that are used by different
same other type of
only testing that ensures the ebuild testing, as organizations. Steps involved are:
of the
product that reaches this is the
the customer. 1. Perform an initial Smoke test.
2. Understand the criteria for selecting the test cases.
 ST & QA - MCA (Mgt.) :
Sem lil 2.42 Softwaro
Testlng Fundam
3. Classify the test case into
different priorities.
4. Select test cases. ST& QA - MCA (Mgt.): Sem ll 2.43 Software Testing Fundamentals
S. Resetting the test cases for execution.
6. Conclude Priority-0: These test cases check basic functionality
the results of regression cycle. and are run for accepting
the build for further testing. They are also run
1, Perform an
initial Smoke test: when a product goes through a
major change.
The term smoke
testing originated in These test cases deliver very high project
hardware or a hardware the hardware industry. After value to both development team and to
component (For example, a piece the customers.
repaired, the equipment was transformer) was
component passed
the test.
simply powered up. I"
there was no smoke
changed , Priority-1: These test cases use the basic
These test cascs deliver high project
and normal setup.
In software, the term value to both development tearm and to
Smoke testing describes customers. the
to identify and process
fix defects in software before the of validating changed ea. Priority-2: These test cases deliver
product. It is designed to the changes are mapped moderate project value. They are executed as a
confirm that changes in into the sn. part of the testing cycle and are selected
A smoke test the code, functions as expected for regression testing on a need basis.
is reduced version Classification of above test case
2. Understand of regression testing. priorities is illustrated in Fig. 2.24.
the criteria for selecting
There are two approaches the test cases: Prionity-0,
10%
choose to have a constant for selecting the test cases. First, an
set of regression tests organization caa
change. But this approach that are run for every build ts
is not always feasible
In order to cover all because: Priornty-2,
Prionity-1,
fixes, the "constant 25%
which are not required, set of tests" will cover 65%
may be run every all features and teste
A given set time.
of defect fixes or changes may
not be ready test cases introduce problems
in the constant set. for which there nay Fig. 2.24: Classification
A second approach of Test Case Priority
is to select the test cases 4. Select Test Cases:
of test cases requires knowledge of:
dynamically for each
build. The sclection Once the test cases are classified
The defect fixes into different priorities, the test cases can
and changes made in selected. The methodology discussed be
The ways to test the current build. below
the current changes. impact of defect fixes after the test cases are takes into account the criticality and
The impact that classified into several priorities.
the current changes may Case 1: If the criticality and
impact of the defect fixes are low,
The ways of testing have on other parts then the test
the other impacted parts. of the system. engineer selccts a few test cases from test case
Some of the criteria stores all the test cases). These database (TCDB, a repository that
to select test cases are test cases can fall under any
(i) Include as follows: priority (0, 1, or 2).
test cases that Case 2: If the criticality and impact
(ii) Include test cases have produced the of the defect fixes are medium, then
maximum defects engineer selects all Priority-0 and Priority-1 the test
that test the basic in the past. test cases. If defect fixes need
product, which are functionality or additional test cases, then Priority-2 test cases are
mandatory requirements the core features the also selected for regression
(iii) Include test cases of the customer. of testing.
that test the end-to-end
(iv) Include test cases behavior of the Case 3: If the criticality and impact
to test the positive application. of the defect fixes are high, then the test
3. Classify the test case test conditions. engineer selects all Priority-0, Priority-1
into different priorities: and a carefully selected subset of
It is important to Priority-2 test cases.
know the relative
execution. Test cases can priority of test cases The above methodology requires analysis
be classified into for a successful of criticality and the impact of defect fixes.
three categories: test This can be time consuming. Alternative
methodologies can be:
Regress all: All priority 0, 1, and 2 test cases are rerun.
This means all the test
cases in the regression test bed /
test-suite are eXecuted.
 ST & QA - MCA (Mgt.) :
Sem l! 2.44 Software Testing
FundamerAun
Priority based regression: All priority 1, test cases
0, 2
are run in order, ST& QA - MCA (Mgt.) : Sem !
the availability of time. basedc 2.45 Sottware Testing Fundamentals
Random regression: Randomn test cases are Above discussed conclusions are summarized
selected and executed in Table 2.2..
regression methodology.
Table 2.2: The results of a Regression Test Cycle
Context based dynamic regression: A
few priority-0 test cases are selected
based on the context and outcome: Previous
continuing the regression testing.
additional related test Cases are selected . result
Current result Conclusion Remarks
5. Resetting
the test cases for execution: PASS FAIL FAIL Need to improve the
After selecting the test cases, the next step
is to prepare the test cases regression process and code
Ina large product release involving several for execution
rounds of testing, it is very important ,. reviews.
record what test cases were executed FAIL PASS
information. This is called test case in which cycle, their results PASS This is the expected result of
and relat.i
result history. a good regression.
A method or procedure
cases, which are that uses test case result history to FAIL FAIL
selected for regression testing, indicate some of the ter FAIL Need to analyze why defect
a test case is nothing is called a reset procedure. Resettin: fixes are not working.
but setting a flag called not run or
DB. execute again in the test cate FAIL PASS (with a PASS (if satisfied Workarounds also need a
6. Conclude work-around) with workaround)
the results of Regression Cycle: good review as they can also
Since regression uses test cases create side-effects.
that have already been executed more PASS
expected that 100% of those test cases pass than once, it it PASS PASS There are no side-effects due
done right. On the other using the same build,
hand, where the pass percentage if defect fixes are to defect fixes.
can compare current is not 100, the test manager
results with
whether regression was successful orthe previous results of the test case to conclude 2:11; NON-FUNCTIONAL TESTING TYPES
not.
If the result of a particular test case was a Non-functional testing is defined as a
FAIL PASS using the
previous type of software testing
in the current build, then builds and a functional features (performance, to check non
regression has FAILED. A new usability, reliability, etc.) of a software
and the testing must start build is required application.
from scratch after
If the result of a particular test case was resetting the test cases. Following are the most common types
a FAIL using
PASS in the current the previous builds and a of Non Functional Testing.
build, then regression 2.11:1 Performance (Load & Stress)
that the defect fixes worked. has PASSED. Here it is
safe to assume
If the result of a particular test case was Performance Testing:
FAIL in the current a FAIL using Performance testing is designed to test
build and if there are no the previous builds and a
the run-tim performance of the system.
FAILED. This means defect fixes, then regression Main aim of performance testing is not to
such test cases should not has find bugs, but to eliminate bottlenecks
If the result of a particular be selected for regression. establish a baseline for future regression and
test case was a FAIL testing.
tworks with a documented using the previous
WoRKAROUND builds but Performance testing is used to uncover
TIOrkaround, you are performance problems that can result
then it should be considered asand if satisfied with the lack of server-side resources, inappropriate from
a PASS network bandwidth, inadequate database
regression test cycle. for both the system and capabilities, faulty or weak operating system
capabilities, poorly designed Web App
If you are not satisfied with the WORKAROUND, functionality,and other hardware or software
then it should issues that can lead to degraded client
a
fail for system test but may be considered be considered as a server performance.
as a pass a
for regressiontest cycle.
 ST & QA - MCA
(agt.) : Sem
il 2.46 Software Testing
The goal of performance Fundamert
1.
testing is twofold:
To understand
how the system
of transactions, or overall responds to loading ST & QA - MCA (gt.): Sem Ill
(i.e. number users. 2.47 Software Testing Fundamentals
2. To collect data volume). of n..
metrics (factors) In a typical clicnt-server environment,
performance. that will lead to design the modifications throughput represents the number of
transactions that can be handled by the server
2.11.1,1 Major toimp:, between the request and response.
and response time represents the delay
factors of Performance
Several factors
that govern performance Testing 3. Latency:
1. Throughput: testing are: In the networking scenario,
the network or other products, which are
network resources, can also cause sharing the
The capability the delays. Hence, it is important to
of the system or the the delay caused by the product and understand
determined by a product in handling the delay caused by the environment.
factor throughput. multiple transactione : Latency is a delay caused by the
application,
transactions processed It represents the calculates that separately. operating system, and the environment
by the product number of reques: .
in spccified time duration.
The throughput Let us consider an
(that is, the number cxample where latency can be
calculated for the product (database
time) varies according of transactions serviced server, web server,
etc.) and for the network
to by the product per Utsi
example of the throughputthe load the product is subjected to. available for the product. In that represents the infrastructure
such a scenario, if the network
Fig.
product can be increa'sed of a system at various load conditions. 2.25 shows ; the product latency and if that is latency is more relative to
number ofconcurrent by increasing the
number of users or
The load to th improve the network infrastructure. affecting the response time, then we need to
operations of the product. by increasing th In other case where metwork latency is more or
cannot be improved,
then we need to improve
approaches of caching and product by using intelligent
sending multiple requests
Throughput responses as a bunch. in one packet and receiving
4. Tuning:
Tuning is a procedure by
which the
different va' 1es to the parameters product performance is enhanced by sctting
Saturation point of the product, operating system,
components. and other
5. Benchmarking:
It is related to per formance
of competitive products.
User load should match the performance Performance of a product
Fig. 2.25: compare the of competitive products. Hence
Throughput of a system throughput and response time it is very important to
In the above example, of the product with those of
it can be noticed competitive products. This type the
as the user that initially the throughput of performance testing is called as
load increases. keeps 6. Capacity Planning: benchmarking.
that the product is capable This is the ideal situation for any product increasing
use the product. of delivering more when and indicates One of the most important
there are more users factors that affect performance
In the second part trying to of resources. A right kind of testing is the availability
comes down. of the graph, it can be noticed configuration is needed to derive
This is the period that the throughput performance testing. the best results from
response and the system when users of the system
starts taking more time to notice a lack The procedure to find out
The "optimum throughput" complete
of satisfactory what resources and configurations are
needed is called
is represented
by the saturation business transactions. capacity planning.
the maximum throughput for the product. point and it represents The purpose of capacity planning
is to help the customer
2. Response Time: and software resources prior to plan for the set of hardware
installation or upgrade of the product.
Response time is anotherimportant activity To summarize, performance
asthe delay between
of performance
f testing is done to ensure that a product:
testing. It can
the point of request and thefirst response Processes the required number
be defined of transactions in any given interval
(throughput).
fromthe product. o Is available
and running under different load
conditions (availability).
Responds fast for different load conditions
(response time).
 ST& QA - MCA (Mgt.)
: Sem lIl
Is comparable to and
2.48 Softwarec Testing
Fundament
6
betterthan that of
(benchmarking). the competitors for different
paramele ST& QA - ACA (Mgt.) : Sem l!
2.11,1.2 Performance 2.49 Software Testing Fundamentals
Performance tests are
Testing Purposes Areas that may be subjected to the test -
include
designed to simulate Input transactions.
number of simultaneous real-world loading
users grows, or situations AAs Disk space.
increases, or the amount the number
Two different of data (downloaded or uploaded) of on-line transacts:y Number of concurrent connections.
performance tests are increases.
1, Load testing: conducted: 211:1.3 Tools for Perfo .4ce Testing
Real world
variety of combinations. loading is tested at a variety There are two types Jt tools
that can be used for performance testing -
of load levels and performance 's and Load tools. Functional
2. Stress testing:
Loading is increased
i.
to the breaking 1. Functional
capacity the WebApp point to determine performance tools help in
1. Load environment can handle. how mr transactions and obtaining performance recording and playing back the
Testing: numbers. This test involves very
machines. few
Load testing is a
part of the performance Examples:
system by constantly testing i.e. to check
increasing the load. the performance of WinRunner.
Load testing is
sometimes called
t
Examples of volume volume testing, or QA partner.
longevity/endurance
testing: testing. Silktest.
Testing a word processor 2. Load testing
by editingavery large document. tool simulates the load condition
Testing a printer having tokeep that many users or for performance testing without
by sending it a very machines.
Testinga mail server large job.
with thousands of user's Examples:
A specific case mailboxes. Load Runner.
of volume testing is zero-volume
empty tasks. testing, where the system QA Load.
Examples of longevity/endurance is fed
silk Performer.
Testing a client-server testing:
server over an application by running 2:112 Usability
extended period time. the client in a loop Usability evaluates the system
of against the for human use or checks
Load testing operates if it is fit for use.
a
system can accept at predefined load level, usually the
Key Points are:
while still functioning highest load that the o Is the output correct
Load testing does properly. and meaningful and is it the same as
not aim to break per the business? which was expected as
2. Stress Testing: the system.
Are the errors diagnosed
Stress testing tries correctly?
to break Is the GUIcorrect and consistent
taking resources away from the system under test by increasing o
with the standard?
The main purpose
it. its resources or by Is the application easy
for use?
of stress testing is to make sure 2.11.3 Maintainability
gracefully (this quality is
known as recoverability). that the system fails and recovers Once the application/Product goes
Stress testing verifies live, then there are chances
even under full
that application software will up in the live environment or for an issue to come
l performance loads and under meet
its design requirements the customer may want an enhancement
all possible application which is already live. for the
For example, input conditions.
special tests may be designed In this case, maintenance testing team
when one or tWo that generate ten is available to test the above
is the average rate. Test cases interrupts per mentioned, Once the application goes live scenarios
that require maximum second, it still needs maintenance for
memory, maintenance testing team works. which the
etc.
 ST & QA - ACA (Mgt.) :

2.11.4 Portability
Sem l 2.50 Software
TestingFundame
6
Portability testing is done
different system or on a
to verify if in case a software/application ST&OA- MCA (gt.) : Sem l
2.51 Software Testing Fundamentals
different platformit should isinstalled
functionality should be a be able to run as cn. I18N testing can be divided in to two parts. to sure that application's GUI
ffected because of a change expected First, make
While testing,
it is also required to test
in the environment. iet, or functionality will not be broken with the translated text. Second, to make sure that
such as the hard disk space, the change with the hardwar translation of all the strings have happened properly.
This activity is called
ensure the application's Processor, and also with configurt Translation Verification Testing and is normally
correct behavior different operating systems conducted by person who knows the
2.11.5 Security and expected functionality are language very well.
intac
Localization (L10N):
Security testing is done
to ensure that the application It is a process of adapting internationalized
lead to any data loss or has no loopholes software for a specific region or language
threats. It is one whichcou, by adding local specific components
testing and if not performed of the important aspects and translating text.
properly, it can lead to of non-functin Localization testing follows after product
It includes testing security threats. localization and is performed to ensure that
authentication, authorization, the localized product is fully functional, linguistically
2.11.6 Localization & integrity, and availability. accurate, and no issues have
Internationalization been introduced during the localization process.
Internationalization (118N): A localization tester
must know the destination
language.
It is a process of designing Localization testing involves testing
a software application of the localized product in accordance with
languages and regions so that can
without any changes. it be adapted to vario: National language standards.
It checks the ability a Searching for un-translated text in the user
of software product to support interface.
Regardless of the any language Verifying consistency of formats (date formats,
platform, internationalization in the world. number formats, ctc.).
1. Data Component: has three main components: Verifying accordance with capitalization
Includes data analysis, rules and proper use of alphabets.
searching, and conversion. storage, retrieval, Verification of correct use of currencies,
display, sorting. etc.
2. Locale/Culture Focus on Translations that are cut
Component: Includes off or wrap to the next line.
well as calendars, measurement formatting of numbers, Reveal incorrecterror messages.
units, currency, graphics, dates and times, as
3. User Interface and audio. Reveal errors generated by installing
Component: Includes the localized software on a localized os.
localizable data aspects of design For example, Zip code field in Sign up
for localizers. This category and accessibility of form:
fragmentation, ambiguity, includes issues such 1) For globalized,
it should allow to enter alphanumeric
space limitations, hard-coding, text inputs.
information. fonts, image layering 2) For localized (country like INDIA),
and size it should allow only numbers in input field.
In I18N testing, The Localization Testing and Globalization
first step is to identify testing is done for adapting a product to
includes all the text all the textual information a local or regional
present on the in the system. This market & its goal is to make appropriate linguistic
application is producing application's GUI, and cultural
including error message/warning any text/messages that
aspects of product.
etc. and help/documentation These testing are performed with the
help of by translators, language engineers &
Main focus of the I18N localizers.
testing is not to find
product is ready functional defects, Internationalization and Localization Testing:
for the global market. but to make sure that
functional testing In non-functional
has been completed testing, it is assumed Reduces overall testing costs.
and all the functionality that
identified and removed. related defects are Reduces the support costs.
Help to reduce time for testing which result faster time-to-market.
It has more flexibility and scalability.
 ST & QA- MCA (Mgt.) :
Sem !!
2.52 Software Testing!
Fundamert
2.12 BLACK BOX VS WHITE BOX TESTING
Table 2.3 summarizes ST& QA - MCA (Mgt.) : Sem ll
the difference between 2.53 Software Testing Fundamentals
black box and white box
Table 2.3: Difference testing
between Black Box and 8
Types:
White Box Testing Types:
Sr. Static Black Box Testing
No. Black box testing Static White Box Testing
White b0x testing Dynamic Black Box Testing
Dynamic White Box Testing
1 Focus: /O behaviour.
For any given Focus: Thoroughness Statement Coverage
input, predict the Branch Coverage
output, if it (coveragel
matches with actual Every statement in
the coimponent
output then the Path Coverage
module passes is executed at least once. 9. Mainly applicable to higher levels
the test. of Mainly applicable to lower levels of
2 Tester oes not testing: Acceptance and system
programs code. have access to Tester testing. testing: Unit, integration testing.
He only knows has access to the program's
the software is supposed what code andcan examine
to do. He help him with his it for clues to 213 CONCEPT OF SMOKE TESTING
doesn't know HOW testing. AND SANITY TESTING
or WHY
happens? 2.13.1 Smoke Testing
3
It is testing Smoke testing is a software
against functional testing technigue used
specification. Testing based on that the software's essential after software builds to ensure
design and features are operating properly.
implementation functional or regression tests are run It is run before any
4 (specification may structures in detail.
It is not based on any be ignored). Smoke testing looks for
knowledge of It problerns in specific sections
internal design or deals with the internal entire application. of the program rather than the
on requirements code. Tests are based structure of logic and
"Build Verification Testing" or
and functionality. thecode. "Confidence Testing" are
Therefore, programming testing. other terms for Smoke
knowledge is
not required. It is used to test the acute
S. functionality of the software.
It will not test the developers deliver a new build Smoke testing is done When
errors associatedhidden functions and It will not test limited to being carried out
to the Quality Assurance teams,
However, it is not
with them will not missing functions (i.e. simply at the outset of a new
found. be those described continue to operate even if new project. Smoke testing will
in the functiona! modules are added to current
design specification It is done by both testers functionality.
implemented but not and developers because it is
It's part of the thorough testing process, simple and requires little time.
by the internal and it employs test cases to ensure
6 Black box testing specification or critical components of the build are
so code). that all
not possible to is named as it is White box Smoke testing is a subset
in working order.
look inside
determine the box to possible totesting is so named as it is of acceptance testing.
the design look inside The basic goal of smoke
implementation structures and determine the box to testing is to rcjecta software program
the the QA team doesn't waste that has flaws so that
components you are testing. of the| implementation design and time evaluating defective software.
components you
structures Smoke testing can save test
are testing. of the
7. Synonyms: effort while improving the application's
Behavioral the client and the organization, quality. Based on
Functional testing, testing, Synonyms: smoke testing can be done
Opaque-bOx Structural automatically. manually or
concrete Box testing testing, Box testing, Clear
and Closed-Box Box testing, Glass-Box testing, Open Real-Time Example: Assume
that you are working for an e-commerce
testing. testing. new build is released site. When a
for testing, as a Software QA you have to
core functionalities are make sure whether the
working or not. So you try to access
add an item into your.cart to place an the e-commerce site and
Contd order. That's a major workflow in most e
of the
 ST &
QA - MCA (Mat.)
:Sem ll 2.54 Software
Testing
Fundama,
Commerce sites. If this
flow works, you can say
to functional testing on same
this build is passed. You can
the build. ST&QA
-
MCA(Mgt.) :Sem ll 2.55 Software Testing Fundamentals
Advantages: moit

1. 3. Most of the time Sanity testing is not at all scripted, which may
It helps to find issues
in the early phase of testing. be a problem for
2. Some testers.
Improves the overall quality
3. Very limited of the system.
number of test cases is required to
Disadvantages: do the Smoke testing. Initlal or
Unstablo Build Smoko Tesing Smoke Tost
1
Is Yes
Smoke testing does is not Passcd
detailed.
2. Smoke testing
sometimes causes wastage
stable. of time if the software build
i Build 1
3. This type
of test is more suitable if you can automate;
spent manually executing otherwise, a lot of tima:. Build 2 System and/or
the test cases. Build Rejectcd
2.13.2 Sanity Testing Regression
Tsting
Sanity testing determines Build N
new module
build are stable enough to whether additions to an existing
proceed to the next stage softu:.
Surface Level Testing,
and it is required to quickly of testing. This is also known:
assess the
regressions. quality of softw Stable Build Sanity Testing Sanity Test
Yes
Sanity tests also guarantee is Passed
that any modifications
build's other capabilities. made do not affect
Sanity testing is a type the softwar:
assurance. of regression testing used in qual:y
Fig 2.26: Smoke Testing and Sanity
The goal is to determine Testing
testing is similar to Regressionif the proposed functionality works as expected. Sanity Summary
that cover all the AUT or testing in the fact that you
application area but ch0ose specific scenarios Software testing is the process of executing a
factors. It is executed at an shorter and based on software program or an application for
end in the process of a software the highest risk finding the bugs.
Real-Time Example: development Lifecycle. An error is a human action that produces an incorrect
Let's take the same result.
on an e-commerce example as above. Assume you
site. A new feature are working A defect is a flaw in a component or
system that can cause the component or system
functionality. Here your is released which
is related to Search to fail to perform its required function, e.g. an
main focus should be on incorrect statement or data definition.
make sure that the the search functionality. A defect, if encountered during execution, may cause a
Search functionality is Once you failure of the component or
major functionality such as payment working fine then you moves on
flow. to othe: system.
Advantages: A failure is actual
deviation of the component or system from its expected delivery,
1. It helps to
find related and missing objects. service or result.
It saves lots A software bug is an error, flaw, failure or
fault in a computer program or system that
of time and effort because
functionality. it is focused on one or causes it to produce an incorrect or unexpected result, or to
few areas of behave in unintended
3. It is the simplest way ways.
to assure ethe qualityof product
Disadvantages: the before it is developed. Software Testing Life Cycle (STLC) refers to a testing process which has specific steps
to be executed in a definite sequence to ensure that the quality goals
1.
Its scope is relatively narrow, compared to have been met.
i the other typesof testing. In STLC process, each activity is carried out in a planned and systematic way. Each
2. It focuses only on
the commands. andfunctions of phase has different goals and deliverables.
the software.
 ST& QA - ACA (Mgt.) :
Sem l 2.56 Software Testing
Fundame,
Unit testing is performed at developer's
well end to make sure that their code
and meets the user specifications. The QA - MCA (Mgt.)
: Sem l!l
aim of unít testing is to divide is ST &
2.57 Software Testing Fundamentals
of the program and test that the separate part are working
correctly. everj
Integration testing is a technique to Checking that we are building the system right
(c)

Modules are typically code verify joint functionality after (d) Performed by an independent test team
modules, individual applications, integra
applications on a network, etc. client and 6. What are the various Testing Levels?
Agite testing is specified as (a) Unit Testing
an advanced and dynamic (b) System Testing
performed regularly throughout every type of Testing (c) Integration Testing
iteration of the SDLC (Software (d) Allof the Above
Life Cycle) by the
agile test engineers.
Types of Black Box Testing:
Devel! thi 7. The plan for unit testing, system
testing, and acceptance testing is called
Functionality Testing and Non-functionality
Functionality testing used to Testing (a) A test plan
verify the functionality of (b) A development plan
whether the function is working the software applira:
according to the requirement (c) A Re-Test Plan
(d) None of above
The primary purpose specification.
of non-functional testing is to test 8. Software mistakes during coding are known as
software systemn as per non-functional the reading speed of
parameters. (a) erTOrS
In the V model, all the activities go (b) bugs
on the downward (c)
failures
in time, it starts moving in direction first and at one neis. (d) defects
the upward direction to re-use 9. Which testing technique
testing process and forms V the test document for tb,: is used for usability testing?
shape. (a) White-box testing
Smoke Testing is a software (b) Grey box testing
testing process that determines whether the deplor
software build is stable or (c) Black Box testing
not. (d) Comnbination of all
Sanity testing is performed 10. "" model is
working as properly. to ensure that the code
changes that are made ar. (a) Test type
(b) Test Level
Check Your Understanding
(c) Software development
testing (SDL(C) model
1 Which of the following (d) Test design technique
is not a valid phase
Cycle)? of SDLC (Software Development Lite
(a) Testing Phase ANSWERS
(c) (b) Requirement Phase |1. (d) 2. (a) 3. (b)
Deployment phase 4. (b) 5. (c) 6. (d) 7. (a) 8. (b)
2. Functional (d) Testing closure 9. (c) 10. (c)
testing is a
(a) Test type
(b) Test design
(c) Test level technique Practice Questions
3. Locating or (d) SDLC Model
identifying the bugs is known as Q.I Answer the following questions in short.
(a) Design
(b) Testing 1 What are the different methods of testing?
(c) Debugging
(d) Coding 2. What is SDLC?
4. Black box
testing is only functional testing. 3. What are the different levels of testing?
(a) True
(b) False 4. What is usability testing?
5. Verification is S. What is User Acceptance Testing?
(a) Making sure that is
it what the user really wants 6. What is system testing?
(b) Checking that we are building
the right system 7. Define the term: regression testing
 ST& QA - MCA (Mgt.) :Sem Softwarc Testing
Il 2.58
Fundamerta
Q.Il Answer the following questions.
1. Explain Load and Stress Testing?
2. On what basis the acceptance plan is
prepared?
3.
What is Verification and Validation in Software Testing?
4. Explain V modcl and W model.
3...
5. Describe seven
testing principles.
6.
7.
Explain any 4 non-functional testing types.
Write difference between smoke testing
and sanity testing.
StaticTesting
8
What is software testing? What is the effect
Q.III Write a short note on:
ofit on software quality?
1. Agile Testing
Objectives...
2. Smoke Testing To understand the concept of Static Testing.
3. Sanity Testing To study Review in Static Testing Techniques.
4. Structural Testing To study Static Analysis of Static Testing Techniques.
5. Functional Testing

3.1 INTRODUCTION
Static testing is a software testing techniquc for evaluating
the quality of the
software without actually executing the code.
This testing purposes to detect errors right from the requirement
gathering stage of
SDLC (software development life cycle),
all the way up to source code.
Finding errors in the documentation stages helps in the prevention errors
of at later
stages and thus, it is cost-effective to perform static testing.
Static testing is done either manually which is performed in Reviews or
through
testing tools that are performed in Static Analysis.

3.2 STATIC TESTING TECHNIQUES-REVIEW

Unlike dynamic testing, which requires the execution of software,
static
testing techniques rely on the manual examination and automated static analysis
(static analysis) of the code or other project documentation without the execution of
the code.
Various static testing techniques are:
o Reviews.
o Walkthroughs.
o Inspections.
o Audit.
Reviews are a way of testing software work products (including code) and can be
performed well before dynamic test execution. Defects detected during reviews early

(3.1)
 ST & QA - MCA (Mgt.) :
Sem ! 3.2
Statlc
in the life cycle (e.g., defects found Tet
remove than those detected in requirements) are often much cheape: ST& QA - MCA (Mgt.) Sem lll :

by running tests on the executing code. 3.3 Statlc Testing

Any software work
product can be reviewed, including B.2.1:1
design specifications, code, test plans, test requirements s
specificaticz; Informal Reviews
guides or web pages. specifications, test cases, test An informal meeting is a form of review where technical problems are
scripts,u discussed.
Benefits of static testing include • It is also called as peer-review i.e. simply giving a document to a colleague and asking
early defect detection and correction, them to look at it closely which will identify defects we might never find on our own.
productivity improvements, reduced develen
development timescales, reduced It is generally a one-on-one meeting between
and time; fewer defects testinp the author of a work product and a peer.
and improved communication. It finds No agenda is required and the results are also not
formally reported.
requirements, which are unlikely to be omissions
3.2.1:2 Formal Reviews
Typical defects that are found in dynamic testing.
easier to
include: deviations from standards, find in reviews than in dynamic testi.. Formal review in software testing is a review that characterized
by documented
requirement defects, design defects, procedures and requirements. Inspection is the most documented and
maintainability and incorrect interface insuffice formal review
specifications. technique.
3.2.1 Review Process (Informal & Formal) A formal review is the process under which static white-box testing is
performed.
Review is "A process or meeting
A formal review can range from a simple meeting between twO programmers a
during which a to
project stakeholders, user representatives, software product is examined b detailed inspection of the code.
or other interested Elements of Formal Review:
comment or approval". parties for feedbari
There are four essential elements of a formal
Software Reviews are a filter review:
for the software engineering process. 1. Identify Problems: The goal of formal review to
Reviews are applied at various is find problems with software.
points to 2. Follow Rules: A fixed set of rules should
another software engineering activity or find the errors before they are passed on t be followed. They may be the amount of
code to be reviewed, how much time will be spent.
released to the customer. what can be commented on and
Reviews provide a powerful way
to improve quality by SO on.
defects can be detected (and corrected) providing a means by which
3. Prepare: Each participant is expected to prepare,
A review is a way : early in development. which improves the
to effectiveness of the review. Depending on
the type of review, participants may
Point out needed improvements have different roles.
in the product. 4. Write a Report: The review group must produce a
Confirm those parts of a product written report summarizing the
in which improvement is either not results of the review and make that report available to
not needed. desired or the management and
Objectives of Review: development team.
Formal reviews are planned and may be held at any time.
1. To uncover errors
in function, logic, or implementation Formal Review Process:
the software. for any representation of The formal review follows the formal process
which consists of six main phases -
2. To verify that Planning phase, Kick-off phase, Preparation phase, Review Meeting
the software under review meets phase, Rework
3. To ensure its requirements. phase, and Follow-up phase.
that the software has been
represented according to 1. Planning:
standards. predefined
o The first phase of the
4., To
achieve software that is developed a formal review is the Planning phase. In this phase, the
in uniform manner. review process begins with a request for review by the author to the moderator (or
S. To make projects more
manageable. inspection leader).
Types of Reviews: o A moderator has to
take care of the scheduling like date, time, place and
There are two types of reviews: invitation of the review. Moderator performs entry checks and defines the exit
1. Informal Reviews criteria.
2. Formal Reviews o An entry check is performed to ensure that the reviewer's time is not wasted on a
document that is not ready for the review. Once the entry check for a particular
 ST& QA - MCA (Mgt.) : Sem
ll 3.4
Stallt
Te
document is passed, both moderator and author of the document
decide - (Mg.) : Sem
part of the document needs to review. vihin
ST & QA MCA l 3.5 Static Testing
o
The formal review team is consists of 4-5 members.
Moderators assign o Moderator of the project take care of these issues and ensure that all discussed
roles/tasks to each member. So each reviewer can focus on a diffex
items either have an outcome by the end of the meeting or are defincd as an
defect during checking. particular action point if a discussion cannot be solved during the meeting.
type:.
o This process not o At the end of the meeting, team members take a decision on the documents based
only saves time but also reduces the chances
of difere:, on exit criteria.
reviewers finding the same defect. dif
2. Kick-off Meeting: o If the number of defects found per page exceeds a certain level, then the
o The next phase of the formal review process an document must be reviewed again. If a project is under pressure, then the
o is optional kick-off meeting moderator will sometimes be forced to skip reviews and exit with a defect prone
The main goal of this phase
is to get everybody on the same document.
wavelength regardig
the document under review and to commit to Phases of Review meeting:
the time that will be sna
checking. 1. Logging Phase: Defects and issues are
o In identified in the preparation steps that
this meeting, reviewers receive a short are logged page by page.
introduction to the objectives
review and its document. Role assignment, pages of.. 2. Discussion Phase: This phase handles
the issues that require discussion.
to be checked, check rate. ari 3. Decision Phase: Decision on
other things that need to be carried out for the review are the document revicws is constructed by
Distribution of the review documents, source discussed. reviewers or participants. Sometimes decision is based on formal exit
documents are also shared during documents, and other relatahl. criteria (Average number of major defects found per page).
the kick-off meeting. A kick-off meetino 5. Rework:
highiy recommended as it motivates i Based on the defects detected, the author will improve
the reviewers. the document under
3. Preparation: review step by step.
o In this phase, o
Not every defect that is found leads to rework. It is the
using related documents, rules, checklist, author's responsibility to
member work individually on the documents. and procedures each team judge if a defect has to be fixed.
o These team o
lf nothing is done about an issue for a certain reason, it should be reported to at
members individually identify bugs, comments,
to their understanding questions according least indicate that the author has considered the issue.
of the document, and role. All these issues are Changes that are made to the document should be easy to identify during follow
the logging form. Spelling mistakes are recorded in
also recorded but not discussed up. Therefore the author has to indicate
where changes are made.
meeting. during the
o The 6. Follow-up:
annotated document will be given to o In the follow-up phase,
meeting. the author at the end of the loggina the moderator of the project is responsible for ensuring
The check rate is a critical success that satisfactory action has been taken for all logged defects, process
factor for this phase. The improvement, and change requests.
number of pages checked per hour. check rate is the
Optimum Although the moderator checks to make sure that the author has taken action on
factors, including types of documents, check rate is the result of a mix of
a number
of related documents, all known defects, it is not necessary for the moderator to check all the
complexity,and reviewer's experience.
Usually checking rate is corrections in detail.
in the range of 5 to 10 pages per o If it is decided that all team members will check the document and update the
preparation phase, a team member hour. During the
should not exceed the checking same, then the moderator just takes care of the roles distribution among the team
been asked to use. rate they have
o and collecting feedback from them.
Criteria for checking rate
and document size can be set o To control the review process, the moderator colects all the measurements at
measuring the review process. by collecting data and
each phase of the process. For example, the number of defects found a number of
4. Review Meeting: defects found per page, time spent on the documents, time spent to correct the
o
In the review meeting phase, all issues are discussed. defects per page, etc.
o Team member o It is moderator's responsibility that all details are correct and kept for future
forwards their comments and issues.
analysis.
 ST& QA ACA
(hgt.) : Sem
ll 3.6
3.2.2 Desk Checking Siatle
Te
Desk checking
is an informal manual test GT& QA MCA (Agt.) :
Sen I!
and algorithm logic that programmers can use
before a program launch.
3.7 Static Testing
to verify
might prevent program from
a This enables
them to spot Getting a different propramnmer to desk check may
2.
desk checking less working as it should.
Modern
cit
crrors person running the check also solve this issue. However, the
essential than it was debugging needs to understand the requirements behind
spotting logic errors. in the past,but it tools ta code before he can evaluate if it the
cah still bea useful. will work.
91 TIUeneCapureiype>0:/exit::" Rneck Checking and the Structured Walkthrough:
<ex1l:DateTipe Or Desk checking is sometimes part
iginal>2012 of a broader testing process. In a structured
<ex1l: DateTieDigit1zed>201:-:.
-1 walkthrough, for example, the programmer is
part a peer group that reviews and
<ex1l: IS03pecdPat analyzes the work prior to launch. The programmerof
ing3: typically gives the materials for
<rdt:3eq review to group members before
the meeting. During the meeting itself, she
<rdt: 11>100</rdt: group through the code. Ideally,
the group will spot errors if they exist or
walks the
</rdl:seq> l 1:
suggestions for improvement. Projects may make viable
7
</ex1t: IS03peedPat checking issues such as the have one or more walkthrough stages,
understanding of requirements
<ex1t: Lxi1Verzi0h79.
i i.g B.2!3 Technical or Peer Review andcoding accuracy.
<ex1l:Flash
rdf:p
<ex1t:Fired>Fal: ur According to IEEE standard: "The purpose
software product by a team of qualified
of a technical review is to evaluate a
<ex1l: personnel to determine its suitability
Kex1t: Peturh0!:i
Hode>:rferit:
intended use and identify discrepancies
In other words, the
from specifications and standards."
for its
<ex1t: Funcri " technical review is a meeting in
product to see it its quality is as which a team analyzes a work
Desk Checling Fig. 3.1: Example expected or ifit needs some improvement.
Overview: of Desk Checking It addresses technical issues
Desk checking a
such as evolving software products
is similar process design, and code), services, and solutions. (requirements,
runs through to proofreading.
In this example, Technical reviews are attended
lines of code only by persons with technical
Typícally, the programmerto identify errors and to check logic. the programme: subject matter and not management. knowledge of the
paper exercise. will print out o Includes
He may run a the code and go through Project leader, Reviewer and Developer
correctly and contain no manual test on it in a pencil and o In (Technical Personnel).
algorithms, checking requirements phase includes Customers, Users.
This usually involves coding errors. that they work Actual technical status
of the project is reported to management.
variables, conditions, creating a table with columns Technical review identifies risks
and inputs and outputs, containing line numbers, and issues to be raised at Management Reviews.
Advantagcs of Desk depending on the Examples:
Checking: checks he is making.
1. Even experienced programmers Code walkthrough.
fix them before a program make mistakes. A desk Formal Inspection of design and test case
goes through a check may help catch documents.
2. Running a formal run. and Technical Review Criteria for a Software
desk check is quick Product or Service:
code typically checks and inexpensive. o Is it complete?
it herself; if he identifies The programmer who wrote the
before the project moves issues, he can fix Does it comply with standards
error causes onto the next stage. them on the spot and specifications?
problems later down If he doesn't desk Are changes properly implemented?
also be harder to identify a the line, it might check and an
delay a project. Does it adhere to the applicable schedule?
at
Disadvantages of Desk Checking: later stage. Errors may o Is it
ready for the next planned activity?
1. A
desk check does not Is development being conducted according to
guarantee that a programmer the plans, standards,and guidelines
focus to human error. will find mistakes. of the project?
Programmers may It is also
miss
because they wrote
the codethemselves and arethings that need to be fixed. simply 3.2.4 Management Reviews
too close to it to
be objective. Technical Reviews provide inputs to Management Reviews as
illustrated in Fig. 3.2.
 ST & QA - MCA (Mgt) : Sern l!
3.8
stalcTe
Technical
Plan Review - ACA(Mgt.) :
sT& QA Sem il
Code 3.9 Static Testing
Status
3.2.5 Walkthrough
Walkthrough is the next step up in formality
Questions
from peer reviews.
Prelminary Technical Working of Code Walkthrough:
Review Management
Requirement Risks Review The programmer who wrote the code
Specification
group of 5-7 programmers formally presents (walks through) it to a small
and/or testers.
The reviewers (senior programmers)
so they can examine
should receive copies of the software in advance,
it and write comments and questions
Issues review. that they want to ask at the
Technical
Preliminary The presenter reads through
Interface
Review the code line-by-line, or function-by-function,
Specification explaining what the code does and why.
The revicwers listen and
question anything that looks doubtful.
provides clarification if required. The presenter
Address project issues Fig. 3.2: Management Review The presenter notes down relevant
like Status versus points and takes corrective actions.
and Quality. Plans, Test Reports, Purposes of Walkthrough:
Schedules, Standav
A walkthrough can have a
Management is informed two-fold purpose.
about status, direction, 1. It is performcd
Are attended by technical and agreements. to evaluate a software product
leaders, project managers, Find anomalies / inconsistencies. with the purpose of:
authority over cost and and managers (with
schedule). decisicn Improve the software product.
Identify and resolve risks.
Receive input Consider alternative implementations.
and resolve issues from Evaluate the conformance to
Examples: several Technical Reviews. standards and specifications.
2. To exchange
Design review. techniques and perform training
raise all team members to of the participants. It is a method to
Test readiness review. the same level of knowledge
styles and details of the product. regarding programming
Management Review
Criteria: 3:2.5.1 Levels or Types of Code
s progress according
to plan?
Walkthrough
Informal: Code is presented to the reviewer
Are schedules, standards, who simply reviews it "on-the-spot".
Are resources adequately and guidelines being followed?
is reserved for simple,confined, This
and non-critical changes.
Are risks evaluated allocated? Formal: Code is presented to the
reviewer and the reviewer examines
Are we making
and a mitigation algorithrms for proper style, the code and
good decisions
plan drawn? format,and technique. This is reserved for
based on metrics? a
changes of critical nature and those complex code
Do we need to changes that may impact multiple
change direction or Coding Standards and Guidelines: subsystems.
Peer Review: revise plans?
There are problems where the code may
A peer review, a operate properly but may not
be written to
review technique, meet a specific standard or guideline.
Peer review is the which a
evaluation of work is static white-box testing. Guidelines to perform code Walkthrough:
the producers of by one or more The team performing the Code
Peer Rating: the work (peers). people of similar
competence to Walkthrough should not be either too big or too
Preferably, it should consist of three to seven members. small.
Peer rating is a The discussion should focus on
technique of evaluating the detection of errors and not to how to fix
overall quality, anonymous programs these
maintainability, errors.
The purpose extensibility, usability, in terms of their
of the technique is to and clarity. Managers should not attend the Walkthrough
meetings in order to promote
provide programmer
self-evaluation. cooperation and to avoid the feeling among
the engineers that they are being
evaluated in the code Walkthrough meeting.
 ST & QA- MCA (Agt.) : Sem
I! 3.10
sialc
Example: Programming standard that deals with
Te:t
the use of C
language goto, ST& QA- MCA (Agt.) :
Sem |
and if-else statements. 3.11 Static Testing
Titl: Control-Restriction on control structure 6 Informal, so there is no moderator.
Moderator has a role in making sure
Standard: that the discussions proceed on the
The goto statement (and labels) should not be used. productive lines.
The while loop should be 7 Main purpose is to judge product Main purpose
used instead of the do-while loop, except where is to measure/improve
the problem explicitly requires execution of the body at least once thelogic quality, find defects, and provide quality of
product and prOcess.
loop condition regardless. training if required.
Ifa single if-else can replace continue, an if-else should be used. 3.2:6 Inspection
3.2.5.2 Outcome of Code Walkthrough Software inspection is a static verification method
with a high degree of technicality
and formalism.
There can be three outcomes to the Code Walkthrough: Do not require execution
of a system so may be used before implementation.
Successful: All required checks and quality are present. May be applied to any representation
of the system (requirements, design, test data,
may be released into the approved build. In this case, the softws..
etc.)
Corrective Action needed, No Further Review needed: The primary objective of the software
A list of items to b. inspection is to detect and correct defects early
corrected is presented. Once these are performed, before they leak into the subsequent
phases. This improves the quality and
the code walkthrouph i productivity of software development.
complete. This is usually applied for minor changes.
Inspections improve software quality, maintainability,
Corrective Action needed, Review needed: A reduce time to delivery, and
list of items to be corrected it lower development costs.
presented. Once these are performed, another
code walkthrough is necessar: Roles in Inspection:
This is applicable in case of major changes or a There are four roles in inspection.
critical functionality.
3,2.5.3 Difference between Walkthrough and 1. The
author or producer of the code.
Inspection
Table 3.1 summarizes the difference between 2. A mnoderator or
review leader who is expected to formally run
Walkthrough and Inspection. the inspection
Table 3.1: Walkthrough Vs Inspection according to the process.
3. The inspector or
Sr. No. Walkthrough reviewer who provides, review comments for the code.
Inspection 4. A scribe or recorder, who takes
1, Informal Type of Review (Semi detailed notes during the inspection meeting and
Formal type of Review. circulates them to the inspection team after
Formal Review) the meeting.
Limitations:
2
Initiated by the author Initiated by the project team Advance preparation should occur but should require no more
3 It is unplanned. than two hours of
Planned meeting with fixed roles work for each person.
Reviewers are not aware of the assigned to all the members Theduration of the inspection should be less than two hours.
involved.
subject/topic. Reviewers are aware & Inspection Guidelines:
well prepared for
the subject/topic. Review the product and not the producer.
Anthor reads the product code
Set an agenda and maintain it.
4
and Reader reads the product
his team mate comes up code. Everyone Limit denial and debate.
with inspects it and comes up
defects or suggestions. with defects.
Express the problem area, but don't attempt to solve every problem noted.
5. Author makes a note of etects Recorder Take written notes.
records the defocte
and suggestions offered by team Limit the number of participants and insist on advance preparation.
mate. Develop a checklist for each product that is likely to be reviewed.
(Checklist contains items that are imnportant or relevant toan issue or situation).
Contd.
 ST& QA - MCA (Mgt.) :
Sem l! 3.12
Slatic
Alocate resources and schedule atime Tesi
for all reviewers. ST & OA - MCA(Mg.) : Sem Ilt
Conduct meaningful training 3.13
Review your early reviews.
for all reviewers. .Stalic Testing
The software product to be inspected.
Inspection/Review Process: Docurmented inspection procedure.
1. The individual
who has developed the work Inspection reporting forms.
project leader that the work product product i.e. the producer informe . Current anomalies or issues list.
is complete and that a review
2. Project leader contacts a review is required. o Inspection checklists.
leader or
readiness, generates copies inspector, who evaluates the Any regulations, standards, guidelines,
product plans, and procedures against which the
of the product
three reviewers for advance preparation. materials, and distributes them to th. software product is to be inspected.
The inspection leader Hardware product specifications
training about the inspection process. has to have a for if required.
3. Each reviewer Advantages of Inspection:
spends between one to two
to understand the product. hours reviewing the product, making
Review leader also reviews ntt. 1. Reduction
in user reported defects.
agenda for the review the product and establishesa. 2. Increased customer
satisfaction
4 meeting. 3. Increased
The review meeting is development productivity, which
attended by the review leader, materializes in shipping more
One of the reviewers takes all reviewers, and the produre: function in a given time or reduction
the role of the recorder, who in time to delivery.
important issues raised during records (in writing) : 4. Improvement in
the review. meeting committed schedules.
5. Review begins 5. Rapid cross-training
with an introduction of the agenda of developers and maintainers on
and a 6. Authors rapidly the new products.
producer. Producer then proceeds brief introduction by tha. learn to avoid creating defects
to "walk through" the inspections that find defects in through participating in
product. product, explaining tt their own work products and in
6. Reviewers raise products of others. the work
issues based on their advance 7. Team building and
7. At the end of the review, preparation. Inspections may eliminate the need to
all attendees of the review decide this is not recommended. unit test code, though
a) Accept the product without whether to:
further modification. 8. Inspections can
check conformance with a specification
b) Reject the product
due to severe errors. Once with the customer's real requirements. but not conformance
up must be performed. corrected, another review or follc
Statistical evaluation in Figure 3.4 shows
c) Accept the product
provisionally. i.e. minor errors that over the software development life
cycle, inspections save time, resources,
must be corrected, but no have been encountered and cost and improve the quality
additional of the product.
Inspection process can be summarized asreview will be required.
shown in figure 3.3.
Employees

Planning

Overview
Requirements

Individual Follow-up
preparation Design
Without inspection
Rework
Inspection Planning

meeting
Coding

Fig. 3.3:Inspection With inspection

Process Test

Input to the inspection:

According tothe IEEE standard theinput to the inspection shall Time
A
statement of objectives for the inspection. include : Fig. 3,4: Statistical Evaluation of Software development
With and Without inspection
 ST & OA - IMCA
(Mgt.) : Som
ll 3.14
3.3 STATIC TECHNIQUES
- STATIC ANALYSIS stale
Tev,
In Static Analysis, T&OÂ- MCA (Mgt.): sem
11l

software or an application 3.15 Static Testing

the code written by is tested to find the
developers without structural
Static Analysis is
usually done by
actually executing ít. der. Interface Faults Parameter type mismatches.
unused/ unrefcrenced the tools and is used to uncover Parameter number mismatches.
variables,
coding standards programming standard violation, the defcr. Non-usage of the results of functions.
unfollowed, dead syntaxviolaticz
Stagcs of Static code (code written
but not used anywhere), ete Useless or Uncalled functions and procedures.
Analysis:
Control Flow Analysis: Storage Management Faults Unassigned pointers.
Checks for loops with multíple
unreachable code, etc. exit or entry points. Pointer arithmetic.
Data use Analysis: ,fin's
Detects uninitialized 3.3.1 Data Flow Analycis
without an intervening variables, variables
assignment, variables written ti. pata flow analysis can be used to
etc. which are declared increase program understanding
but never ue cases based on
data flow within the program. and to develop test
Interface Analysis: Checks Data flow testing selects test
and their usc. the consistency of routine paths according to the location of
definitions and use of
and procedure declaratior: data / variables.
Information Flow Analysis: It is the testing in which test cases are
Identifies the dependencies designed based on variable usage
not detect anomalics of output variables. Doe: code. within the
itsclf but híghlights
review. information for code Testing based on data flow. It
checks whether data is defined,
inspection o modified and sequence
Path Analysis: Identifies of data related events.
paths through the program pata-flow anomalies:
executed in that path. and sets out the statements
Again, potentially Data flow anomalies represent
Static Analysis Checks: useful ín the review process. the patterns of data usage which may
incorrect execution of the code such as. lead to an
Various Static Analysis
Checks are summarized o Variable
defined but not used.
in Table 3.2.
Table 3.2: Static Analysis Variable used but not defined.
Checks o
Variable has been defined twice
Fault Class before using.
Static Analysis Checks Notations for Anomalies:
Data Faults The notation for representing
Variables used before the patterns is:
initialization.
Variables declared d: defined, created, initialized
but never used.
Variables assigned k:killed, terminated, undefined
twice but never
between assignments. used u:used
Undeclared Variables. C:used in a computation/calculation
Array bound violations. p:used in a predicate
Control Faults Unreachable code. -X:indicates all prior actions are not of interest to x
Uncondítional X; indicates all post act 's are not of
branches into loops. interest tox
Input/output Faults Variables output Table 3.3 lists the combinations
twice with no of usage and their corresponding consequences.
assignment. intervening can be observed that not It
all data-flow anomalies are harmful but they are
all
suspícious and indicate that an error can occur. For example,
the usage pattern 'ku'
Contd. indicates that a variable is used after it has bcen killed which a
is serious defect.
 ST & OA - MCA (Mgt.) :
Sem IlII 3.16
Stallc
Table 3.3: Testing Anomalies Tette
- :
ST&QA MCA (Mgt.) Sem l 3.17
Anomaly Static Testing
Explanation Bill 40;
~d first define Allowed,
>
du define-use if(Usage 100)
Allowed. Normal case.
dk define- kill if (Usage <= 200)
Potential bug. Data is killed
without use after definition Bill =
Bill + (Usage 100)
first use 0.5;
Potential bug. Dataisused without definition. else
ud use - define Allowed. Data is used and then redefined. =
Bill Bill +
50 + (Usage - 203)
0.1;
uk use- kill Allowed.
if (Bil1 >=
=
10)
Bill Bill 0.9;
-k first kill Potential bug. Data is killed before definition.
}
ku kill-use Serious defect. Data is used
after being killed.
kd kill - define Allowed, Data is killed and
return Bill;
then re-defined.
dd define- define Potential bug. Double definition. The control flow diagram is given
in Fig. 3.5 and the annotated control flow diagram
uu with define-use-kill information for
use-use Allowed. Normal case. each variable is given in Fig. 3.6 and Fig. 3.7
respectively.
kh kill - kilI Potential bug. 0. Start
0. Start
define last Potential bug.
= 0 1. define Bill
1. Bill
U use last Allowed.
k
kill last Allowed, Normal case
usage >0 Y 2 3. define Bill
3, Bill = 40
Types of Data Flow Testing:
Static Data Flow Testing
Dynamic Data Flow Testing
4.
4
3.3.1.1 Static Data Flow Testing Usage > 100 Usage <= 200
With static analysis,the source N
code is analyzed without executing
an example of an application it. Let us consider
to calculate the bill of a 6. use B1
cellular service custome: 7 6. Bill = Bill + 50 +

use
depending upon on his/her usage. Bill > 100 (Usage - 200)
Bill
define Bill

Example: 0.1
(Y N
Consider the following source code: 8. use Bill
l8. Bill = Bill 0.9 define Bi

calculateBill (int Usage) 9. Bill = Bill +

10. return Bill (Usage- 100)*

10, use Bill 9. use Bill
define Bill
double Bill = 0; 0.5
if(Usage > a) 11. End 11. Kill Bill

Fig. 3.5: Control Flow Diagram Fig. 3.6: Annotated Control Flow Diagram
for Variable Bill'
 ST & OA - MCA (Mgt.)
:Sem Ill
3.18
Slatic
0. define usage Tet
sT& QA - MCA (Mgt.) : Sem |
3.19
Static Testing
Table 3.4: Static Analysis
for variable 'Bil1'
Anomaly
use usage 3 Explanation
0-1 Allowed. Normal case.
dd 0-1-2-3 Potential bug. Double definition.
4 du 3-4-5-6
use usage 5. Allowed. Normal case.
use usago
ud 6 Allowed. Data is used
and then redefined.
uk 10-11 Allowed
1-2-3
Potential bug. Double definition.
6. use usage 7-8 Allowed. Normal case.
|k 11 Allowed. Normal case
N
8 Table 3.5 covers the
Static data flow testing for
any bug. Variable 'Usage' and did not
0
discover
9. use usage
Table 3.5: Static Analysis
11. kill usago for variable 'Usage'
Fig.3.7: Annotated Anomaly
Control Flow Diagram Explanation
For variable 'Usage', for Variable 'Usage' -d Allowed
- define: normal case the define-use-kill patterns
are: du 0-1-2 Allowed. Normal case.
define-use : normal case uk 9-10-11 Allowed.
use-use:normal case
S-6 Allowed. Normal case.
use-kill:normal case k
11
For variable 'Bill', Allowed. Normal case.
the define-use-kill patterns Static Data-flow testing
~
define: normal case are: will fail in situations
cannot be determined where the state of a data
by just analyzing variable
define-define: suspicious variable is used as an the code. This is possible
index for a collection when the data
define-use :normal case For example, in case of data elements.
of arrays, the index might
use-define: acceptable execution. Hence we be generated dynamically
can't guarantee what the state during
use-use: normal case referenced by that index. of the array element is which is
use-kill:normal case Static analysis methods are
also inadequate for :
The static data-flow Dead variables : Detecting
testing for the given unreachable variables is unsolvable.
anomaly: application discovered Pointers: Impossible to verify
the pointer values at compile time.
Bill:define - define following 3.3.1:2 Dynamic
Data Flow Testing
Table3.4 covers the Static data flow The primary purpose
usage 0-1-2-3 is a potential testing for Variable of dynamic data-flow testing is to uncover
bug. 'Bill' and discovers usage during possible bugs in data
the execution of the code. To achieve
that the trace every definition to this, test cases are created which
each of its use and every use
definition. is traced to each of its
 ST & QA - MCA (Mgt.) :
Sem l
3.20
Data Flow Testing salic
Strategies: Tes
Various testing strategies ST& OA - MCA (Mgt.) : Sem
employed for the creation of !
Table 3.6: Testing Strategies thetest cases are: 3.21
Static Testing
for the creation of the test cases 6
All-c-uses/Some-p 'For every variable and every definition
Sr. Testing Strategy uses (ACU+P) of that variable,
No. include at least one path from
Explanation the definition to every
computational use; if there are definitions
1. All-du paths
'Every du path from every that are not covered then add predicate useof thecases
variable
(ADUP) definition of every required to cover ever y definition'. test as
every use of that definition' variobe In this testing strategy, for every
It is the strongest data-flow from every definition to every c-usevariable, a
there is path
testing strategy since it i there is a definition of that definition. If
superset of all other no c-use
data tlow testing stratepia use of the definition with following it, then a p
Moreover, this strategy All-definition (AD) is considered.
requires greatest number patb.i 7. 'Every definition of every
for testing. of one use of that variable be covered by at least
2
All-Uses (AU) variable, be that use a computational use
'At least one path from every or a predicate use'.
definition of every variable
to every use of that can be In this strategy, there is path every definition to at
reached by that definition' least one use of that de finition. from
For every use of the Note: ln the above tabe italic text shows
variable, there is a Formal Definition of Testing
definition of that variable to the use. path from th Eyample: Strategy.)
3. .
All-p-uses (APU) 'APU Strategy is derived from APU+C Let us consider our billing application
by dropping the control flow graph is and perform dynamic data-flow
requirement of including a C-use there are no p-use annotated testing.The
if references to all other variables for each variable (Fig. 3.8 and Fig. 3.9) by removing
instances following the definition' and
definition, 'c-use' for computational replacing the contents
use and 'p-use' of the nodes with 'def for
In this testing strategy, for every 0. Start
for predicate use.
variable, there is path
from every definition to every p-use 0. daf
of that definition. t
there is a definition with no p-use following 1. def
dropped from contention.. it, then it is
4. All-c-uses (ACU)
'ACUStrategy is derived from ACU+P Y
by dropping the 2 3. def 2
requirement of including a p-use p-uso 3
if there are no c-use
instances following the definition'.
In this testing strategy, for every
variable, there is a path
from every definition to every c-use 4 4.
5.
there is definition with no c-use of that definition. If
p•use
a p-use
following it, then it is N
dropped from contention.
5. All-p-uses/Some-c- |For every variable
and every definition of that variable, 7.
uses (APU+C) include at least one N p-use
6. C-use,def 7 6. C-use
path from the definition to every
predicate use; if there are
definitions of the variable that Y
are not covered then
add computational use test cases as 8. C-use,def
required to cover every definition'.
In this testing strategy, 10. C-use 10
9. C-use
for every 9. C-use,def
from every definition to every variable, there is a path
p-use
there is a definition with no p-use of that definition. Ii 11. End 11

use of the definition following it, then a C Fig. 3.8: Annotated Control Flow Diagram Fig. 3.9: Annotated Control Flow
Diagram
is considered. for
for Variable 'Usage'
Variable 'Bill'
ST& OA - ACA
(Mgt.):Sem
ll 3.22
The testing Static
Teslrg
strategies are then applied to
cases are derived. the annotated control flow ST& QA - MCA (Mgt.)
:
Sem l!
graphs 3.23
Table 3,7 presents andte:, Static Testing
application. the list of test paths for variables 'Bill' 8-10
and 'Usage' of tho
In Table 3.7 for variable bilin, 9-10
'Bill': All du
Path 1-2-10 depicts an all-definition (ACU + P) +
(ACU+ P) +
For All c-uses, we path from definition in 1 to c-use (ADUP)
(APU + C)
trace a path for every definition of in 10. (APU + C)
path tracing from every C-use to Bill to at least one c-use All definition 1-2-10
its definition. The same 0-1-2
applies for All p-useeanda (AD)
3-4-5-6
Table 3.7: Data flow testing
paths for each variable 6-7
Strategy 8-10
Bill Usage
All uses 9-10
3-4-5-6 0-1-2 After obtaining the test paths,
(AU) test cases are created by giving
6-7 0-1-2-3-4 parameter (Usage'). We alues to the input
obtain different test suites
6-7-8 0-1-2-3-4-5 application considered, we get 2 for each variable. For the
test suites for 'Bill' and 'Usage'
8-10 and3.9 shows the test suite for Variable respectively. Table 3.8
0-1-2-3-4-5-6 'Bill' and Úsage'.
3-4-5-9 0-1-2-3-4-5-9 Table 3.8: Test suite for
Allp- uses Variable 'Bill'
1-2-3-4-5-6-7 0-1-2 Uses Bill
(APU) Input Usage Value Expected Value
3-4-5-6-7 0-1-2-3-4 All definition 1-2-10
6-7 0-1-2-3-4-5 (AD)
3-4-5-6 0.0
All c- uses 220 92.0
1-2-10 0-1-2-3-4-5-6 6-7
(ACU) 220 92.0
3-4-5-6 0-1-2-3-4-5-9 8-10 350 94.5
3-4-5-9 9-10 220
3-4-10 All c- use 92.0
1-2-10
6-7-8 (ACU) 0.0
3-4-5-6 220
6-7-10 92.0
6-7-8 350
8-10 94.5
8-10 350
9-10 94.5
All p-use/somec 9-10 220
1-2-3-4-5-6-7 92.0
0-1-2 All p- use 1-2-3-4-5-6-7
(APU + C) 3-4-5-6-7 220
0-1-2-3-4 (APU) 92.0
3-4-5-6-7 220
6-7 92.0
0-1-2-3-4-5 6-7
8-10 220 92.0
All c-use + p 1-2-10
9-10 0.0
(ACU+ P)
Allc-use/some p 1-2-10 3-4-5-6 220
0-1-2-3-4-5-6 92.0
(ACU + P) 3-4-5-6 3-4-5-9 170
0-1-2-3-4-5-9 75.0
3-4-5-9 6-7-8 350 94.5
6-7-8 8-10 350 94.5
9-10 170 75.0
Contd..
Contd.
 3.24 StalcTes
Al p-use+c 1-2-3-4-5-6-7 220 sT& QA- MCA (Mgt.)
: Sem lll
3.25 Slatic Testing
92.0
(APU + C)
3-4-5-6-7 220 92.0 In addition with Code Coverage (Statement, Branch, Path and Function coverage)
6-7 220 92.0 discussed earlier. CFA also deals with Independent Program Paths and Loop Testing.
S-10 350 94.5 B3.21 Independent Program Paths
9-10 170 75.0 An independent path is any path through the program that introduces at least one
Al uss 3-4-5-6 220 92.0
new set of processing statements or a new condition.
(AU) 6-7 When stated in terms of a flow graph, an independent path must move along at least
220 92.0 one edge that has not been traversed before the path is defined. For example, a set of
6-7-8 350 94.5
independent paths for the flow graph illustrated in Fig. 3.10 is:
8-10 350 94.5
3-4-5-9 170 75.0

Table 3.9: Test Suite for Variable 'Usage'

Uses Usage Input Usage Value Expected Value
All definition 0-1-2 0.0 Path 1:1-11
(AD)
Path 2:1-2-3-4-5-10-1-11
Allc- use 0-1-2-3-4-5-6 220 92.0 Path 3:1-2-3-6-8-9-10-1-11
(ACU) 0-1-2-3-4-5-9 170 75.0 Path 4: 1-2-3-6-7-9-10-1-11
All p- use (APU) 0-1-2 0.0
0-1-2-3-4 170 75.0
0-1-2-3-4-5 170 75.0
All c-use + p 0-1-2-3-4-5-6 220
(ACU + P)
92.0
0-1-2-3-4-5-9 170 75.0
All p-use +c Fig. 3.10 : Flow graph
0-1-2
(APU + C) 0.0 In Fig. 3.10, a sequence of process statement (2) and a decision statement (3) is
0-1-2-3-4 170 -
75.0 mapped into a single node (2, 3) and a sequence of process statements (4 and 5) is
0-1-2-3-4-5 170 -
75.0 mapped to a single node (4,5).
All uses 0-1-2
0.0 Note that each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10
(AU) 0-1-2-3-4 170
75.0 1-11 is not considered to be an independent path because it is simply a combination of
0-1-2-3-4-5 170 the already specified paths and does not traverse any new edge.
75.0
0-1-2-3-4-5-6 220
92.0 Paths 1, 2, 3 and 4 constitute a basis set for the flow graph in Fig. 3.10. That is, if the
0-1-2-3-4-5-9 170 tests can be designed to force execution to these paths, every statement in the
75.0
programn will have been guaranteed to be executed at least one time, and every
3.3.2 Control Flow Analysis
condition will have been executed on its true and false sides.
Control Flow Analysis (CFA) 15 a stattc code analysis
the control flow of a program. technique for determining It should be noted that the basis set is not unique. In fact, a number of different basis
1ne control flow is expressed as a sets can be derived for agiven procedural design. Test cases should be derived so that
Graph (CFG). Control Flow
all of the paths are executed.
ST& QA - MCA (Agt.):
Sem lll 3.26 static
Testi Sem lI Static Testing
sT&QA - MCA(Mgl.) : 3.27
3.3.2.2 Loop Testing
applied to nested loops is
Loops are the basis of most algorithms implemented the loops are not independent the approach
using software. Loop testing i. recommended.
white-box testing approach that concentrates on the validity of loop constructs.
to the use of
Four loops can be defined: Simple Loops, Concatenated Loops, Nested A. Unstructured loops: This class of loop should be redesigned reflect
Loops. a. the structured programming constructs.
Unstructured Loops (Fig. 3.11).
B.3.3 Static Analysis by Tools (Automated Static Analysis)
Automated static analysis tools can identify
a wide range of software anomalies such

(i) Noncompliance with coding and documentation standards

(ii Whether there are unreachable codes (use of GOTO statement).
(iii) Variables declared but not used.
iv) Mismatch in definition and assignment of values tovariables.
(v) Illegal typecasting of variables.
(vi) Memory allocated but have having corresponding statements for freeing them.
vi) Null pointer dereferencing, endless loops, floating-point arithmetic problems
and many more.
Static analysers are software tools for source text processing. They parse the program
text and try to discover potentially erroneous conditions and bring these to the
SIMPLE LOOPS CONCATENATED LOOPS
NESTED LOOPS attention of the V8V team.
Fig. 3.11: Classes of Loops Very effective as an aid to inspections. A supplement to but not a replacement for
inspections.
1. Simple Loops: The following group of testsshould be used on simple loops, where
n is the maximum number of allowable passes through the loop: Static analysis tools check for consistency in coding guidelines. For example :
Naming conventions, Allowed data types, and so on.
Skip the loop entirely.
Working:
Only one pass through the loop.
Static analysis tools determine application size and identify vulnerabilities while
Two passes through the loop.
generating key code metrics. The calculation is used in conjunction with additional
m passes through the loop where m <n. assessment practices to determine complexity or identify defects.
n-1, n, n+1passes through the loop. Static analysis tools that provide a benchmarking score are used by organizations and
as software is
2. Nested Loops : For the nested loop, the number of possible tests increases as the developers to monitor aspects such as code quality or productivity
level of nesting grows. This would result in an impractical number of tests. An created or enhanced.
approach that helps to limit the number tests is:
of
The benchmark measurement is effective for determining application size,
can be used to
Start at the innermost loop. Set all other loops to minimum values. complexity, and quality. As systems evolve, static analysis tools
scores. It is a fast, cost effective
Conduct simple loop tests tor the innermost loop while holding the outer loop monitor code improvement efforts based on updated
at their minimum iteration parameter value. approach to detailed source code evaluation.
TAJerk outward, performing tests ror Static analysis tools are generally used by developers
as part of the development and
the next loop, but keeping all other outer is not
Ioons at minimum values and other nested loops to "typical" yalos component testing process. The key aspect is that the code (or other artefact)
or run tool itself is executed, and the source code we are interested
Continue until all loops have been tested. executed but the
Concatenated loops can be in is the input data to the tool.
3. Concatenated loops: tested using the techniques
These tools are mostly used by developers.
1Cood for simple loops, 1t e2cu o the loops is independent
of the other when
 ST & QA - MCA (Mgt.) :
Sem l| 3.28 Statlc
Characteristics: Testie
:
sT& OA MCA (Mgt.) Scm l!
-
To calculate metrics 3.29 Static Testing
such as Cyclomatic Complexity or
help to identify where more testing may Nesting levels (which 3. If the programming language allows mixed case names, are
be needed due to increased risk). there
To enforce coding standards. variable names with confusing use of lower case
letters and capital
To analyze structures letters?
and dependencies. Are all the common structures, constants,
To help in code and flags to be used defined
understanding. in a header file rather than in each file
To identify anomalies or separately?
defects in the code.
An Automated Static
Analysis tool helps programmers Data usage related:
within source code. Missed source code eliminate critical defa
problems experienced within an defects account a
for large percentagp Y, N, NIA

system failures, and infrastructure including performance t 1

Are valucs of right data types being
degradatite assigned to the variables?
compliance problems.
Static analysis tools provide insight 2 If pointers are used, are they initialized?
environments where several about potential vulnerabilities in compley 3 Are bounds to array subscripts
languages or technologies exist. and pointers properly checked?
There are various static analysis 4 Has the usage of similar looking operators
tools such as: (For example : = and = =
or & and && in C) checked?
Jtest: Java Testing and static code
analysis product by Parasoft. 5. Is the access of data from any
JSLint: JavaScript syntax checker standard files, repositories, or
and validator. databases done through publicly supported
Lint: The static code analyzer C. interfaces?
for
Clang: An open-source compiler Control flow related:
that includes a static analyzer.
Pylint: Static code analyzer for Python. Y, N, N/A

3.4 CASE STUDY : PREPARATION OF SOFTWARE Are all the conditional paths reachable?
CHECKLIST INSPECTION 2. Are "goto" and "labels" used only
when absolutely necessary?
It is useful to have a Software 3. If there is a nested "IF" statemnent, are the THEN
Inspection Checklist. Checklist and ELSE parts
should be used to drive the inspection. of common errors appropriately delimited?
Error checklist is programming 4 In branch like SWITCH I CASE statement,
dependent. language is a default clause
a provided? Are the breaks after each CASE
In multi-product organization, appropriate?
the checklist may beat two levels: Are there are any loops that wil never execute?
1. Organization-wide
Checklist: It includes issues as organizational
such 6. Is there any part of code that is unreachable?
standards, documentation standards, coding
and so on.
2. Product or Project-specific
Checklist: It addresses issues Standards related:
or project. specific to the product
Given below is a checklist Y, N, N/A
that covers some of the common issues.
1. Does the code follow the coding conventions of the
Example 1: CODE REVIEW CHECKLIST organization?
2. Does the code follow the coding conventions
Data item declaration related: that are platform
specific?
Y, N, N/A
1. Are the names
of the variables meaningful? Style related :

2. Are the variables inítialized? Y, N, NJA

:
1
Are unhealthy programming constructs (For example Globa!
variables in C) being used in program?
 ST &
QAACA (Mgt.) : Sem ll 3.30
Static
Miscellaneous : Tesr
- : Ill
ST& OA MCA (Mgt.) Sem
Y, 3.31 Static Testing
N, NJA
1 Have you checked for memory Computation (Lexical rules for operators) :
leaks (For example : Memory
Y, N,N/A
but not explicitly freed)? acquite,
Do assignment and
conditional operators always have space
Documentation related: around them?
Y, N, Are commas and semicolons
NJA followed by a space?
3 Are unary operators adjacent to
1 Is the code adequately documented, their operands?
especially where the loeie : 4. Do primary operators "s"
complex? "" "0" have a space around them?
(Should have none)
Is appropriate change history documented? :
Comments
Y, N,N/A
Exception related :
1
Isthe module header informative
Y, N, NIA and complete?
2. Are there sufficient comments to
1
Have all possible error conditions 3.
understand the code?
been taken into account? Are the functions of arrays and
variables described?
4
Are changes made to a module
Example 2: Code review checklist, after its release noted in the
especially forClanguage. development history section of the header?
Functionality : Interface Related:
Y, N, NIA Y, N, N/A
1
Is there code, which should 1. Do all function and procedure calls have
be in a separate function? the correct number of
2. Is the code consistent parameters?
with performance requirements?
3
Does the code match
2
Do formal and actual parameter
the detailed design? types match?
3. Are the parameters in the right
order?
Data, Constants, and Variables : 4. If components access shared memory, do
they have the same
Y, N, NIA model of the of the shared memory
structure?
1
Are allvariable names
lower case? Summary
2
Are all constant names upper Static testing isa software testing method
3 case? that iinvolves the examination of a
Are constants defined via. program, along with any associated
4
"# define"? documents, but does not require the program to
Are constants that are be executed.
used in multiple
INCLUDE header file? files defined in an
Static testing is performed for the following reasons: We can
Control and Linkage : find and address defects
and errors early on. It improves development productivity.
Y, It reduces testing costs
N, N/A and the timeline for dynamic testing
later on.
1
Are "else if" and "switch" Static testing is carried out with two different steps or
used clearly? techniques: Review and Static
2 Are "goto" and "labels" Analysis.
used only when absolutely
3 Is "while" necessary? Review is typically used to find and eliminate errors or
rather than "do while" ambiguities in documents
Are "INCLUDE" files used wherever possible? such as requirements, design, test cases, etc.
4. used according to
5. Are nested "INCLUDE project standards? In static testing, reviews can be divided into four
different parts: Informal Review,
files avoided?
WalkThrough, Technical Review, Inspection
 ST & QA• MCA (Mgt) : Sem lM 3.32
Siallc
Teai
Static Analysis is the code written by developers are analysed (usually sT & OA - MCA (Mgt.)
:
Sem iI
by tool3) 3.33 Statlc Testing
structural defects that may lead to defects.
(c) Revicwer
Static Analysis can be further classified into three parts, Data Flow. Control (d) Scribe
Cyclomatic Complextty. Flow (c) (a) and (d)
Phases of formal reviews are: Planning, Kick-off, Preparation,
G
Which is a formal review technique?
Review
Rework, Follow-up. meelg, (a) Walkthrough (b) Pecr to Peer Review
Static code analysis is the process of detecting errors and (c) Inspection
defects in software,
(d) Al of the above
sOurce code. 6. 'If static testing is done prior to dynamic testing, it would be
beneficial'. True or
The static data flow testing process involves analyzing the source code False.
withou
executing it. (a) True
(b) False
Control flow analysis (CFA) is a static program 7. Which documents can be revicwed in static testing?
analysis for determining the cont..
flow of a program, which is usually expressed as a (a) Functional requirement specification
control flow graph (CFG),
Static analysis tool is typically used by the (b) User manual
developers before and somnetimes durits
component and integration testing. (c) Code
Check Your Understanding (d) Design document
(c) All of the above
1. Which are the benefits of Static Testing?
8. Which are methodologies of Walkthrough?
(a) Early feedback of a quality."
,(a) Scenario, Dry Run, Peer Group (b) Kick-off Meetings
fb) Less rework cost.
(c)
Formal Follow up Process
(c) Increased developmental (d) Includes Metrics
productivity. 9. Which of thefollowing is not a static testing technique?
(d) All of the above
(a) Error Guessing (b) Walkthrough
2. Arrange the following phases of a Formal
Review, according to the (c) Data Flow Analysis
they are conducted. order in which (d) Inspections
10. In Static Testing
1.Preparation
(a) code is not executed (b) code executed twice
2. Kick-off
(c) code executed repeatedly (d) None of the above.
3. Review meeting
4. Planning
5. ANSWERS
Follow up
1. (d) 2. (c) 3. (a) 4. (e) 5.(c) 6. (a) 7. (e)
6. Rework 8.(a)
(a) 1, 2,
4,3, 6, 5 9.(a) 10. (a)
(b) 4,1, 2, 3, 6, 5
(c) 4, 2, 1,3, 6, 5
(d) 4,2,1, 3, 5, 6
3 Which of the following can be Practice Questions
found using static testing
(a) Defect techniques?
(b) Failure QIAnswer the following questions in short.
(c) Both
(d) None
of the these
1. What are the static testing techniques?
4. During review meeting, defects are logged
by 2. What is meant by data flow analysis?
(a) Author (b) Moderator 3. Which are types of Reviews?
4. What is thedifference between static and dynamictesting?
 ST& QA- ACA
(agt.) : Sem ll
3.34
5. Explain Walkthroughs. Stalic
Tesi
6. Write examples
of Technical Review.
Q.II Answer
the following questions.
1 What is Dynamic data
2. Explain
flow testing?
in brief Loop testing.
4...
4 What are
verification and validation?
S. What are
the valuable steps to
6. What are the
7. Explain the
resolve issues while
phases of a formal review? testing? Dynamic Testing
data flow analysis in detail.
8. Differentiate
between Walkthrough
Q,III Write a and Inspection. Objectives...
short note on:
1 Informal Review.
To learn about Black Box Testing
2. Technical Techniques.
Revie. To learn White Box Testing Techniques.
3. Inspection [ To know Experience-based
Techniques.
4. Review Meeting
5. Desk-checking
4.1 INTRODUCTION
Dynamic Testing is a kind
of software testing technique using which
behaviour of the code is analysed. the dynamic
The main aim of the Dynamic
Tests is to ensure the correct
during the installation of and workings of the
after installation of the software, to ensure software,
of the application, without any major defects. the stability
It validates the software's stability
and efficiency before and after execution.
Dynamic Testing is classified into two
categories: White Box Testing and Black Box
Testing.

4,2 TEST DESIGN TECHNIQUES - BLACK BOX TESTING TECHNIQUES

.

The black box is a powerful technique to

check the application under test from the
user's perspective.
Black box testing is used to test the system against external factors responsible for
software failures.
Following are some techniques of Black-box testing.
4.2.1 Equivalence Class Partitioning
Equivalence partitioning is a testing method that divides the input domain of a
program intoclasses of data from which test cases can be derived.
It defines a test case that uncovers classes of errors, thereby reducing the total
humber of test cases that must be developed.
This method is typically used to reduce the total number of test cases to a finite set of
testable test cases, still covering maximum requirements.
(4.1)
 ST & QA- MCA (Agt.) : Sem l! 4.2 Dynamic
Testir
Identification of Equivalence Class: ST& QA - MCA (Mgt.) : Sem ! 4.3 Dynamic Testing
An equivalence class represents a set of valid or invalid states for
input conditica, nevelopment of the actual test cases:
Typically, an input condition is a specific numeric value, a range of
values, After the equivalence classes have been identified,
related values, or a Boolean condition. a setc the next step in test case design is
Equivalence classes may be defined according to
thedevelopment of the actual test cases. A good approach includes the following
the following guidelines or steps.
conditions :
list o 1. Each equivalence class
should be assigned a unique identifier.
1. Range: If an input condition specifies a range,
then select one valid cquivalera 2. Develop test cases for all valid equivalence classes
until all have been included in a
class that covers the allowed range and two
invalid equivalence classes, test case.
outsíde each end of the range. 3. Develop test cases for all invalid equivalence classes
For example, suppose the specification for insurance until all have been included
module says that an ins. in a test case.
age lies in the range 25 to 45;
then select one valid equivalence class that includ. 4.2.2 Boundary Value Analysis
all values from 25 to 45. Select a second
equivalence class that consists of al Boundary value analysis (BVA) is a test case
values less than 25, and a third equivalence class design technique that complements
that consists of all values proater equivalence partitioning. Rather than selecting any
element of an equivalence class,
than 45. BVA leads to the selection
2. Specific value: If an input condition
of test cases at the "edges" of the class as shown in Fig. 5.3.
requires a specific value, then select one
valid equivalence class that includes the value
and two invalid equivalence
classes that are outside each end of the allowed number.
Equivalence Partition
For example, if the specification for a
project management module says that a
project can have one to four testers, then
select one valid equivalence class that
includes all the valid number of testers,
and two invalid equivalence classes for Boundary
less than one tester and more than Boundary
four testers.
3. Set of valid input values: Fig. 4.1: Boundaries of an equivalence
If an input condition specifies a set valid input BVA is the method partition
valucs, then select one valid equivalence of useful for arriving at tests that are effective in catching defects
class
the set and one invalid equivalence class anythat contains all the members of that happen at boundaries. BVA believes and extends
the concept that the density of
for value outside the set. defect is more towards the boundaries.
For example, if the specification
for a paint module states that Guidelines for BVA:
Green and blue are allowed as the colors Re. Guidelines for BVA are similar in many respects to
inputs, then select one equivalence those provided for equivalence
includes the set Red, Green class that
and blue, and one invalid equivalence partitioning:
other inputs. class for all 1. Range If an
input condition specifies a range bounded by values a and b, then
:

4, "must be" condition : If an input test cases should be designed with - values a and b as well as values just
condition specifies a must above and
select one valid equivalence class to be condition, then just below a and b.
represent the "must be"
invalid cquivalence class that does not condition and one For example,for the insurance modu!e mentioned previously specified
include "must be" condition. that age
For example, if the must lie in the range 25-45; then boundary values for age are: 24, 25,
specification for a registration
characters of username must be module states that the first 4
letters, then select one valid 26,44,45,46.
where first 4 characters are equivalence class
letters and one invalid class 25 45
are not letters. where the first 4
characters
5. Boolean Condition: If an input condition is Boolean,
then select one valid
invalid equivalence class. and one
24 25 26 44 45 46

Fig. 4.2: BVA using range of values

 ST & QA - MCA
(Mgt.): Sem ll 4.4
Dynamic
In above example, 6 Testna
groups. For example:
boundary values (24, 25, MCA (Agt.) : Ill
26, 44, 45, 46) form ST&QA- Sem 4.5
the h Dynamic Testing
BLB -Value
just below the lower The conditions in the decision table may be
• LB -Value on bound i.e. 24. interpreted as the inputs, and the actions
the lower boundi.e. 25. may be thought of as outputs.
ALB - Value
just above the lower Cause Effect Graph (Decision table):
BUB -Value just bound i.e. 26.
below the upper bound It is a software test design technique
i.e. 44. that involves identifying the cases (input
UB -Value on the upper bound conditions) and effects (output conditions), producing a
i.e. 45. Cause-Effect Graph, and
AUB -Value just generating test cases accordingly.
above the upper bound
2. i.e. 46. Use of decision tables for test designing:
Number of values: If an
input condition specifies a The first task is to identify a suitable
should be developed that number of values, test cate function or subsystem which reacts according to
exercise
just above and below minimum the minimum and maxdmum numbers. a
combination of inputs or events. The system should not
contain too many inputs
and maximum are Val. otherwise the number of combinations will
o For example, also tested. become unmanageable. It is better to deal
for the project management with large numbers of conditions by dividing
specified that a project can module mentioned previously that them into subsets and dealing with the
one to four testers, subsets one at a time. Once you have identified
testers and 4,5 testers would have tests that include 0.1 the aspects that need to be combined,
be developed. then you put them into a table listing all the combinations
4.2.3 Decision Table Testing of the aspects.
of True and False for each
A decision table is a
good way to deal Examples:
associated outputs and also called with different combination inputs with their
table is an associated logical cause-effect table. Reason to 1. Consider the scenario of Printer Troubleshooting:
call a cause-effect
diagramming technique called
that is basically used to derive the decision cause-effect graphing Conditions Printer does not print Y Y

We can apply Equivalence

table. YY N NNN
A red light is flashing
Partitioning and Boundary Value Analysis N Y
only specific conditions or inputs. techniques to NN
Although, we Printer is unrecog.ized
in different actions being taken or secondly weif have dissimilar inputs that resul: N N|Y N Y
are different combinations have a business rule to test that there Actions Check the power cable
X
of inputs which result in different actions.
We use a decision table to test Check the printer-computer cable X X
these kinds of rules or logic. It is a tool
look at the "complete" combination that helps us Ensure printer software is installed
of conditions. Decision tables are very much
helpful in test design technique. It helps testers
X X X
to search the effects of combinations Check/replace ink X X X
of different inputs and other software states must correctly implement business
rules. They also provide a regular way of that Check for paper jam X
statingcomplex business rules, that's helpful
for developers as well as for testers. 2. Employees working on salaried or hourly basis:
Testing combinations can be a challenge, as Conditions/
buge. It assists in the development process
the number of combinationscan often be Rules
with developers to do a better job. Testing Course of Action
with all combinations might be unrealistic or 1 2 4 5 6
unfeasible. It is basically an Condition
outstanding technique used in both testing and requirements Employee type H H H
management. It is a
structured exercise to prepare requirements when dealing with Stubs Hours worked <40 <40 40 40 >40 >40
complex business
rules. Also, used in model complicated logic. Pay base salary X X X
Theconditions in the decision table may take on any number
of values When it is Action Calculate hourly wage X X
hinarv then the decision table conditiOns are Just uke a truth table set ofconditions
The decision table allows the iteration or Stubs
al ne combinations of valuee af the Calculate overtime X
condition, thus it provides a "completeness check. Produce Absence Report
 ST& QA- ACA (Mgt) : Sem
ll 4.6
Dynamic
Advantages of Decision-Table: Testre
- MCA (Mgt.) :Sem
1
Allow us to start witha "complete"
sT& QA ! 4.7
view, with no consideration of Dynamic Testing
2,
Allow us to look at dependence. Invalid PIN
and consider "dependence", "impossible"
situations and eliminate some test cases. and "not
relevarr Insert card PIN OK
3 Allow us to detect potential errors
in our specifications. Deposit
Disadvantages of Decision-Table: withdrawal
1. Need to
decide (or know) what conditions are
2. Scaling up can be massive: relevant for testing.
2n for n conditions.
4.2.4 State Transition Testing Account Account
This testing is used where some
aspect of the system can
called a 'finite state machine'. be described in wha:.
This simply means |InsertAmount
number of different states, that the system can be in a (finie envelope Retry
determined by the rules and the transitions from one
of the 'machine. This is the state to another 2 Withdraw card No
the tests are based. model on which the system and Confirm?
Any system where you get a |Yes
different output for the same
has happened before, is a input, depending on wht Withdraw card
finite state system.
One of the advantages
of the state transition technique
detailed or as abstract as you is that the model can be as Fig. 4.3: State Diagram
need to be. Where a part for ATM System
important (that is, requires more of the system is more
Where the system is less testing) a greater depth Example 2:
important (requires less of detail can be modeled.
state to signify what testing), the model can use a single Let us consider
would otherwise be a series another example of a word processor.
of different states. able to close it. If no document open, If a document is open, you are
EXAMPLES: is then 'Close' is not
'Close' once, you cannot available. After you choose
Example 1: choose it again for the same
document. A document thus document unless you open that
has two states: open and closed.
Consider an example
of an ATM of the bank to 43 TEST DESIGN TECHNIQUES
corresponding State Graph. demonstrate the steps on
creating
-WHITE BOX TESTING TECHNIQUES
Customner uses a
(COVERAGE BASED AND FAULT
bank ATM to check balances BASED)
withdraw cash and/or of his/her bank accounts, White Box Testing is software
transfer funds (use cases). deposit funds, testing technique in which internal structure,
maintenance and repairs to ATM Technician and coding of software are design
the ATM. provides tested to verify flow of input-output
For example, if you request desig, usability and security. and to improve
cash. Later you may towithdraw Rs.1000 from a bank ATM, you may Coverage based and fault
make exactly the same request be given based are strategies of white box testing.
money because your but it may refuse to give you Fault based testing attempts to
your bank accountof insufficient balance. This later refusal is the show the absence of certain classes of fault in code.
because the state of Code is analysed for uninitialized of unreferenced
has changed from having variable, parameter type checking
to having insufficient sufficient funds to cover etc. For example,
funds. The transaction the withdrawal Mutation testing.
state was probably the earlier withdrawal. that caused your account to White Box Testing
change its Types:
A state diagram can Static White Box Testing: It does not need the
represent a model from execution of the software. It is the
account or the customer. the point of view of process of carefully and
the system, the methodically examining the design and code.
Dynamic White Box Testing:; Dynamic analysis
is what is generally considered as
"testing", i.e. it involves running the system.
 ST & QA- MCA (Mgt.) :
Sern il 4.8
Dynamic
Statement Coverage: Testing Testng
performed where every statement ST& QA - MCA (Mgt.) :
Sem || .
least once. is executed Dynamic Testing
Branch Coverage:
Helps
sure that no branching in
validating all the branches
in the code
leads to abnormal behavior
Path Coverage: Testing all of the application. and makina

possible paths.
Coverage based Testing:
These types of White
box testing techniques
program to propose utilize the logical flow
test cases. By logical throuoh
parts of a program may flow that means
be executed as we run the way in which certai.
Execution of a test case causes the program.
Corresponds to taking a the program to execute
specific path through certain statements, whick
Different paths can be the flow graph.
taken by varying
edge to be taken from a the conditions to cause a
branch node. Branch, different
from the execution Statement and Path coverage branct
path of a program in ways isderived
edges and paths within that correspond to visiting Fig. 4.4 : Flow graph
the flow graph. nodes. showing statement coverage
Types of Code Coverage Various examples of statement coverage
based Testing: can be:
Code coverage testing <A, B, D, H, K>, <A, B, E,
H, K>, <A, C, F, I, K>, <A,C, G, I, K>
is made up of the following
(i) Statement
Coverage.
types of coverage: 43.2 Branch and Decision Coverage
(ii) Branch Branch coverage is determined
/
Condition Coverage. by assessing the proportion
(iii) Path Coverage. exercised by the set of decision branches
of proposed test cases. 100% branch coverage
decision branch in the program is where every
(iv) Function Coverage. is visited by at least one test.
4.3.1 Statement Coverage Branch coverage Total decisions exercised
=
Total number of decisions program x 100
Statement coverage Branch coverage corresponds in
is determined by assessing coverage is to visiting the branch edges
by the set of the graph. 100%
of proposed test cases. 100% statementthe proportion of statements visited where all branch edges are visited by
the paths taken by the test cases.
in the program is visited by at coverage
least one test. is where every statement
Statement coverage =
Total statements
Total number of executable exercised
Statement coverage statements in program
corresponds to visiting * 0
where all nodes are the nodes of the graph.
visited by the paths 100% coverage is
There are 10 nodes in the taken by the test cases as
sample flow graph. shown in Fig. 4.4.
Nodes<A, B. D, H,
K> trace one execution
path
10 nodes,
thus 50% coverage. Actual statementthrough
coverage
the program. It visits 5
of the
coverage levels levels may differ
depending on the way your graph from
many statements are is defined, e.g. node
grouped as one node, etc. For depending on how
anda decision statement can map instance, a sequence
into a single node, instead 2 of process
of nodae
Fig. 4.5 : Flow graph showing Branch Coverage
 ST & QA- MCA (Mgt.) :
Sem ll 4.10
Dynamic
There are 6
branch edges
traces one execution in the sample flow graph (Refer Fig. 4.5). <A, Teste eT& QA- MCA (gt.)
:
Sem IlI|
4.11
path through the program. It visits 2 B, D, H,L, Dynamic Testing
33% coverage. of the 6 branch
edges, 4.3.3 Path Coverage
Example 3: thy
Path coverage is determined by
For the code in Fig. assessing the proportion of execution paths through a
4.6 (a) and its corresponding programn exercised
by the set of proposed test cases.
would have to develop test cases flow graph in Fig. 4.6 (b). a ouery path 100% path coverage is where
case that satis fies that exercise nodes 1-8 in t..
the graph. A possible .
in the program is visited by at least one test.
Path coverage corresponds to
100% branch coverage uisiting the paths through the graph.
is shown in table 4.1. 100% coverage is where all
the test cases. paths are taken by
1, pos_sum(a, no, sum) 1,2,3
Path coverage = Total paths exercised
2. Sum = 0 Totalnumber of
pathsin program
There are 4 paths in the sample
3. int i 1 False flow graph (refer Fig. 4.7). Path <A, B, D,
one execution path H, K> traces
through program. the It visits 1 of the 4 paths,
while(i=no) I Truo thus 25% coverage.
if(a[i] >
0)
6. 5
Sum = Sum + |False
a[i] Truo
end if
i = i + 1
end while
8. end pos_sum

Fig. 4.6 (a): Code sample

with branch
and loop
Fig. 4.6 (b): Flow
graph for code in Fig. 4.6
()
Table 4.1: A Test Case
for the code
in Fig. 4.6 (a)
that satisfies the Branch Coverage Fig. 4.7 : Flow graph showing
Decision or Branch Criteria Path Coverage
Value of variable i Value of predicate Statement, Branch and Path Coverage
Differences:
Test case: Value of It is possible to have 100% statement coverage
without 100% branch coverage.
a, no All nodes are visited, without
visiting all branch edges.
no =3 Example 4: Example corresponds program:
to
while a = (1, -45, 3})
1
True
2 True if A then B;
3
True
4
False
if 1
True Note that
2
there is no else part.
False
3 True
 ST& QA- MOCA
(Mgt) :Sem I
4.12
Dynamic
It is possible to have 100% branch coverage Testig :
All branch edges are visited, without 100% path coverage. sT &
QA- MCA (Mgt.) sSem l 4.13
without visiting all paths. Dynamic Testing
Example 5:Example corresponds Solution:
to program:
ret us label the statements in the code as Flow graph of above code:
below for statement and decision
coverage as follows:
Procedure liability
if A then B else C; (age, gender, married, premium)
ifD then E else F; begin
1. premium :=5e0;
2. if ((age<25) and (gender=male) and
Two paths visit all branch edges, but there (not married)) then T
are 4 possible paths through the graph. 3. premium := premium + 1500:
else if ((married or (gender
=
4.
female)) then
premium := premium - 290:
S.
6. if ((age>45) and (age<65)) then
Where 100% path coverage is achieved, 100% branch coverage is achieved by default. premium := premium - 100;
7.
Where 100% branch coverage is achieved, 100% statement coverage is achieved by 8. end;
default.

Example 6: Based on the following procedure, identify 2 test conditions for each of
following: (1) Statement Coverage:
Married Nodes visited
(i) Statement coverage. Test case Age Gender
{1,2,4,5,6,7,8)
55 Female Yes
(ii) Decision coverage. 1
7 out of8 nodes visited i.e.
87%

statement coverage
(iii) condition coverage. {1,2,3,6,8}
coverage. Male No
(iv) Multiple condition 2 20 5 out of 8 nodes
visited i.e. 63%
(age, gender, married, premium) statement coverage
Procedure liability
begin Coverage:
Decision Coverage/Branch
(ii) Condition2 Condition3
premium :=500; Married
Condition1
((age <
25) and (gender
=
male) and (not married)) then Test case Age Gender (Node 4)
(Node 6)
if (Node 2)

premi um := premium + 1500; False True

True

or (gender female)) then Yes

=
Female False
else if ((married
premium - 20;
1 50
Male
Yes False True
False
premi um := < 65) ) then
20
No True
False
> 45) and (age Male
if ((age um - 00;
3 20

premi um ::
premi

end;
 ST & QA MCA-(Mgt.) : Sem 1! 4.14
(iii) Condition coverage Dynamic
& (iv) Multiple condition Testg
Let us consider coverage: - MCA(Mgt.) : Sem I
following
conditions for sT& QA 4.15
condition and Flow graph of Dynamic Testing
coverage as multiple condition the code:
.The various complexity metrics are :
follows:
1. Lines of code
Procedure 1iability
2. McCabe's cyclomatic complexity
(age, gender,
marricd, premium) 3. Halstead's software science
begin
1, Lines of Code:
1
premi um
:-500; It is simple metric. It counts
the number of lines of the code in a program
if ( (aqe <
25) and (gender the count as measure of complexity. and use
male)
and (not narried) ) 2. CyclomaticComplexity :
2. then It is software metric that
Prenium : premium + provides a quantitative measure
1500; complexity of a program. When used of the logical
else if (
(married or (qender in the context of the basis path
method, the value computed for Cyclomatic testing
female) ) then complexity defines the number of
3. independent paths in the basis set a program
Premium : premi um - of us
and provides with an upper
200; bound for the number of tests
if ((age that must be conducted to ensure that all
45) and (age <65)) statements have been executed at least once.
4 then
Premi um :
premium - 100: Cyclomatic complexity has a foundation
in graph theory and is computed in one
5. end; of following three ways :
C1- age < 25 The NUMBER OF REGIONS corresponds to
F the Cyclomatic complexity.
C2-gender = male Cyclomatic complexity, V(G), for a flow
graph G is defined as:
C3-not married V(G) = E-N + 2

C4-married Where E is the numt er of edges, and N is number

of nodes.
C5- gender = female Cyclomatic complcxity, V(G), for a flow graph G is also
defined as:
C6- age > 45 V(G) = P+1
C7-age < 65 5 Where Pis the number of PREDICATENODES Contained
in the flow graph G.

4.3/4 McCabe's Cyclomatic Complexity

Metric
Cyclomatic Analysis:
Code complexity testing is a method to
determine how
he tested. This is achieved thoroughly a program should
by various complexity
combination of the size metrics, which are based on
of the program and complexity of the logic
program. used to control the
Complexity metrics can be used as an input for risk-based
would lead us to assume higher likelihood of failure. By testing. High complexity
programs we can use the programs complexity as a breaking down a system to
component of
factor used in calculating risk levels. the likelihood
In defining the risk level, the tester still needs to assess
theimpact of
each program, as well as the likelihood of defect turning into a
a the failures for
failure.
Fig. 4.8 : Flow graph
 St& QA- MCA (Mgt.) :
Sem l 4.16
Referring Dynamic
the Flowgraph of Fig. 4.8, the Cyclomatic complexity
Te1th
- MCA (Mgt.) : Sem
using each of
thealgorithms discussed above: can ST& QA 4.17
be computel Dynamic Testing
The flow graph
has four regions. 20-40 Very complex, testability is low;
V(G) = 11 edges cost/e ffort to maintain is high.
-9 nodes +2 =4 > 40 Not testable, any amount
of money/effort to maintain may not
V(G) =3 predicate
nodes +1=4 (Predicate enough. be
Referring to Flowgraph nodes -2, 3, 6)
using of Fig. 4.9 (b), the Cyclomatic 3. Halstead's Software Science
:

each of the algorithms complexity can be compluteA Halstead's metric is based on

discussed above: the use operators (e.g. keywords) and
The flow graph has (eg. variable names, data base objects) of operands
three regions used in aprogram.
V(G) = 8 edges primitive measures of Halstead's
-7 nodes + 2=3 software science are :
V(G) =2 predicate n1 = Number of distinct operators
nodes + 1=3 (Predicate in program
nodes - B,E) n2 = Number of distinct
operands in program
N1 =
Number of operator occurrences
A.
N2 = Number of operand occurrences
input(score)
Based on these primitive measures,
B
if score <
45 Halstead developed a system
expressing the total vocabulary, of equations
C. then print (fail') the overall program length, the potential
volume for an algorithm, minimum
D. the actual volume (number of
else print ('pass') program), the program level (a measure bits required to specify a
E. if score > 80 of software complexity), program difficulty,
and other features such as development
F. then print("distinction' ) effort and the projected number of
the software. faults in
G. end Halstead's major equations include
the following:
Vocabulary (n) = n, +n,
Length (N) N = N, + N,
= n, log, (n,) + n, log, (n,)
Fig. 4.9 (a): Sample Code Volume (V) = N
Fig. 4.9 (b): Flow log, (n)
Complexity is additive. Graph
Module A N
log,(n, +n)
complexity of 9, their combination has complexity of 7 and module B has o
is complexity of 16. Level (L) L =
For small programs V/V
Cyclomatic complexity can =
automated tools are be calculated (2/n)x (n,/N)
essential 1or big and complex programs. manually, but Dificulty (D) =
complexity number, one can Based on the D V/V'
conclude what actions (Inverse of L)
complexity measure using Table 4.2. need to be taken for
o
Table 4.2: Meaning Effort (E) E = V/L
of ComplexityMeasure o
Complexity Faults (B) B = VIS
Meaning (Bug prediction) = (N, +
1-10 Well-written code, testability N) log, (n, +n)/3000
is high; cost/effort to Where,
10-20 Moderately complex, testabulity maintain is low.
is medium; cost/effort to V" is the
maintain minimum volume represented by a built-in function performing
is medium. the entire program. the task of

S 1s the mean number of decisions between errors (S is 3,000 according to

Contd. Halstead).
 ST & OA- MCA
(Mgt.) : Sem
l 4.18
Deriving Test Dynamic
Cases: Testm
sT& QA - MCA (gt.) Sem
The basis : Iu
path testing method can 4.19
sOurce code. Basis be applied to a detailed Dynamic Testing
path testing can be seen as a procedural design pisadvantages of data flow testing:
Using the design or set of steps. or
code as the basis, tt A few
disadvantages of data flow testing are:
Determine the Cyclomatic draw an appropriate Good knowledge
flow graph. of programming is required for proper
complexity of the testing.
Determine a basis set resultant flow graph. Expensive.
of linear independent paths.
Prepare test cases o
Time consuming.
that will force execution
Data should be selected so of each path in the basis set. Techniques of data flow testing:
test case is executed that the conditions at Data low testing can
the predicate nodes are be done using one of the following
and contrasted with tested. Ed two technigues:
been completed, the tester can the expected result. 1 Control flow graph
ensure Once all test cases
at least once. that all statements in h:e 2. Making
the program are executel associations between data definition
and usages.
4.3.5 Data Flow based 43:6 Control Flow Graph
Testing
What is data flow A
control flow graph (CFG) is a
graphical representation
testing? the order of statements in of the flow of control, ie.
Data flow testing is a which they will be executed.
white-box testing Consider the following piece
respect to the variables technique that examines of pseudo-code:
used the data flow with
andchecks their values at eachin the code. It examines the initialization variables 1. input (x)
instance. of 2. If (x>5)
White box testing is a
software testing technique 3. Z = X +
10
of the software code being developed. that examines the internal workinz 4. else
Types of data flow
testing: 5.
There are two types 6. print("Value of
of data flow testing: Z:", z)
1. Static
data flow testing: The declaration, In the above piece
of code, if the value x
usage, and
examined without executing deletion of the variables are the order of execution statements of entered by the user is greater than 5, then
the code. A control flow of would be:
2. Dynamic graph is helpful in this.
data flow testing: The variables 1,2,3, 6
execution of the code. and data flow are examined • If the value entered by the user
zith the in line 1 is less than or equal to 5,
Advantages of data flow testing: execution of statements would the order of
be:
Data flow testing 1,4,5, 6
helps catch different
kinds of anomalies Hence, the control flow
anomalies include: in the code. These graph
of the above piece of code will be:
Using the above control flow
Using a variable without declaration. graph and code, we can deduce the
table mentions the node at table below. This
Deletinga variable without declaration. was used:
:hich the variable was declared and the nodes at
which it
Defining a variable two times.
Deletinga variable without using it in the code. Table 4.3
Variable Name Defined At
Deleting a variable twice. Used At
Using avariable after deletingit. 1 2

Not using a variable after defining it. 3, 5 6

Me can use the above table to ensure
that no anomaly occurs in the code by ensuring
multiple tests.For example, each variable is
declared before it is used.
 ST & QA - MCA (Mgt.) :
Sem ll 4.20
Dynamic
Making Associations: Testre
eT& QA - MCA (Mgt.) : Sem ll! 4.21
In this technique, we make associations Dynamic
between two kinds of statements: the associations are divided Testing
1 Where variables are defined. into these groups, the tester
2. Where those variables examines each point. makes test cases and
are used. ctatements and variables
An association is made which are found to be extra are
with this format: removed fromthe code,
(ine number where the 4.3.7 Mutation Testing
variable is declared, line Aftation testing is another white
used, name of the variable) number where the variahl, box testing approach of
requires knowledge of code structure, generating test-data
For example, (1, 3, x) would mean
that the variable 'x is defined on nnroach. Mutation testing is but it is classified as a fault-based that
line 3. used to evaluate the effectiveness testing
line 1 and usedos
Now,consider to a system. It is also called as defect seeding. of the testing applied
the following piece of pseudo-code: De Millo proposed
1. input (x) the mutation-testing
scheme in 1978. In this testing
mutate or change technique, we
2. if(x>5) certain statements in the source code
3.
able find the errors. It is a
to and check if the test code is
Z = >X
+ 10
cases i.e., whether technique that is used to assess
4. elSe they can reveal certain types of faults. the quality of the test
5. x - 5 Mutation testing starts
Z = with a code component, its associated
6. print("Value of Z: results. The original code component test cases, and the test
", z) is modified in a simple way to
For the above snippet similar components provide a set of
of pseudo-code, we that are caled mutants. Each mutant
will make the following of the modification. The contains a fault as a result
(1, (2,t), x):
for the true case of IF statement associations: original test data is then run
data reveals the fault in with the mutants. If the test
o (1, (2,), x): in line 2 the mutant by producing a
for the false case of IF statement execution, then the mutant different output as a result of
(1,3, x): variablex being in line 2 is to
said be killed. If the mutants
is as a result produce same output
used in line 3 to define of execution, then the test are not adequate i.e. they are
o (1, 5,
x): variable x is being the value of z of revealing the defects. The tester data not capable
o (3, 6, z): used in line S to define then must develop additional test
variable is being used
z the value of z the fault and kill the mutants. data to reveal
o (5, 6, z): in line 6, which is defined
variable is being used in
z in line 3 Mutation Testing Tools :
The first two associations are line 6, which is defined in
line 5 Following are some of
for the IF statement on thepractically implemented Mutation testing tools:
the condition is true, and the line 2. One association
is made if
o
:
Jester Mutation testing tool
A
other is for the false case. in Java (Open Source)
Now, there are two types uses Pester: A Mutation testing tool
of of a variable: in Python (Open Source)
Predicate use: The use a o Nester:
A Mutation testing tool
of variable is called p-use. in C# (Open Source)
flow of the program, e.g., line 2. Its value is úsed to o Insure++ : A
decide the commercial testing tool offered by Parasoft
Computational use: The use Mutation testing. Inc. which leverages
a
compute another variable or of variable is called c-use when its value is Advantages of Mutation
A
the output, e.g.. line 3. used Testing:
fterthe associations are made, 1. It can show the ambiguities
these associations can in code.
Al definitions coverage be divided into these groups:
2. It leads to move reliable
Allp-use coverage product.
3. A comprehensive
Allc-use coverage testing can be done.
Disadvantage
Allp-use, some c-use coverage of Mutation testing:
All c-use, some p-use cOverage
1. It can be difficult to kill some
mutants.
All uses coverage <. very mutant needs to be executed after being compiled. This can be very time
Consuming especially if there are a lot of them.
 4A TEST DESIGNTECHK10UES -EPEIENCE
ZASED
TECH0T:
tTIul:ȍ al: pleya
Tthee
le in thu.
1iniue: cun br helpful in ioskinz ot for
by
ttier s1rurtured one: lets that wre Dyl 23iiy ide
Types of Lrperienced
Pased Testing:
Lrror Ge:ing Testing
7 Checrlizt-bazrd
Teting in oTder 19 eífectiveiy
3 ixpiratury Teztitog 1es a prut. Tiias wi.
erprorye.:l .
441 Lrror Guessing Testing EzDloratory testing Js
periorinedto rereGine th.e
l::atisna c .
Error Guessing is a test
helps in Smprovinz TestCase
suile. 1le:pati.ies Gn learninz ri
and adaab..aty
:
nethod in which test cases Lzploratory Testíng Example:
established based on Ued to find bugs in prozrams are
previous experlence A client
Lrror Guessing is the art and judpment of tester. of Global App Tesling uzes
of zuessing where errors can exploratory teting in a
Android nobile rarníng app. erj pulär
io 2.4
There are no specific be hidden. V/hen this clien: is ready :0
1ools and techniques their application, usually on a releae a nes ersioa cf
depending on the siluation: for this, but you can bi-monthly basis, th.ey call upon
you are testing Either when rcading write test cases from the global crowd to exploratory testers
the functlonal docuInents or functionally explore the app. Testers
and find an error thatyou when will be given general írom arournd the world
Lrror guessing will have not docurnented. scenarios from which to test expected
require tester to think out version. behaviour of the new
andexpericnce of the tester. Error of the box and would involve
intuition For instance, the end user
other test case design guessing techniques are might expect to be able to play
techniques with the applicd in addition to computer player. In doing so, aguinst another hunan or
test conditions. intention of identifying they might need to use tokens or
missing negative iterns before battle. The in-game inventory
e.:if a date ficld has to be tested then some exploratory testing may require a tester to ensure
functionality works and the player can that this
crror gucssing are: of the inputs that could
be derived from complete the battle as expected.
Test automation
31/06/1999 (une has only simply doesn't work for these scenarios.
30 days in a month). While a script could ensure
that tokens or inventory items are
29/02/2003 (2003 is not a leap year). battle! This is the inherent
purchasable, it can't enulate a human dotng
o
00/00/0000. human aspect of exploratory testing.
Lrploratory testing in Agile
In error guessing, testers can think development:
of situations
where software Exploratory testing is commonly
Testers think likca hacker will fail. used by teams following Agile methodology. Agile
following experience, development places emphasis on collaboration
Intuition and hunchos and responding to change, and this
For example, testing approach rclies heavily on
these features.
Division by zero.
soltware testers are encouraged to frecstyle
Pressing submit button on form without illing any in their approach, playing around with
ne product as part of the testing process.
cntries. This combination of simultaneous learning
Entering wrong data in the fields and checking software nd testing is incredibly well-suited to an Agile-based team, but might not tit a
bbehaviour.
traditional software
development team.
 -
ST & QA MCA
(Mgt.) : Sem IlIl
4.24
Sum nary Oynamic
Testrg
Dynamic Testing a sT& QA - MCA (Mgt.) :
Sem ||
4.25
is kind
behaviour of software testing Dynamic Testing
of the code is analysed. technique using Check Your Understanding
which the dyna
BlackBox Testing 4
Techniques : Equivalence which of the following are
Decision Table experience-based techniques?
Testing, State Partitioning. Boundary (a) Error guessing
Value Analyei.
Equivalence partitioning Transition Testing.
(b) Equivalent
(c) Explorat cesting partitioning
program into is a testing method (d) Both (a) and (c)
that divides the input (e) All of 'ne above
classes of data from domain of .
Boundary value which test cases can In whi a of the following
analysis (BVA) is a be derived. techniques, experience
equivalence partitioning. test case design (a) rror guessing of tester is beneficial?
technique that complements
(b) Exploratory testing
Decision Table Testing :
It is a
the cases (input conditions) software test design technique that
(c) Both (a) and (b)
and effects (output conditions), involves identifying (d) None as
there is no
Graph, and generating relationship between techniques
test cases accordingly. producing a Cause-Effect a tester. applied and experience
of
State Transition Testing 3. Which of the following
is used where some is/are characteristic of Exploratory
what is called a 'finite aspect of the system (a) Minimum testing?
state machine'. can be described in planning and maxinum execution
White Box Testing (b) Formal
testing techniques are also used
is software
and coding of software are testing technique in which internal structure, (c) Test design
and test execution are done
tested to verify flow design
(a) Useful in situations in parallel
design, usability and of input-output and to improve with poor specification
security. (e) All of the above and limited time
Statement coverage :
Testing performed 4. "For
once. where every statement effective testing, variety
is executed at least of techniques should be used
True or False in combination".
Branch coverage is
determined by assessing (a) True*
exercised by the set of proposed the proportion (b) False
test cases. of decision branches 5. Error guessing can be have more
Path coverage isdetermined fruitful results when
by assessing the proportion (a) System has been
deployed
program exercised by of execution paths through a (b) When testing
the set of proposed test cases. with inexperience tester
Code complexity a
testing is methodto determine (c) As a first approach
howthoroughly a of testing
be tested. program should (d) Asa additional
technique after applying more formal
6. Cyclomatic complexity techniques
Dataflow testing is white-box testing technique
a
is
that examines the data (a)
White box testing
respect to the variables used in the code. It examines flow with (b) Black box testing
the initialization (c)
Grey box testing
and checkstheir values at each instance. of variables (d) All of the above
7. Which of the following is not
Mutation testing is white box testing approach of generating another name of white box testing?
test-data that requires (a) Structural testing
knowledge of code structure, but it is classified as afault-based (b) Behavioral testing
testing (c) Glass box
approach. testing (d) None of the mentioned
Experience based techniques is the technique of executing 8.
testing activities Which of the following is not a
years. valid software testing technique?
help of experience gained through several with the
(a) Inspections (b) Data flow analysis
(c) Error guessing (d) Walkthrough
 ST & QA - MCA (Mgt.) : Sem
ll 4.26
9. Which of Dynamic
thefollowing testing is refers to asa Testirg
(a) Stress fault-based testing technioies
testing
(c) Beta (b) Mutation testing
testing
(d) Unit testing
(e) Walkthrough
10. Which of the
below testing is implemented
(a) Static Testing initially?
5...
(b) Black-box
(c) White-box
Testing
(d) Dynamic
Testing
Testing Test Management
ANSWERS
1. (d)
2.(c) 3. (e)
9. (b)
4. (b) s. (d) 6. (a) Objectives...
10. (a) 7. (b) 8.(c)
To learn about the Test Management.
Practice Questions Toknow about Test
Organization, Test Planning,
To get information Test Monitoring
Q.I Answer of Configuration Management- and Test Control.
the following
questions in short. To study
about the Risk and Testing. Project Risk and Product
Risk.
1.
Which are Black
box testing techniques? To learn about the
Incident/Defect Management.
2. Which are
Experience based techniques?
3. How to
calculate statement coverage
4
What is Boundary in software testing? 5.1 INTRODUCTION
Value Analysis? • Test
5. What is meant management is a process
by Cause Effect Testing? execution, monitoring, of managing testing activities,
Q.I Answer the following and controlling activities. such as planning,
questions. The purpose of
this process is to arrange tasks
1. Explain the various
types is best suited
for which that are imperative and to analyze
Write difference between of white box testing.
task. who
2. The process
black box testing of test management can be
3. What is meant and white box testing managerment tools. carried out with the assistance
by exploratory testing? techniques. of test
4. Write difference
between Statement coverage 5.2 TEST ORGANIZATION - ROLES & SKILLS
5. Explain
in brief Data flow testing. and Path coverage. TEST MANAGER OF TESTER,TEST LEAD,
Q.III Write a
short note on: Test Organization
in Software Testing is a procedure
1 State transition testing process. It of defining roles in the testing
defines who is responsible for
2. Path coverage explains test functions, which activities in testing process.
facilities It also
Roles & Skills and activities.
3. Mutation testing of Software Testing Team:
4 Error guessing Every organization has its own team structure,
to be filled either by but there are a few positions that need
5. Exploratory testing role or responsibility. These positions are
testing teams because they cover critical to the success of
different aspects of the testing process.
d QA Engineer: This position
generally covers more than testing processes. A
quality assurance engineer constantly software
monitors each and every phase of the software
development process and makes sure
that the developed software meets quality

(5.1)
 ST& OA - MCA (Mgt.) :
Sem l 5.2
TestManageme
standards. Additionally,
they make sure that the software products ST& QA MCA (Mgt.)
:
Scm I!
ithouterors before they are pushed into production. work seamleesk 5.3
Tost Managomont
2. Test Managcr: test manager
A
acts as a project manager. This a the software product.
withín the QA or test team, is management testing process. Estimate,
for custom software tpositra
which is very common
organízations. Design the prioritize, plan,
outsourdrg Recruit and
3. Test Engineer: This automatcd testíing and coordinate
is generally used as an supervise the team.
can refer to many umbrella term to cover many processes and quality testing
engincers specialized in capabiliti . Communicate
testing, exploratory testing, various testing approaches, as ma. create activitics.
performance testing, etc such across
testing position that minimally It is also widely used to infor documentation.
departments. Create detailcd
relies on automation. Sclect and use the
4. Test Analyst: This a and well.
is position that,
business problems. Test rather than being more technical, tooling. structured test
analysts ensure the functional focucor
acceptable before it is readiness of the application i. plans and test
pushed into production.
troubleshoot tests to They generally design, Cases.
catch any defects or errors develop, run, and
-
environments. in the code in pre-production Create status
5. Test Automation
Engineer: This is a widely reports and defect
representing an engincer spread position among report.
who codes (most likely a developer), enterprises Create the strategy
automating test processes. but whose sole focus is on Develop scripts to
These people use for testing the Evaluatc and
Cucumber, or others to testing framneworks such as Selenium. run automated
effectively design product. observe the
advantage of test automation and write new test cases. tests.
engineers is that they are Another great Core Functions - product manually
software testing. well versed Manage the testing Design automated
in GUIdesign and to make sure it
process and
tests to streamline
5.2.1 Core Functions, Skills, workflow within the testing
doesn't go to
and Responsibilities production with
Software Testing of Roles in the team. process. any defects.
The software tester's Comprehensive
role in a project is utilized
depending on the size differently in different knowledge about
of the organizations
requirements of the organization.testing team, structure of the team, and specific testing strategies,
Comprehensive
Comprehensive knowledge about
Software testing job
titles or positions are typically Manualand knowledge about
the technology they use, called manual testing
the business domain they are "QA" or "test engincer", but automated testing Devops and agile
even the type in, the expertise methodologies.
of testing they make will differ. they have, or Required Skills knowledge. methodologies.
In the table below, you can Ability to
review a summary Ability to Coding skills.
required overall skills, of the core functions, responsibilities, understand the
and knowledge of required understand and -
testing roles. tools of some common Analytical skills. clients'
software
Table 5.1: Summary communicate both Problem-solving requirements.
of Software Testing Team - Roles/Responsibilities with the internal skills. Data analysis
Roles Test Automation team and also with skills.
Test Manager
Engineer QA Engineer
the client.
Set suCcess and Write, run, Automation tools
and Do the
Responsibilities quality metrics for monitor the and frameworks. Test management
product. automated test requirement |Tools
Management tools . Observability tools.
-
Plan and execute suites for the analysis for -
tools. Debugging tools
manual tests.
CI/CD tools
 ST& OA MCA
(Mgt.): Sem I!
5.4
Test Hanagemen
5.2.2 Test Lead- Roles
and Skills sT& QA MCA(Mgt.) : Sem I!
5.5
Responsibilities of Test leaders tend to include .dantify and plan necessary Test Management
monitoring, and control involvement in skils development within their test team.
At the outset of the of the testing activities
and tasks. the planning, nnse a
business case tor test
project, test leaders, activities which outlines
devise the test objectives, in collaboration expected. the costs and henefte
organizational test policies, with theother stakehold. Eoeure proper
They estimate the test strategies and test communication within
testing to be done plans stakeholders. the test team and with
necessary resources. and negotiate with management other proiect
to acquire th. .Participate in and lead test process improvement
They recognize when initiatives.
test
select the tools, and ensureautomation is appropriate and, if it is, aTEsT PLANNING- TEST PLAN AS PER IEEE
training of the team. they plan the effor
such as programmers They may consult PLAN TEMPLATE 829 STANDARD TEST
They lead, guide -to help them with their testing. with other grouns
and monitor The test plan is a
the test cases, test procedures the analysis, design, implementation document describing
the activities and the testing scope.
They ensure proper and test suites. and execution of basic requirement any
for testing It is the
configuration management TEEE software product.
traceability of the tests to 829 is a standard
of the testware for software testing by
As test execution comes near, the test basis. produced and Electronics Engineers the Institute of Electrical
((EEE). It specifies and
they make sure the test documentation at each stage. all the stages of software
before test execution environmnent is put IEEE 829 defines testing and
They schedule the tests and managed during test into place the standards for software
execution. and citations. analysis
report on the test progress, for execution and then they monitor, measure, JEEE 829
standard TEST PLAN TEMPLATE
the test plan and compensating the product quality status control and /2014/03/ieee-829.pdf) (https://jmpovedar.files.wordpress.com
as needed to and the test results, adapting
During test execution adjust to evolving conditions. Sections of IEEE 829 Test Plan:
and as the project winds
test status. down, they write summary According to IEEE
829 test
Sometimes test leaders wear reports on plan standard, following
testing plan: sections goes into creating a
Alternatively, the test different titles, such as test
leader role may wind up manager or test 1 Test Plan Identifier:
coordinator.
development manager or assigned to a project manager, •
Test Plan Identifier, unigquely identifies
a quality assurance a
expect them to manager. Whoever project and, in the test plan. It contains information on
plan, monitor and control is playing the role, certain cases, version information. the
Along with the test the testing work.
identifier convention in some Companies may employ a test
leaders
projects, although most testers should also be included from instances. The type of test plan
plan is also included in the
testers until the test of the time the project the beginning of the test plan identification.
execution period. So, now we doesn't need a full complement of Preferably the test plan
will see testers responsibilities. level will be the same as
5.2.3 Test Manager- Roles and Skills number may also identify the related software level. The
whether the test plan is a Master
Test Manager manages integration plan or whichever plan, a Level plan, an
a testing project plan level it represents. This is to
by implementing software and testware versions assist in coordinating
testing processes established the mission, goals and within configuration management.
for the
Organize and lead risk identificationtesting organization. test plans are like
other software documentation, they are
Keep in mind that
such sessions for test estimation, and risk analysis sessions and use must be kept up dynamic in nature and
planning, monitoring the results of todate. Therefore, they will have revision numbers. You may want
Create and implement test plans consistent and control lnclude author and contact to
with information including the revision
strategies. organizational part of either the identifier history information as
policies and test
2.
section of as part of the introduction.
Continuously monitor and control the test activities References:
Assess and report relevant and timely test status to achieve project ASt all documents
t to project objectives.
stakeholders.
that support this test plan. Refer to the actual
version/release
Identify skills and resource gaps in their test umber of the document as stored in
team and the configuration management system. Do
adequate resources. participate
in sourcing upicate the text from other documents as n0t
this will reduce the viability of this
dOcument and increase
the maintenance effort.
 ST& QA - MCA (Mgt.) : Sem Il 5.6 TesttManagemert
Documents that can be referenced include:
- :
er& QA MCA (Mgt.) Sem u
5.7
o
Project Plan
o Requirements
ao are some
inhercnt sottware risks
such as complexity:
Test Management
specifications identified. these need to he
o High Level design
documnent Safety
Detail design document o Multiple interfaces
Development and Test process standards o Impacts on Client
Methodology guidelines and examples Government regulations and rules
Corporate standards and guidelines Amisunderstanding of
the original requirements is
3. Introduction: etr at the management, user another key area of risk. This can
and developer levels. Be aware
State the purpose of the Plan, possibly and requirements that cannot be tested. unclear requirements
identifying the level of the plan (master ete) The past history
This is essentially the executive summary of defects (bugs) discovered during
part of the plan. ootential areas within
You may want to include any the software that are risky.
Unit testing will help
identify
references to other plans, documents
contain information relevant to or.items that
this project/process. If preferable, you can
large number
of defects or a tendency towards If the unit testing discovered a
references section to contain all create a software, this is an defects in a particular area
reference documents. indication of potential future of the
Identify the Scope of the plan in relation ie the nature problems.
to the Software Project of defects to cluster and
Other items may include, resource plan that it relates to. it will most likely bunch together. If it was
continue to be defect prone. defect riddern earlier.
and budget constraints, scope risks are is to have One
how testing relates to other
evaluation activities (Analysis &
of the testing effort. several brainstorming sessions. good approach to define where the
the process to be used for change control Reviews), and possible 6. Features To Be
Tested:
and communication and coordination , This a
activities. As this is the "Executive of key is listing
Summary" keep information of what is to be tested from
4. Test Items (Functions): brief and to the point. does. This is not a the USER'S viewpoint of what
technical description of the system
These are things to test functions. Set the level the software, but a user's view
within the scope of this test of risk for each feature. of the
will test, a list of what is to plan. Essentially, something you Use a simple
be tested. This can be developed rating scale such as (H, M, L):
application inventories as well as from the software levels are understandable High, Medium and Lov. These
to a User. You should types of
This can be controlled other sources of documentation be prepared to discuss why a
and defined
and information. particular level was chosen.
process you by your local Configuration Management
if have one. This information (CM) It should be noted
includes version numbers, that Section 4 and Section 6 are very
requirements where needed, configuration difference is the point similar. The only true
(especially if multiple of view. Section 4 is a technical type
supported). It may also include versions of the product are version numbers description including
key delivery schedule
issues for critical elements.
and other technical information
Remember, what you are viewpoint. and Section 6 is from the User's
section can be oriented testing is what you intend to deliver to the Client. Users do not
to the This understand technical software terminology:
application or functional area, level of the test plan. For higher levels, may and processes as they understand functions
for lower levels it may be program, it be by they relate to their jobs.
build. by unit, 7. Features
module or Not To Be Tested:
5. Software Risk Issues: Ihis is a listing of what is NOT to
Identify what software be tested from both the Users viewpoint
is to be tested and System does and a of what the
Delivery of a third party product. what the critical areas are, configuration managemnent/version control
such as: technical description view. This is not a
New version of interfacing software
of the software, but a USERS View of the functions.
laentity WHY.the feature is not
Ability to use and understarnd a new to be tested, there can be any number
package/tool, etc.
Reasons may of reasons.
be:
Extremely complex functions. o Not to be included
Modifications to components in this release of the Software.
with a past history of failure. O Low risk has been
used before and is considered
Poorly documented modules or stable.
change requests, wu be released but not tested or documented as a
of this version functional part of
therelease
of the software.
 ST &QA - MCA
(Mgt.) : Sem ill
5.8
Sections 6 Test Managemen
and7 are directly related
tested is directly to
affected by the levels Sections 5 and 17. What will
:
er& OA MCA (Mgt.) Sem l
-

does not get tested and will no 5.9

affects the level of acceptable risk within the project, Test Management
8. Approach of risk and 12. Testing Tasks:
(Strategy): of the project. wh..
These areas need to be identified to
In section, approach for
this avoid any confusion
will be performed. testing will be defined. reported back on those future functions. and should defccts
It contains It contains details This will also allow be
outputs, testing information of of how testina
avoid incomplete functions and prevent the users andtesters
techniques and priorities. the sources waste of resources to
requirements analysis, The approach of test data, inputs an the project is being developed as a chasing non-defects. If
will define the guidelines multi-party process,
execute test cases. develop scenarios, portion of the total functions/features. this plan may
derive acceptance for
ctatus needs to only cover a
9
Item Pass/Fail criteria, construct and be identified so
Criteria: tamand to avoid
that those other areas have
This section wasting resources tracking plans developed for
explains urben a third party defects that do not relate
specifies the success how to evaluate the test is developing the to this plan.
criteria for each functionality results using success criteria, It fohose test tasks belonging software, this section may contain
It can be general to be tested great to both the i. descriptions
A defect is functional requirements for in detail. Creating test scenarios, ernal groups and the external groups.
something that may cause higher level plans. test cases, test scripts,
application. A failure a failure, and may be and creatingan issue log are executing test cases, reporting
etc. It is impossible is the result of a defect as seen acceptable to leave all examples of testing tasks. defects,
to detect all defects. by the User, the system in the 13, Environmental
Needs:
The completion crashes. This section
describes the requirements
criteria
appropriate to the level of plan is a critical aspect of any software or any for test environment. It
includes hardware.
of the plan. At test plan and should other environmental requirement
All test cases
completed.
the Unit test level this could be items
be identify for testing. The plan
such as: what test equipment is already present and should
A specified percentage
cases completed 14. Staffing
and Training Needs: what needs to be procured.
number of minor defects.of with a percentage Training on the
Code coverage tool containing some application/system. Training
At the Master test plan indicates all code covered. describes the for any test tools to be
All lower level
level this could be items such as: training needs of the used. This section
plans completed. activities successfully.
staff for carrying out the
A Specified planned testing
number
minor defects. This of plans completed without errors a
15. Responsibilities:
.
could and
plan or it can be general be an individual test case level criterion percentage with In this section
of the test plan, roles and responsibilities
10. Suspension Criteria functional requirements or a unit level team. are assigned to
and Resumption for higher level plans. the testing
It willdescribe any Requirements: 16. Schedule:
criteria that may result
subsequently the requirements in suspending Schedule should
11. Test Deliverables:
to resume the testing process.the testing activities and be based on realistic
and validated estimates. If
development of the estimates for the
The documents the application are inaccurate,
that the testing team will testing will slip. The the entire project plan as
give at the end of the schedule is well as
known as test deliverables. testing process are schedule shall be
created by assigning dates to
testing activities. This
What is to be delivered as part in agreement with the
plan development schedule to make a realistic
of this plan? test
Test plan document. 17.
Planning Risks
Test cases. and Contingencies:
1s very
Test design specifications. important to identify the risks, likelihood
also contain and impact of risks. Test plan shall
Tools andtheiroutputs. mitigation techniques for
included in the identified risks. Contingencies
Simulators. the test shall also be
18. Approvals: plan.
Static anddynamic generators.
Error logs and execution logs. Inis section contains
19,Glossary: the signature of approval from
Problem reports and corrective actions. stakeholders.
Glossary
used to define terms
3eneral, to eliminate and acronyms used in thedocument, and testing in
confusion and promote consistent
communications.
 ST & QA - MCA (Mgt.) : Sem ill 5.10
TestManagemerg
: tn
5.4 TEST PROCESS MONITORING $T& QA- MCA (Mgt.) Sem 5.11
AND CONTROL Test Management
Test Monitoring and Test Control
is basically a management
Ideally the test log
naming convention should follow
Test Monitoring is a process of activity. testware it is related to. This is to assist the same general rules as
evaluating and providing feedback on in cOordinating the
in progress" testing phase. the "currently versions within contiguration management. software and testware
Test Control is an activity Unique "short" name for the log.
of guiding and taking corrective Version date and version number of log.
metrics or information to improve action based on sor
efficiency and quality. Description:
5.4.1 Test Monitoring through
Test Log (IEEE 289: Items being tested and any
report template to be discussed) Test summany supporting reference materials
Case Specification
The purpose of test monitoring and Defect Density
is to give feedback Procedure specification
which can be used for initiating and visibility about test activitiee Transmittal report
Relevant Test Metrics to correctiye and preventive
action. Date & time
be tracked:
Test Coverage o Executed by
Test Execution
Metrics- Number of test cases Tester
blocked, or are on hold. that have passed, failed, been Observer
Defect Metrics o
Environment
The cost of the project so
far. Especially any variances
Resources consumed from the planned test environment.
by
Status of each task-on the project so far. Activity and Event Entries:
schedule, lagging or
Requirement Traceability ahead of schedule. o Date/time
Test artifacts and Beginning of each significant
deliverables are an activity
artifacts offer various integral part of software End of each activity
benefits testing life cycle. Test
transfer andsharing experiencesto the testing team such as enabling Execution description
with various teamn members, knowledge
clients for improvement, management, and Procedure executed (reference to
to reducing distractions. its location)
which is created during Test log is a type Personnel present at test
test execution. of test artifact
5.4.1:1 Test Log Tester, developer, observer
It provides detailed Reason for each persons presence
information regarding
validate the quality, the success of each test o
Procedure results
performance, & functionality performed to
It also includes all
the script routines, keyword of the software. For each execution, log
all relevant information
the results of test operations tests, low-level
procedures. It contains
in each test. It can also Error messages, aborts, interventions
applications, links to files, include images Location of outputs
and other entries. of the tested
A test log shall
have the following structure: Result status (success, failure,
(1) Test-log identifier o unknown)
Environmental information
(2) Description
Any changes or substitutions
(3) Activity and event from requested environment
entries o
Anomalous Events
(1) Test-log Identifier:
Record events before and
Some type of unique company
generated number identify after an anomaly
the level of software that it is related to. to this test log, Any special situations
Preferably the test its level and
as the related test case or log level will be Power interruptions, etc.
procedure level. the same Incident reports
Report on each unexpected result or variance
from expected output
 ST & QA - MCA (Agt.) : Sem
Il 5.12
Test Managemet
S.4.1.2 Defect Density sT& QA• MCA(Mgt.)
: Sem l!
5.13
It is one of
the software testing metrics. Defect density helps Test Management
the team in determining Exarmple:functionality verification which
A

the total number of defects found application cannot be tested, as needs connectivity
in software during a specific the connectivity could not to a third party
operation or development. The results are period of t: P
then divided by the size of that limitations. This section be established due
to some
module, which allows the team to particulat should be clearly documented;
decide whether the software sceumed that Testing covered else it yill be
or whether it requires more is ready for the rol all areas of the application.
testing. i. In Scope:
Defect density is counted per
thousand lines of code also Eunctional Testing
used for this is: known as KLOC. The for the folowing modules are
forml Registration in Scope of Testing:
Defect Density = Defect Count/Size
Example: For a particular of the Release/Module ii. Booking
test cycle there are 30 ii. Payment
components). The density would be: defects in S modules (nr
ii. Out of Scope:
Total no. of defects/Total no.
Testing for defects during of modules = 30/5 =6. DD per Performance Testing was not
module is 6. done for thisapplication.
the development of your
rate of the software software will predict iii. Items not tested:
released on the market. the defect
testing, it means there was If the defect density is Verification of connectivity
high during
development of your app.
likely a high rate
of errors occurring during the System' was not tested, as with the third party system 'Central Repository
some technical the connectivity could not
be established due to
S.4.2 Reporting Test limitations. This can be
Status (IEEE 829 TEST SUMMARY Testing) where the connectivity verified during UAT (User
TEMPLATE to REPORT is available or can be established. Acceptance
be discussed) 4. Metrics:
(https://www.softwaretestinghelp.com/wp-content/qa/uploads/2014/06/Sample-Test .
Metrics will help to
Summary-Report-by-SoftwareTestingHelp.pd) understand
the test
execution results, status
defects etc. Required of test cases &
A test summary report a Metrics can be added as necessary.
is Quality work product Example: Defect Summary ·
summarizes the results
of all testing. The Lead or/
Test document Severity wise; Defect Distribution -
that formally wise; Defect Ageing
etc. Function / Module
document at end Test Manager prepares Charts / Graphs can be
STLC/SOftware
of the Testing, means this representation. attached for better visual
in Test Closure
Test Process). phase (Last phase in i. No. of test cases
A typical Test Report
Template will contain
planned vs executed
1. Purpose: the below information: i. No. of test cases
passed/failed
This document explains Test cases
the various activities Test cases Test cases
Transport System' application. performed as part Planned Test cases
of Testing of 'ABCD Executed Passed
2. Application Overview: 80
Failed
'ABCD Transport 75 70
System' is a web-based
various buses can Bus ticket booking
be booked using application. Tickets TCs Fail
information is received the online facilities. for
from a 'Central repository Real time passenger 17% TCs Pass
before booking is system', 93%
confirmed. There are which will be referred
Payment and Reports several modules like
which are integrated to Registration, Booking.
3. Testing Scope: fulfill the purpose.
Thissection explains
about
Anvitems which are not the functions/modules in scope & out scope
of
tested due to any constraints/dependencies/restrictions.for testing:

Fig. S.2: Test Cases Pass vs Test Cases Fail

 ST & QA -NCA (Mgt.) :
Sem il 5.14 Test Managemert
iii. No of defects identified er& OA- MCA (Mgt.)
: Sem I)
and their Status & Severity: 5.15
Test tlanagement
Critical Major Medium s Types of Testing Performed:
Closed Cosmetic Total
25 15 20 This section describesthe various types of Testing performed
Open 60 sure the application is being tested for the Project. This will
properly throtesting types agreed as per
5 Test Strategy.
65 . Smoke Testing:
Defects Severity and Status This testing was done
25 whenever a Build is received

L
environment) for testing to (deployed into Test
make sure the major functionalities are
20 fine, Build can be accepted and Testing can working
start.
i. System Integration Testing:
15 This is the Testing performed on
the Application under test, to verify
D
Cosed entire application works as per the the
requirements.
10 Critical Business scenarios were
Open tested to make sure important functionalities
in the application works as intended
without any errors.
5
iii. Regression Testing:
Regression testing was performed
each time a new build is deployed
testing which contains defect fixes for
Cntical Major Modium Cosmotic
and new enhancements, if any.
Regression Testing is being done on
the entire application and not just the new
Fig, 5.3: Graph of Defects
Severity and Status functionalities and Defect fixes.
iv. Defects distribution - Modulewise: This testing ensures that existing
functionalities works fine after defect fix
and new enhancements are
added to the existing application.
Registration Booking
Payment Reports Test cases for new functionalities are
Critical 6 Total added to the existing test cases and
Major 7 25 executed.
2 6. Test Environment & Tools:
Medium 6 15
2 This section
Cosmetic 1
4 20 provides details on Test Environment in which
2 the Testing is carried out.
1 Server, Database,Application URL etc. If any Tools were used like Quality
Total 17 Center (now
22 10 HP ALM)
16 65
for logging defects.
25%
Application URL http://abcd.2345.com
26% Apps Server 192.168.0x.22
URegistration
Database Oracle 12g
DBooking
HP QC/ALM 192.168.X0.22
Paymont 1.
344 Lessons
Learnt:
IReporls
nis section is used to describe the critical issues faced and their solutions (how
they
oved during the Testing). Lessons learnt will help to make proactive decisions
Fig. 5.4: Defects Distribution-Module Wise during the next
Testing engagenent, by avoiding these mistakes or finding asuitable
workaround.
 ST & QA MCA (Ag.) :
Sem Ill 5.16
TostManagemes
Sr. No. : Sem I!
sf& QA HCA(Mgt.)
-
Issues faced 5.17
1 Smoke testing test cases
be executed manually each
Solutions
required to Smoke test cases were
automated a
. Conclusion/Sign off:
Test Management

time. the scripts were run, This section will mention whether
the Testing team agrees and gives a
which ran fast Abe application to 'Go Live' or not,
and saved time. Green
2. after the Exit Criteria was met. signal
Initially, Few testers were not application does not meet the Exit Criteria, If the
Rights were obtained then it can be mentioned as
having rights to change defect from Client, by application is not suggested to "The
explaining the difficulty. 'Go Live'. In this scenario, It will be
status in HP QC/ALM. Test Jaision of Senior Management and Client and other left with the
lead Stakeholders involved to take
need to perform this task. he call on whether the application can 'Go Live' or not.
8. Recommendations: abo Fxit criteria was
Inet and satistied as mentioned
ie suggested in Section 10, this application
Any workaround or suggestions can to 'Go Live' by the Testing team.
be mentioned here. Appropriate User/Business acceptance
testing should be performed before 'Go Live'.
Admin control for defect management
lead/manager for providing access to tool can be given to 12. Definitions,
Acronyms, and Abbreviations:
Testing team. ffshore Test rhicsection mentions
Each time the onsite Admin the meanings of Abbreviated terms used
need not be contacted for requests any other new in this document and
arise, thereby saving time due to whenever they definitions.
the geographical time zone difference.
9. Best Practices: S.4.3 Test Control
There will be lot of activities Test Control occurs based on
done by the Testing team the results of Test Monitoring. It refers to taking
them could have. saved time, some during the project. Some of corrective action based on test
proved to be a good & efficient way monitoring reports to improve quality
These can be documented as a to work,etc. Some examples of test control and efficiency.
'Value Add' to show case to activities would be:
Example: A repetitive task done the Stakeholders. o
Prioritize testing efforts in adifferent way.
manually every time was time
was automated consuming. This task o
Reorganize test schedules and deadlines.
by creating scripts and run
each time, which saved
resources. time and o
Restructure the test environment.
Smoke test cases were automated o
Reprioritize the test case and conditions.
and the scripts were run, which ran
saved time. fast and Test Control is essentially
modifying the testing process so that it becomes better
Automation scripts were prepared to create new suited for meeting the defined objectives.
customers, where a lot records This may require adding extra resources,
need to be created for Testing. of reducing the scope of release, or splitting the
release into multiple releases, etc.
Business critical scenarios are Obviously, what specific test control
separately tested on the entire activities will be implernented depends on a
are vital to certify they work fine. applications which variety of factors - stakeholders' opinions, budget,
project complexity. availability of
10. Exit Criteria: testers, and the like.
Exit Criteria is defined asa Completion of Test Control goes hand-in-hand
Testing by fulfilling certain with Test Monitoring. Obviously, once Monitoring
conditions. Identifies any bottlenecks that may prevent a test cycle
Alltest cases should be executed- Yes from meeting its goals,
Control activities will have to come into play to ensure
Aldefects in Critical, Major, Medium severity should otherWise.
o Ány open be verified and closed - Yes.
defects in trivial severity - Action plan D.5 REQUIREMENT TRACEABILITY MATRIX (HORIZONTAL &
prepared with expected dates
of closure. VERTICAL)
Example: No Severity1 defects should be 'OPEN"; Only 2 Severity2
defects should
be 'OPEN; Only 4 Severity3 defects should be 'OPEN' Airaceability Matrix (TM) is a document that correlates any two baselined documents
may which
Note: This vary from project to project. Plan require a many-to-many relationship comparison, checking the completeness
of Action for the Onen defects
should be clearly mentioned with details on when S how they will of said relationship.
be addressed A Requirement
and closed. Traceability Matrix(RTM) may be used check the current project
to if
Tequirements are of a request for proposal,
being met, and to help in the creation
 ST & QA - MCA (Mgt.) : Sem
ll 5.18
TestManagement
11
software requirements specification, various deliverable sT& QA- MCA (Mgt.) : Sem
documents, and 5.19
tasks. project plan st
Management
A
requirement traceability matrix has four basic
his wilI have multiple test cases as stated below:
components: Requirement Pavment method to be used: PayPal,
Identifier, Requirement Summary Text, Test Paytm, GPay, Credit/Debit Card.
Case ldentifier, and Test Case i) The payment done is success ful.
Vertical Traceability Matrix: Stat.
There is verticaltraceability i) Payment done is unsuccessful.
matrix which showS relationships liv) The payment process aborted in between.
and horizontal traceability between requiremens.
matrix which displays v) Not able to access payment methods.
requirements andtest cases. relationships betweas
ui) The application breaks down in between.
Vertical Traceability matrix
is high level document Scenario Testing :
requirements to all phases which map
of the Software developrment cycle. the nnarioTesting in software
Component Integration testing, i.e. Unit testing testing is a method in which
System Integration testing, Be testing the software actual scenarios are used
System testing, Acceptance Smoke/Sanity testing application instead of test cases.
testing etc. bing js to test end to end The purpose of scenario
Vertical traceability is scenarios for a specific complex
registered from the textual
related to the bidirectional
trace that could be
Scenarios help in an
easier way to test and evaluate end to problem of the software.
requirements, going through Procedure to write Test Scenarios: end complicated problems.
requirements and at last to graphical functional
the phases of the software development Ás a tester, you can
like design coding, testing lifecycle follow these five steps to create Test
and so on. Step 1: Read the Requirement Scenarios:
Horizontal Traceability Documents like BRS, SRS, FRS, of
Matrix: Test (SUT), You the System Under
Horizontal Traceability could alsO refer uses cases, books,
matrix is used for Coverage to be tested. manuals, etc. of the application
requirement changed it will analysis when a
used to identify the Test cases o Step
requirement. prepared on that 2: For each requirement,
figure out possible users actions
Horizontal traceability Determine the technical aspects and objectives.
is related to the bidirectional of the requirement. Establish possible
could be registered from trace that of system abuse and evaluate users scenarios
the graphical with hacker's mindset.
architectural policies or mechanisms non-functional requirements or even the o Step 3:
After reading the Requirements
to the architectural Document and doing your due Analysis,
at last the design phase. integration model and list out different test scenarios
that verify each feature of the software.
o Step
4: Once you have listed all possible
5.6 TEST SCENARIO, TEST
SUITE,TEST CASES(BOTH created to verify that each & every
Test Scenarios, a Trsceability Matrix is
NEGATIVETEST CASES POSITIVE AND requirement has a corresponding Test Scenario
AS PER IEEE 829) o
Step 5: The scenarios created are
reviewed by your supervisor. Later, they are
5.6.1 Test Scenario reviewed by other Stakeholders
in the project.
also
A Test Scenario Tips to create
Test
is a statement describing Scenarios:
tested. It is used for end-to-end the functionality of Each Test
the application to be Scenario should be tied to a minimum one
testing ofa feature. It is per the Project of Requirement or User Story as
use cases. generally derived from Methodology.
the
The quality of the software can Betore creating a Test
Scenario that verifies multiple Requirements at once, ensure
be improved by having a good you have a
scenarios. foundation for test Test Scenario that checks that requirement
AYOld
in isolation.
Test scenarios can serve as creating overly complicated Test Scenarios spanning multiple
the basis for lower-level test case Requirements.
Ihe number of scenarios may
Scenario can cover one or more test cases. Therefore a creation. A single test be large, and it is expensive to run them all. Based on
test scenario CUstomer priorities
only run selected Test Scenarios.
relationship with the test cases. has a one-to-1many
56.2 Test
Example: Suite
Test Scenario: Make the payment for the cab service availed
A testtsuite is a
collection of test cases
15
also known that are grouped for test execution purposes. It
as "validation
suite".
 ST & QA - MCA (Mgt.) : Sem
Il 5.20 Test Management
Test suites can identify gaps a sr& QA- MCA(Mgt.)
: Sem 1 5.21
in testing where the successful Test Management
case must occur before you completion of ona.
begin the next test case. tfoither of the situations in parentheses
Test suites are useful for Build - happens, you have a nepative tect in
verification tests, Functional verification terms of. its result again, not what the test was
tests, End-to-End integration tests, tests sma hoping to find. The
to put negative values, application did
what it was not supposed to do. User tends
Regression tests.
In a test suite, the test cases scripts are
/
test case for registration will precede
organized in a logical order. For examnle
the test case for login.
. the application.
example in Registration Form, for Name field, user
For
which may crash

should be allowed to
5.6.3 Test Case ly alphabets. Here tor Positive Testing.
tester will enter only alphabetsenter
application should run properly and should and
A Test Case isa set of actions executed accept only alphabets.
to verify a particular Testing, in the same case user tries to enter For Negative
of your software application. A Test Case feature or functionality case is executed numbers, special characters
and if the
postcondition developed for specific test contains test steps, test data, precondition successfully, negative testing is successful.
The test case includes specific scenario to verify any requirement. netail on the contents ofa Test Case
variables or conditions, using Format as per IEEE 829
can compare expected which a testing engineer case refers to
bact
and actual results to determine whether a the sequence of actions required to
functioning as per the requirements of software product is Aunctionality. Basically, verify a specific feature or
the customer. the test case specifics the steps, data,
Test Cases for Mobile Phone: conditions necessary to verify a feature. prerequisites, and post
.
Check whether Battery is Test cases specify for cach
inserted into mobile properly. testing requirement:
Check Switch on/Switch The exact input values
offof the Mobile. that will be input and the values of any
is required. standing data that
Insert the SIM into the phone n check.
o The exact
Add one user with name output values and changes
and phone number in the Address book.
expected.
of value of the internal system state that are
Check the Incoming call.
Check the outgoing call.
o
And any special steps
for setting up the tests.
Send/receive messages for that mobile. Defining the expected
values is very important, by doing
Check all the numbers/Characters SDotted. A feature this discrepancies can be
on the phone from the Test Design may be tested more
working fine by clicking on and a Test Case may test more in than one Test Case,
them. than one feature. The aim of a set of test cases is to
Remove the user from each feature
from the Test Design at least once. test
phone book and check removed Standard Test Case
and phone number. properly with name Format:
Check whether Network working
1. Test Case ID
fine. Test case name
5.6.4 The difference between Positive 3. Feature to be tested
and Negative
Test Cases
Positive test cases ensure 4, Test
that users can suite ID
valid datawhereas Negative test cases are pertorm appropriate actions when using S. Priorityy
performed to try to "break"
performing invalid (or unacceptable) actions, or the software by 6. Test environment
by using invalid data.
Positive Testing = (Not showing error 7. Test effort
when not supposed to)
+ (Showing error 8, Test duration
Soifeither of the situations
when supposed to)
9. Precondition
in parentheses nappens, you
of its result - not what the test was hop1ng to have a positive test in terms 10. Test
procedure
nd. The application did what was
supposed to do. Here user tends to put all positive values it 11 Actions
according Input Reqd.
Negative Testing = (Showing error when not supposed to) to requirements. 12 Expected
Result
(Not showing error wheni supposed
+ 13. Actual Results
(ISually these situations crop up during to) est Case
boundy testing or cause-effect testing) Example:
Let's
build a
test case example based on a specific scenario. Here is a sample case.
 ST & OA - IACA (Mgt.): Sem IlI 5.22 Test anagement : Sem lI
sf&QA MCA (Mgt.)
-
Test Case ID: #BSTO01 5.23
Test Management
Test Scenario: To authenticate a successful user
login on Gmail.com retracing the same could become impossible or
Test Steps: expensive in the available
environment. test
1 The user navigates to Gmail.com. Therefore it is important to consider
the software deployment cycle
2. In the 'email' field, in the test
the user enters a registered email address. plan not only regarding software test cycles but
also regarding
3. The user clicks configurations. software test
the 'Next' button.
4. The user enters the registered gelease Notes:
password.
S. The user clicks eally. when testers receive an organized,
'Sign In.' version-controlled test release from a

Prerequisites: A registered Gmail ID with a change-managed SOurce code reposttory.

1t is along with a
unique username and password. RRrt or release notes. [IEEE test item transmittal
Browser: Chrome v 86. Device: 829| provides a useful guideline
Samsung Galaxy Tab S7. eanort. Release notes are not for what goes into such
Test Data: Legitimate username always so formal and do not always contain all
and password. information shown. the
Expected/Intended Results: Once username
redirects to the user's inbox, displaying and password are entered,
and highlighting new emails at
the web page
Actual ResultS: As Expected the top. IEEE 829 STANDARD: TEST
Test Status-Pass/Fail: Pass ITEM TRANSMITTAL
REPORT TEMPLATE
5.7 CONFIGURATION MNAGEMENT -
CONFIGURATION
MANAGEMENT SUPPORT Transmittal report identifier
FOR TESTING
Configuration management deternmines Transmitted items
software or system. These clearly about the items Location
items include source code,
that make up the
software, hardware, data test scripts, third-party Status
and both development and test
Configuration management documentation. Approvals
is also about making sure
carefully, thoroughly and that these items are managed
attentively during the entire
Configuration management project and product life cycle.
has a number of important Fig. 5.5: Realease Note
configuration management implications for testing. Like
allows Advanced planning is very important to make
results using the same configuration the testers to manage their testware and test the project planning
Configuration management. During
management mechanisms. stage and may be as part
Configuration management of test plan make sure that
also supports the build process, configuration management
delivery of a test release which is important for procedures and tools are selected. As
into the test environment. proceeds, the configuration process the project
mail will not be sufficient, Simply sending Zip archives e and mechanisms must be implemented, and
because there are too many by key interfaces to the
archives to become polluted opportunities for such the rest of the development process should 'be
with undesirable contents or to documented.
versions of itemns. Especially
in later phases of testing,
harbor left-over previous 5.8 RISK AND TESTING PROJECT - RISK AND PRODUCT RISK
reliable way of delivering test it is critical to have a solid, Risk can
items that work and are the proper be defii.. •
In most testing projects, version. "the chance of an event, hazard, threat or situation occurring
not only one software version and resulting in
the requirement to manage has to be covered. This implies undesrcble consequences or a potential problem".
various test environments Sottware Testing, Risk: are the possible
corresponding test data, test scripts, test automation and to keep track of problems that might endanger the
frameworks, voectives of the project stakehelders.
defect tracking and more. If configurations It is the possibility of a negative or
are not reporting tools, outcome. A undesirable
managed risk is something not happened yet and it may never happen; it is
update of a test script or test data for a newer well, a necessary a potential thi
software version problem.
an incapability to cover previous
software versions in
could create esofRisk:
For example, after a software testing.
defect occurred in the live software 1 Product Risk
version, retesting or
2 Project Risk
 ST& QA - MCA (Mgt.) :
Sem l! 5.24 Test Managcmerg I
1. Project Risk: - (Mgt.) : Sem
ef&QA MCA 5.25
Test Management
Project risks are uncertain
situations that can impact the o
of Appreciation:
Lack Many employees
its objectives. project's ability to achi.. a don't feel appreciated by
employers. As result, motivation and productivity their
Every Software project oftenlack.
has an objective. It could be d Technical Issues:
website with a defined set building a new eCommer..
of acceptance Requirements not clear: Poor requirements
functional characteristics of the software. criteria. It includes functional and nAs
o

lead to different understandings

Any event that may risk he clients and developrment/testing teams. leads by
classifies as Project Risk. these objectitee to additional defccts
quality issues. and
Testing is part of the project,
a ecbnical Feasibility:The requirements may
like development or product
that will impact the development could management. Any risk There could be technical
not be feasible for implementation.
QA Manager must be aware
have an impact on testing as well. constraints due to which some
As such. the may not meet as expected. of the client requirements
of all the project risks that can have an
It's essential to understand all these risks impact on testing. Environment
and their effect on testing. Readiness: If the Test Environment
Here is the list of the common would lead to delays in is not ready in time. then
it
project risk/issues: testing. Moreover, at times, the
a) Project Issues: test in a development testing team might need to
environment, which could lead to data
Delays in Delivery and Task Data Issues: If there issues.
completion: It is the most common is a delay in Data converSion
where there is a delay in completing project risk .old affect the testing team's ability to test with and Data nigration, then it
the
there isa delay in the story delivery to Development Task for a story. Therefore, movingour website real data. For
the testing team. from one platform to another, it would example, if vIe are
Cost Challenges: Project funds Ifa delay happens in this activity, need data migration.
and resources might get allocated to in the testing environment,
then it would affect
priority projects in the organization. other high testing.
There could also be cost-cutting across an
organization, which could lead to Development Process: Weakness in the development process
reduced funds and resources
will impact testing resources, as well. for the project. It quality of deliverables. It could could impact the
be due to a lack of skill set of
Inaccurate Estimates: When a project could also be due to scrum the architect. It's
begins, then the high-level master not setting up the right processes.
happens according to which allocation resources estimation o Defect Management: Poor
of and funds takes place. These Defect Management by Scrum Master or
estimates likely turn out to be inaccurate Managers could also lead to Project
when actual work starts. It could accumulated defects. Sometimes, the team
delays, quality issues, or cost overruns lead to lower priority defects, which are easy picks up
for both development and testing teams. to fix. It helps them to show up numbers.
b) Organizational Issues: However, the high priority
defects pile up. It leads to a lot of regression
Resource Skillset Issues: It defect reopens might also occur. issues, and
isa vital issue where the skill set of resources
match project needs. The training is doesn't e) Supplier Issues:
also not
lead to quality and on-timne delivery issues. sufficient to bridge that gap. This will Delivery Constraints: A third party
Personnel Issues: This could be HR that is required to supply services or
and people-oriented policies infrastructure is not able to deliver in time. It
organization. It also includes any of the could lead to delays and quality
workplace discrimination issues. For an eCommerce website, a
people. that may affect third party provides images. The site is ready
and tested, but cannot go live as are
Resources Availability: Often, images not ready.
o
business users, subject matter experts, Contractual Issues: Contractual issues with suppliers
developers/testers may not be available or key could also affect the
due to delverable. For example, A supplier comes on contract to fix any
business priorities. It has a cascading impact on all personal
the teams.
issues or conflicting
However, the project team needs to fix P1
defect in 7 days.
defects in 2 days. Here, the contract does
c) Political Issues: iot nappen as per project needs. It leads to delays in delivering the software.
Team Skills: It often happens that Development Managers Product Risk:
don't get along well. It falls down to tne team and Test Managers
and such an environmnent obstructs ioduct risks result from problems with the delivered product. Product Risks
effective test execution. aSsociate with specific quality characteristics
are also of the product. Therefore these rnsks
known as Quality Risks.
 ST & QA - MCA (Mgt.)
: Sem
ll 5.26
Characteristics: Test tManagement
-
er& OA MCA (Mgt.) : Sem
5.27
Functionality as per Test Management
client requirements Indirect Risk: Delay
Reliability of software in the Developrment Story
direct development risk. The Architect or completion can happen. It is a
Performance efficiency swork for its Development
Manager should
mitigation. TheQA raise it
Usability lmnact on testing will Manager can raise a new
happen testing risk that the
OA's impact on it stories don't deliver on
Security of software the risk that Development time. He can also call out
Compatibility should then work on its mitigation as well. Manager has raised. The OA Manager
a cee.
Ease of Maintenance OA Lead Manager
/ need to know all the product/project
may or may not originate in testing. risks. These
Portability However, they
Examples of Product Risks: :orables. The QA Manager should could still impact
test
analyze the impact
Let'ssee some examples plan for its mitigation. of these risks on testing, and
of product risk: Project Management:
Risk
Software doesn't perform some Ae
long as the
risk has not yet oCcurred,
when you place an order on an functions as per specification: For example. risk until the project the project manager can simply
eCommerce website, ends or the risk expires. monitor the
email triggers, but SMS functionality then order confirmation fa known project risk does occur during
Software does not function as per not work.
does nte measures the project, the project manager should
devised during project
intends to buy a product and
user expectations:
For example, planning to lessen negative effects then
user maximize positive effects. and
out of stock and subtracts adds it to his Cart. During checkout, ,Proiect risks can be
from the product goes good or bad for the project.
message to tell the Cart. However, the user is not become even better; With proper planning, they can
him what went wrong. shown any without it, they can become even worse.
Computation Errors: These are common S.9 INCIDENT /DEFECT MANAGEMENT
the correct computational logic issues that a developer has not
written
product, then the discount gets in
code. For example, when a Defect :When
discount applies to a tester finds a mistake or problem
applied to shipping costs as Bug: Bug is developer's then it is referred to as Defect.
A loop structure well. terminology. Once a defect
is coded wrong: For example, a developer found by a tester is accepted by
runs ten times as loop that was to run it is called a bug. The process
the developer has used the condition <= 10 nine times, Bug-Fixing. of rectifying all bugs in the system is called
Response times are high ínstead of < 10.
for critical functions: For example, you are Incident: Incident is an unplanred interruption.
order on a website. The order is successful, placing an activity When the operational status any
and your money deducts. However, turns from working to of
order confirmation screen takes a the failed and causes the system to
behave in an
min to load.This response time is too unplanned manner it is an
Customer. high for a incident. A problem can cause more
which are to be
resolved, preferably as soon as than one incidents
User Experience of the possible.
product doesn't meet customer Incident Management
Process: An incident management process
example, when a user is searching expectations: For is a set of
for a product on a website, he wants procedures and actions
taken to respond to and resolve critical incidents.
out results. For example, Filter =
to filter
with Size Small, Brand = Nike. Color =
However. he cannot select all Black.
these filters at one go. He selects size, page
refreshes. He then selects brand and the
and page again gets refreshed
results. It works as per functional requirements. with updated
However, it leads to poor user
experience.
Types of risks according to testing perspective:
Direct Risk: These are the risks that originate in testing.
For exmaple, Test Lead
not available in the Integration phase is a direct
testing risk. The QA manager
should raise it and work for its mitigation.
 ST& QA- MCA (Mgt.) : Sem lll 5.28
Test anagement - MCA (Mgt.) : Sem
STS
OA 5.29
Incident Test tManagement
Identfication your infected systems, isolate
of
and Logging
COpy the infected components, and
systems to confirm that the infection does not spread. fully replace
[ocident Closure:
6
Closing incidents typically involves finalizing
Incident Classification documentation
and steps taken during response. This evaluation helps
and
cvaluating the
Closure teams identify areas of
Prionitization :
improvementcand proactive rmeasures that can help prevent
ncident closure may also involve future incidents.
providing a report or
administrative teams, board members, or retrospective to
customers. This
301mss tnst that may have been information can help
lost and creates transparency
operations. regarding your
Resolution
and Recovery
Investgation
and Analysis 59.1 Defect Life Cycle
Defect life cycle, also known as Bug Life cycle
foct goes through during its lifetime. It varies is the journey of a defect cycle, which a
Fig. 5.6: 1ncident Management Process
from organization to organization
Five Essential Steps od from project to project as it is
also
of Incident Management Process: governed by the software testing process
1. Incident Identification and Logging: also depends upon the tools used. and
Incidents are detected through analyses,
reports, or manually. Once Defect Life Cycle
-
Workflow:
detected, the incident is logged and identified /
investigation and categorization can
2. Classification begin.
and Prioritization:
Classification is important to determining New
how incidents should be handled
prioritizing response resources. and for
The priority of an incident can
be determined as a function
The impact of an incident of its impact and urgency. Assign
denotes the degree of damage
user or business. The urgency the issue will cause to the
of an incident indicates the time
incident should be resolved. within which the Rejected
3. Investigation and
Analysis: Active
Once incident tasks are
assigned, staff can begin
possible solutions for an investigating the type, cause,
incident. After an incident and
the appropriate remediation steps. is analysed, you can Deferred
determine
customers, or authorities This includes notifying any Reopened
relevant staff, Test
about the incident and any
4. Resolution and Recover expected disruption services.
of
Resolution and recovery
involve eliminating
restoring systems to full threats or root causes
functioning. Depending on of issues and Verified
may require multiple stages incident type or severity,
to ensure this
that incidents reoccur.
For example.
if the incident involves a malware don't
delete the malicious files infection, you often cannot
and continue operations. simply
Instead, you need to create a Closed
clean
Fig. 5.7: Defect Life Cycle Workflow
 ST& OA - MCA (Ugt.) : Sem ID 5.30 Test Mansgement
- (Mgt.) : Sem l 5.31
sf&QA MCA
Tasks in Defect Life Cycles are: Test Managenent
New: Potential defect that is raised and yet to be validated. : Incident Description:
In incident description, any information related
Assigned: Assigned against a development teamto address it but not to the incident that was
yet resolved dy included in
Active: The Defect is being addressed by the developer and investigation the summary is provided by not
stensive and detailed information abOut the team. These include
progress. At this stage, there are two possible outcomes: Deferred is under
ior Rejectcd. the incident and providing ne.
Test: The Defect is fixed and ready for testing. ather supporting evidence, which can
help the developers or incident
Verified: The Defect that is retested and the test has been verified by OA management team understand
the defects and incidents effortlessly. Few
Closed: The final state of the defect the things included in this section are: of
that can be closed after the QA retesting or
can be closed if the defect is duplicate or
considered as NOT a defect. Inputs
Reopened: When the defect is NOT fxed, QA Expected Results
reopens/reactivates the defect.
Deferred: When a defect cannot be addressed
in that particular cycle it i Actual Results
deferred to future release.
Rejected: A defect can be rejected for any Anomalies
a Defect, Non Reproducible.
of the 3 reasons: Duplicate defect. NOT
Date and Time
5.9.2 Defect/Incident Report Procedure Step
Incident report can be defined as a written
description of an incident observed durinp Attempts to Repeat
testing. Testers
The aim is to report all Observers
the incidents that require proper assessment
investigation, and to meet the expected output and
4. Impact:
criteria set during the planning phase.
The format defined by the IEEE Finally the impact
std 829-1998 for test incident report is as and severity of the incident(s) recorded
1 Test Incident Report Identifier: follows:
under this section of the is by the team
It is a unique company generated format. Here, the details about
number that offers an identity potential damage caused by the the actual and
and helps differentiate it from tothe report incident are identified and logged by
the team
other reports. The number may for future reference. These are
what level of testing the incident also identify mainly based on the severity of the
occurred at. This is used to the priority to fix them or both, incident,
coordinating software and testware assist in which further help the team categorize
versions withín configuration properly. them
management and to assist
in the elimination of incidents
improvement. through process For example:

2. Sumnmary: Severity: The potential impact to

Thisis a summation/description
the system.
Mission Critical: Application will
to enable others to
of the actual incident. Provide not function or systemfails.
understand how the incident was enough details Major : Severe problems
discovered and any but possible towork around.
relevant supporting information such as: Minor : Does not impact the
C

References to: functionality or usability of the process but is not

according torequirerments/design specifications.
Test Procedure used to discover Priority: The order in which the
the incident incidents are to be addressed.
Test Case Specifications
that willprovide the information Immediate : Must be fixed as soon as
to repeat the possible.
incident Delayed: System is usable but incident must be fixed
Test logs showing the prior to next level of test
actual execution of the test cases or shipment.
Any other supporting trace logs, memory and procedures
dumps/maps etc. Deferred:Defect can be left in if necessary doe to or costs.
time
 ST& QA - MCA (Mgt.) : Sem il 5.32
Test Managemeny -MCA (Mgt.): Sem ) 5.33
CASE STUDIES Test Management

Case Study 1: Home Back

Consider Bill tracking system. PAYMENT SCREEN
This system keeps track of bills that
how much material is are not
purchased from each supplier. Details of paid and
that particular material etc. First suppliers supplying Supplier Number:
the material and then the supplier
about materials validated. If thesse sending the d Now supplier ?
two conditions are satisfied Click hero
will be generated which will be then the bill.code
used to uniquely identify
issued either by cash or cheques. the bill then payment will hs
Finally reports will be sent to Item details:
management. Assume the user and the
that system has two different screens
screen (ii) Payment Screen. for user: (i) Item Ente. Descriptio
Sr. No. Quantity Total
(1) Write a test plan. Rata
Amount
(2) Identify TEST CASES
for your
Form/Screen in the given
for aesthetics testing (look/feel), categories: Two test cases
validation, usability
within the system. Document and navigation by user
test cases properly.
SCREENS: Pay by cash
3 Pay by credit
Print Bill

Home
Back Fig. 5.9: Input Screen
for Payment
ITEM ENTRY ESTPLAN

Supplier Number: L Test Plan Identifier:

Item code : BILL TRACK-2022-1

L Introduction:
Don't know tem
code? Clhck here Bil tracking
Item Nano : system keeps track
of bills that are not paid and
is purchased
from each supplier, the amount of material
Rate: details of suppliers supplying
Quantity:
material etc, that particular
First the
material and then the
Total Amount: supplier sending the data about
I these two conditions are materials is validated.
satis fied then the bill-code
mi be used to uniquely will be generated. This
identify the bil then payment bill code
Add Bil cheque. will be issued either by cash or
tinally reports
will be sent to the user
Fig. 5.8: Input Screen TestScope: and the management.
for Item Entry
InScope:
GUI Testing,
Validation and Navigation
Out of scope:
Performance Testing,
Stress Testing, Security
Testing
 ST & OA- MCA (Mgt): Sem il 5.34
Test Management MCA(Mgt.) : Sem IlI 5.35 Test Management
4. Items to be tested: •

NAME criteria:
item_entry
IDENTIFIER
VERSION
NUMBER AEdt will suspended at the end of the work day. Testing is resumed
be
BILL_TRACK_ITEM Testing the
supplier_details 1.1 fallowing work day morning. A decision to stop
testing will be based on
BILL TRACK_SUPP
tracking :
payment_screen 1.1 requirements
BILL_TRACK_PAY Coverage of all the
Billing 1.2
BILL TRACK
BILL number of open defects reports.
The
5. Test Environment: 1,2 test-relatedIdoccuments must be
All subnitted to Lara.
Test planner describes Managernent:
main components Risk
configuration) including of the test environment Non-availability: Lara. test lead is not available
hardware, software, and (test bed with
the test team to provide
operating system.
Platform cecessary data,and past schedules. In this situation, other test lead will be available
Java Server Page(SP) tothe group and will supply the needed information.
Browser : Mozilla / Chrome Gietof staff
responsibilities: Lara is required to work on a more
Server : .ken some other person urgent project,
Apache who having the experience of test lead
Database test lead.
engineer will replace
: SQL Server the current
OS nelays in testing efforts: If the testing schedule
Windows is significantly impacted
Payment gateway
cererity level
defects, an additional developer by high
Authorize.net will be assigned to the project to
6. Test Team: perform fault localization.
L Aoplication:
List testing participants Itself is not available for the testing on
(team) and their time.
includes: roles and responsibilities. All the resources are not
properly provided.
Test team
Lara, Test lead SRS are not clearly defined.
o John,
Jane, Manual test engineers 2 Defect Recording/Tracking:
Twomanual test Excel
spreadsheet should be
engineers, developed for recording
execution and recording John and Jane will be responsible Approvals : defects and tracking status.
7. Testing of results. They will be supervised for test case design, test
Strategies: by Lara, test lead. he test plans for a
Type of Testing : manager.
project should be reviewed
Manual testing Al parties by Lara, Project manager
who review the plan and sQA
8. Test Deliverables: and approve it should sign
lara the document.
Scope: GUI testing,
Functional testing. Test lead
System test plan Signature
Test cases Date
Test summary report
and Defect Report. Philip Adler
Test data
rojectManager
Input / Output screens
and Reports Signature
Input / Output
for item entry, supplier Date
9. Test schedule: details and payment screens
The project should aulMartin
be ready for acceptance SQA
test by "dd mm Manager
/ /yyyy". Siznature

Date
 ST&OA- MCA
(Mat):Sem l S.34 Test
Mana (Mgt ): Sem u!
5.35 Test Managemert
ef&GA. MCA
4
Items to be tested:
NAME IDENTIFILR VERSION Exit eriteria,
NUM2tR 10.
item_entry BIL TRACK ITEM Testing will be stusperded a the rnd of the work day Testinz is resumed tte
11 A Cei310n to stop testing
Supplier_details BILL TRACK SUPP
fottowinz work day marning will be based on
11 trachinz
paynent _screen BILL_TPACK PAY
12 Coveraze of all tho requuirment:
Billing
BIL TRACK EIL The number of orn defects reports.
5 Test Environmnent: All test-re' >'nd urnen3must be subm.e! to Lur
Test p!anner
descnbes main cGmporents of the test cnvironment 11. Risk Manageiaent:
Configuration) incdudirghardware. software, and operating 3y3tem Non-availability: Lara, test Irad is not ava.lb! nith the test team to provide
Platform Java Server Pagc(USP) rrcessary data, and pait schedila: in th.: 3ituation, other test lead will be available
Browser to the zroup and ill suppl the neetod infor a'ion
Mozlla / Chrome
Conflict of staff responsibilities: Lara ii requred to work on a rnore urgent
Server Apache project,
then some other person nho hainz the eprience of te: lead erngineer will replace
Database SQL Serve: the current tr:t lead
Windows Delays in testinz efforts: If the ta"in,
ictoule Sznificantly inpacted by high
Payment gateway severity level defrct:, an add.tion.al Ceopt will be assizned to the project to
Authorize ret
6. Test Team: perfurm fault lccalization.
List testing participants (tean) Application: self i: rGt avulable for :hotoin; on tu,
It

ar.d theit roles and responsibil.:;rs

includes Al the resources are no properly pronded
Lara, Test lead SPS are not clearly detined
12. Defect Recording/Tracking:
John, Jane, Manual test engineers
Excclspreadsheet shou!d bodeyloped
Twonanual test engineers.
Jokn and jare will be respons.ble for trst forrecordin; defects ard tracbing status.
casei!t 13. Approvals :
executicn and recording of results They
7. Testing Strategies:
wll be supervisrd by Lara, tet lrs: The test p!ans for a project
manazer Allp rties who
ihuld be rened by Lura, Project manager and SQA
Type of Testing : 1Manualtesting reie the plan and approve it should sign the documnent.
Lira
8. Test Deliverables:
Test lead
Scope GUItesting. Functional
testin, Sinature
System test plan
Test cases
ih:dip Adler
Test sumnary report and Defect Project MManager
Peport
Test data
Dat
Input /Output screens and Reports
Input /Output for itern entry, supplier I'aulMutti1
detals and payment screens
9. Test schedule: sQA Mansger
The project should be ready for 1phatufe Date
acceptarKe test by "dd mm
/ / yyyY"
ST & OA - MCA (Mgt.): TesttAanagemert
Sem il 5.36 - (Mgt.) :Sem l! Test Marnagement
of& OA MCA 5.37
TEST CASES:
New
Test cases for Bil Tracking system:
suppler ?
Preconditions : Open Web browser and enter URL in the address bar Home dick here
must be displayed. page
Don't kncw

Test Test status the item

Test case Test steps
case Test case (PIF)
Code ? cick

id name description here

Step Expected result Actual
Back
result
GUI01 Verty Is the gereral Print bill
Open the Backgrourd color
Aesthetic Sareen browser and is proper and Naviga Frames Do frames Open the home Frames not
Condrtions backgroud page and ty
type URL of the visual content are resize present
fon 02
the correct site available without automaticaly resizing the
color? error. and frames
Is the screen appropriately?
Open the site, System gets
resizable and resize and Naviga Is a Open the hcme Navigatonal bar
resized and
minimisable? minimize the minimized. tion navigational page and and home link is
same. bar and link to navigale the present on every

Assure that all home present system SCreen.

Open Item entry Pop-up displaying on every
windows and form and click all item details
popups have screen?
on: have a look and
a consistent Are fonts too Load the home Fonts are proper
feel consistent to
look and feel. large or page
Don't know The its parent window.
small?
Item Code? Click
Valida Valida Check all Lozd item entry An error message
Here paçe and enter
tion 01 ion of numeic "Invalid item
GUI02 Venfy Does a failure Open Item entry System displays item entry values follcwing detals: code!" must be
validaton of validation of displayed
form and feed error message: Supplier no:10
condition every field following details: Invalid supplier Item code: $%a
cause a Qty: 4
number! Try again
sensible User
Supplier No. jij Check Load item entry System should
error
functional.ty of page and enter automaucally
Open item entry System displays
message? following details:
form and feed Item code display the details
error message:
Supplier no:10 of ltem name, its
following details:
Quanty cannot Item code: 2 rate.
Qty. -5 be negalve!
Navk Navgaton Check Load item entry System displays
Does each Open respecive System redirects functicnality ofpage and enter the total amount
gation hyperdink work pages and try lo respective
01 aty feld following details: automatically
on each the navigations pages. Supplier no:10 based on item
page? for:
rae and quantity
 Test Management l Test Management
ST & QA - MCA (Mgt.) : Sem 5.38 QA MCA(Mgt.) : Sem 5.39
ll ST&

Item oode: 2 entered. To verify Open Item entry

Inter
Qty: 3 whether form and
activity
Valida Valid Load payment System should interaction validale pop up Link displays
Check
tion02 tion of functionality of screen and enter display the details for various categories
mechanisms
supplier no.:10 of item purchased
payment payment (pop-ups, pull of items as a pop
Don't krow item
Screen and click get in tabular form.
Screen up window.
down menus) code ? click
details
are easy to here.
Check Load payment System displays
functionatity of Screen and enter an error message: Use
payment Supplier no. :* Enter supplier Does tabbing Load Add Tabbing works
Usabi Verify
SCreen and click get number supplier form properiy for
work
details y 02 tabbing
on each consistently in and check following felds:
Validation Check Load Add System should
of form a uniform labbing Suppl.er name
functionality of supplier form. display the
supplier add supplier Supplier no. manner? Supplier address
delails (Auto Supplier phone ro
form increment of
Email address
Supplier no.)
Check Load Add System displays
funcionality of supplier form following error
Case Study 2:
add supplier and enter follow message: on test cases for different
(Supplier details:
Case study on test plan for application and Case study
•"Special
name) Supplier name: characters are not features within application.
$3sas allowed in supplier Pass/Fail
Test Steps Test Data Expected Actual
Supplier Addr: name Test Test Case
Results Results
pune ."Invalid phone Case ID Description
Supplier Phone number User should As Pass
1. Go to site Userid quru99
|TUO1 Check
No.: asdf888 •Invalid email = Login into anExpected
http/demo.guru99.comPassword pass99
Email addr: address" Customer
dsfaasdf Lcgin with
applicaiton
2. Enter Userld
Usabi Verity Does the Open the System displays a valid Da!a
lity 01 3. Enter Password
Usability home page browser and home page
load quickly? type URL of the quickly 4. Click Submit
site Userid
TUO2 Check
1. Go to site guru99 User should As Pass
if you Verify Load payment System redirects
follow paymen Customer htp ldemo.guru99.comPassword = pass99 not Login Expected
Screen, enter the procedure to
each Screen supplier no. with into an
authorize.net for | Login 2. Enter Userld
instruction procedure Select "Pay by credit card applicaiton
invalid Dsta
does the credit' option vatidations.
3 Enter Password
expected
Click Submit
result
occur?
 ST & OA - MCA (Agt.) : Sem 540
Test Managemeng : Sem ill Test lanagement
sOA MCA(Mgt.) 5.41
-
ll
Summary check Your Understanding
process of managing testíng activities, such as planninz,
Test management is Identify the term which is not related to testing?
a
4

execution, monitoring, and controlling activities. (a) Failure (b) Error

Test Organization in Software Testing ís
a
procedure of defining roles in the
testinz (c) Test case (d) Test bot
process. It defines who is responsible for which activities in testing process. It
alss 2. Identify the stage in vuhich test cases are designed?
explains test functíons, facilities and activities.
(a) Test planning (b) Test configuration
A
Test Plan refers toa detailed document that catalogues the test strategy, objectives,
schedule, estimations, deadlines, and the resources required for completing that (c) Test specification (d) Test recording

particular project. 3. Is exhaustive testing possible?

Test Monitoring is a process of evaluating and providing feedback on the "currentl.. :

(a) Always possible
progress" testing phase. (b) Impracticalbut possible
Test Control is an activity of guiding and taking corrective action based on s (c) Impractical but impossible

metrics or information to improve efficiency and quality. (d) Practically possit'e

Test log provides detaíled information regarding the success of each test perfor. 4, Identify which of the folloing life cycle contains the phases: Test Case Design,
to validate the quality, performance, & functionality of the software. Test Execution, Defect Tracking, Maintenance.
Defect density helps the team in determining the total number of defects found ina (a) SDLC (b) STLC
software during a specific period of time- operation or development. (c) SQLC (d) BLC
Test Control occurs based on the results of Test Monitoring. It
refers to tažing 5. To notify the developer which bugS need to be fixed first is termed as
corrective action based on test monitoring reports to improve quality and efficiencz. (a) Scalability (b) Fixability
A
Requirement Traceability Matrix (RTM) may be used to check if the current proiet (c) Traceability (d) ?riority
requirements are being met, and to help in the creation of a request for proposa! 6. The purpose of is to establish and maintain the integrity of the
software requirements specification, various deliverable documents, and project plan products of the software or system through the project and product lifecycle.
tasks. (a) Configuration Management (b) Test Reporting
A test case is a document, which has a set of test (d) Test Control
data, preconditions, expected results (c) Test Monitoring
and post conditions, developed for a particular test scenario in order to verifz 7. A
chronological record of relevant details about the execution of tests is called as,
compliance against a specific requirement.
A test suite, is also known as a validation (b) Test procedure
suite, is a collection of test cases that are (a) Test suite
planned to be used to test a software program to show that it analysis (d) Test log
has some specified set cf (c) Test
behaviours. 8. A role of test manager is to

Configuration Management determines clearly about the items that make up the (a) determine when to release a system.
software or system. These items include source code, test scripts, third-party (b) Reallocate resources to meet objectives.
software, hardvware, data and both development and test documentation. (c) raise incidents on fault.
Defect life cycle or Bug Life cycle is the journey a defect (d) report deviations in project plan.
of cycle, which a defect goes
through during its lifetime. 9. Test suite is
Project risks are potential failure areas in (a) Set of test cases (b) Set of inputs
the software or system: product risks 3e
risks that surround the project's capability to deliver its (c) Set ofoutputs (d) Set of products
objectives.
 TestManagement
T& QA. MCA (Mgt.) : Sem lII 5.42

document?
10. not part of the Test
6...
is
(a) Test Case
(RTM)
(b) Requirements Traceability Matrix

Tool Support for

(c) Project Initiation Note (PIN)
(d) Test strategy
ANSWERS

1. (d)

9. (a)
2. (c)
10. (c)
3. (b) 4. (b) S.(d) 6. (a) 7. (d) 8.(c)
Testing,
Practice Questions
Q.I Answer the following questions in short. Objectives...
1. What is a Test Plan?
2. What is test Management? Tointroduce the tool support for testing.
To know about types of test tools and their use.
3. What is 'Configuration Management'?
To get informationof various testing tools.
4. Mention what are Project risk and Product Risk?
5. What is a bug life cycle? O To learn about an introduction of testing tool in organisation.
6. What is Requirement traceability matrix?
QII Answer the following questions. 6.1 TYPES OF TEST TOOLS - CAST
1. Explain the various types of white box
testing.
What is CAST in Testing?
1. In software testing, which are roles/skills of tester?
The CAST Certification demonstrates a foundation-level understanding of quality
2. What are the actions that test manager should take against risks?
3. Explain how test manager can estimate the project and
testing principles and practices. Acquiring the designation of Certified Associate in
what to estimate? Software Testing (CAST) indicates a professional level of competence in the principles
4. What does a good test report include?
and practices of software testing in the IT profession.
5. By what factors you can determine the quality
of the test execution? Testing Tools:
6. Describe the defect/incident report.
Tools from a software testing context can be defined as a product that supports one or
7. Explain the IEEE 829 Test Plan.
more test activities right from planning. requirements, creating a build, test
Q.III Write a short note on:
execution, defect logging and test analysis.
1 Test Scenario
Classification of Tools:
2. Horizontal traceability
Tools ca ue classified based on several parameters. These include:
3. Test Log
The purpose of the tool.
4. Defect Management
The activities that are supported within the tool.
S. Defect Density o The type/level of testing it supports,
Thekind of licensing (Open Source, Freeware, Commercial)
The technology used.

(6.1)
ST & OA- MCA (Agt.) : Sem l1
6.2 Tool Support
Following table shows various types
1or Testing QA - MCA (Hgt.) : Sem 6.3 Tool Support for Testing
sT&
of tools with their use:
Table 6.1: Types of Tools Risks of using tools include:
Sr. No. ToolType
Used for Unrealisticexpectations for the tool (including functionality and ease of use.
1 Test Management Tools Usedby Ttnderestimating the time, cost and effort for the initial introduction of a tool
Test Managing, Scheduling,
Defect Logging, Tracking Testers (including training and external expertise).
and Analysis. 1Inderestimating the time and effort needed to achieve significant and
2. Configuration continuing benefits from the tool (including the need for changes in the testing
Implementation, Execution,
Management Tools Tracking Changes. Al Team members process and continuous improvement of the way the tool is used).
Static Analysis Tools Ünderestimating the effort required to maintain the test assets generated by the
Static Testing
4 Test Data Preparation Developers tool.
Tools Analysis and Design, Test Over-reliance on the tool (replacement for test design or use of automated testing
data generation. Testers
S. Test Execution Tools where manual testing would be better).
Implementation, Execution Neglecting version controlof test assets within the tool.
6. Test Comparators Testers
Comparing expected and Neglecting relationships and interoperability issues between critical tools, such as
actual results Al Team members requirements management tools, version control tools, incident management
7. Coverage Measurement
Provides Structural tools, defect tracking tools and tools from multiple vendors.
Tools Developers
8.
Coverage 6.3 INTRODUCTION OF TOOL INTO ORGANIZATION
Performance Testing
Tools Monitoring the The organization must be ready to introduce, use and be involved in adapting
performance, response Testers the tool
9. Project Planning time through its test processes. Only an assessment of the organizational maturity
and Planning could prove its readiness by clearly identifying the strengths, weaknesses
Tracking Tools Project Managers and
opportunities to do so.
10. Incident Management
Managing the tests Essentially, the assessment should identify which testing area or processes can be
Tools
Testers improved by adopting the toolL
6.2 EFFECTIVE USE
OF TOOLS: POTENTIAL
During test tool evaluation phase, we should identify whether:

Simply purchasing or BENEFITS AND RISK It performs effectively within the software under test and within the current
leasing a tool does not
type of tool may require infrastructure.
guarantee success
are potential additional effort to achieve with that tool. Each It requires any potential changes.
benefits and opportunities real and lasting benefits. We should also evaluate the vendor (support, version, reference site visit, training).
also risks. with the use of tools There
in testing, but there are evaluate internal requirementssuch as training needed and estimate a cost-benefit
Potential benefits of using
tools include: ratio based on a concrete business case.
Repetitive work is Once the assessment done and the decision to introduce this tool is made. a nilot
reduced (e.g., running
test data,and checking regression tests, re-entering should be planned for learning more details, confirming that our assumptions were
against coding standards). the same
Greater consistency justified (costs involved, benefits, changes identified) and mastering its use before
and repeatability (e.g., tests
order with the same frequency, executed by a tool further roll out.
and tests derived from requirements). in the same For successfully deploying a tool within an organisation, the initiative should alwsave
Objective assessment
(e.g., static measures,
Ease of access to coverage). follow these principles:
information
about test progress, incident about tests or testing (e.g., statistics and graphs Rollout the tool to the rest of the organization incrementally.
rates and performance). Adapt and improve processes to iit accordingly to how the tool should be 3ead
 ST & QA - MCA (Mgt.) :
Sem 11 6.4
Tool Support
for Testing - MCA (Mgt.) : Sem II
ST&QA 6.5 Tool Support for Testing
Provide training and coaching/mentoring for new users.
Define usage guidelines. Components s of WebDriver Architecture:

Implement way to gather usage information. WebDriver Architecture is made up of four major components:
Monitor tool use and benefits. 1.
selenium Client library: Selenium provides support to multiple libraries such as
Provide support to the test team. Ruby, Python, Java, etc. as language bindings have been developed
by Selenium
Collect lessons learned from all teams. developers to provide compatibility for nultiple languages.
1SON Wire protocol over HTTP: It is an open
.6.4 TESTING TOOLS standard that provides a transport
mechanism for transferring data between client and server on
the web. It
Software testing tools are applications provides support for vario'is data structures like arrays and objects which makes
that can be used to assist developers
testers in performing Manual or Automated Tests. and it easier to read and writer'g from JSON.
6.4.1 selenium Web Driver and Test NG 3. Browser Drivers: Selenium provides drivers specific to
each browser and without
Selenium and Test NG are the most trending software testing tools. revealing the internal logic of browser functionality. The browser driver interacts
with the respective browser by establishing a secure connection. These browser
6.4.1.1 Selenium Web Driver
drivers are also specific to the language which is used for test case automation
Selenium Web Driver is one of the many types selenium like C#, Python, Java, etc.
of frameworks, can he
defined as a Test Automation Tool used to test web-based applications. which
4. Browsers: Selenium provides support for multiple browsers like Chrome, FirefoX,
Selenium WebDriver is a web automation
across various browsers (cross-browser framework which allows us to execute tect Safari, Internet Explorer etc.
tests). How Selenium WebDriver Works?
It makes direct calls to the browser
using each browser's native support for Selenium WebDriver works in three steps:
automation.
1. Test commands are converted into an HTTP request by the JSON wire protocol.
Tool is used for automating web-based
application testing to verify that it performs 2. Before executing any test cases, every browser has its own driver which initializes
expectedly.
the server.
Selenium WebDriver allows you to choose a
programming language to create test 3. The browser then starts receiving the request through its driver.
scripts.
Advantages of Selenium:
Selenium WebDriver Framework Architecture: It is one of the most popular Open-Source tools and is easy to get started with for
testing web-based applications.
It also allows you to perform cross browser compatibility testing.
It supports multiple operating systems like Windows, Mac, Linux, Unix, etc.
It helps to get a higher ROI.
It is easy to access. Users can even access it remotely through anv device
Browser Real
Drivers It helps to find bugs and flaws at the initial stage.
Seleniunm Browsers
usere
DI Client Librarios
(Pyhon, C#, Java, Porl, etc.)
JSON Wire
Prolocol (Chromo Driver,
It makes the process more reliable and tests dependable for

It enables testing in volumes.

Firofox Dover.
Intemet Explorer Drtver,
Microsoft Edgo Drrver)
Fig. 6.1: Selenium WebDriver Framework
Architecture
(Chrome, Firefox,
tnlernol Exploret
Aicrosolt Edgo)
6:4,1:2 Test NG
means Neyt Gonoroate
TestNG is an open source framework where NG
TaetNC makes automated tests more structured, readable, maintainable and user.
powerful features and reporting. Its high-end
friendly. It provides annotations like
scale up, as you perform cross browser
data provider, makes it easier to testingacross
and their versions
multiple devices, browsers,
 ST & QA - IMCA (Agt.) : Sem III 6.6 Tool Support
for Testine
ST& QA - MCA (Mgt.) :
Sem Ill
6.7
It is an automation testing framework and uses annotations. Annotations are Tool Support for Testing
lines of
code that control how the method below it will execute. WebDriver does not havea native
The greatest advantage of TestNG is that we can generate test reports
2. Test Reports can be generated using
and mechanism for generating
number of scripts passed, failed or skipped. Failed test cases can be run know the TestNG
separately reports.
using TestNG. Along with it TestNG provides enables us with the ability
test cases by reading the input file from any medium like excel
to execute 3 For running the failed test cases, Failed test cases can be run separately
and generate reportsthe
we need to run the whole script
in different mediums. using TestNG.
again.
TestNG and Selenium Webdriver
enhance the capability of Selenium tests and make
it easier for users to understand various
XLS File Read Input Data issues and generate a report for the same. It
provides flexibility and great strength to the users
who want to test
the web app no in
Selenium time and want to generate a report that others can
TEst Testing Test Scripts
understand easily.
Generate Framework 6.4:2 Appium
Logs Appium is an open-source automation mobile testing tool,
which is used to test the
application. It is developed and supported by Sauce Labs to
automate native and
hybrid mobile apps.
It is a cross-platform mobile automation tool,
Fig 6.2: TestNG Framework which means that it allows the same
TestNG framework can be integrated test to be run on multiple platforms. Multiple devices can
with various tools as per users' requirements: be easily tested by Appium
users can use tools such as Jenkins, in parallel.
Maven, Jenkins, and many others to test
Using Annotations of TestNG framework their app. In today's development area, the demand for mobile
applications, is high. Currently,
makes it easy for coders and tester to people are converting their websites into mobile apps.
understand the overall process. Therefore, it is very important
to know about mobile software automnation
Advantages of TestNG: testing technology and also stays
connected with new technology. Appium is a mobile application
Some of the benefits are as follows: testing tool that is
currently trending in Mobile Automation Testing Technology.
Logs generation. Appium is used for automated testing of native, hybrid,
and web applications. It
Easy use of annotations. supports automation test on the simulators (ios) and emulators (Android) as well 2e
Enables users to group and prioritize test cases. physical devices (Android and i0S both). Previously, this tool mainly focused on
ios
and Androjd applications that were limited to mobile application
Allow parallel testing. testing only. Few
updates back, Appium declared that it would now support desktop application
Helps to product execution HTML reports. testing
for windows as well.
Data parameterization is possible. Appium is very much similar to the Selenium Webdriver testing tool. Appium bae n
6.4.1.3 Difference Web Driver and Test NG dependency on mobile device 0S because it has a framework that converts +h
Selenium Webdriver commands to UlAutomator and UrAutomation comnnde
Table 6.2: Difference between Android and ios respectively, that depends on the device type rather than
WebDriver and TestNG he
Sr. type.
WebDriver
No. TestNG Selenium is the backend
of Appium that provides control over
the functionality of
1. WebDriver is a web automation Selenium for testing needs.
It is an automation testing framework and
framework that uses Junit. uses annotations such as @BeforeTest, Features of Appium:
application source codee or library.
o Appium does not require
@AfterTest which makes
it more provides a strong and active community
Appium
comprehensible.
Contd
 ST&QA - MCA
(Mgt) : Sem ill
6.8 Tool Support Sem I ToolSupport for Testing
QA-MCA(Mgt.) :
6.9
for Testing &
Appium has multi-platform
support i.e.,.it can run the same test cases Appium UIAutomator
platforms. on multiple Selenium
cre ates This frameworks will then communicate
and Appium Server then
Appium allows the parallel execution esenum ad as a dient automation session for the cdient with bo0strap.jar which i unning
command (hitp
requost)
In Appium, a small change
of test scripts. d server via. JSON
and also checks the desired capablitics
server
in Emulator/Real devico fo
Android
does not require re-instalation Aroum
Protocol.
ofcient and then Appium performing cdient
sends the sever request to UIAutomater operatons Mobile
It supports various languages of the application SON WroFProlocol
(Android) OR UIAutomation (lOS)
such as C#, Python, Java, crtains al tho
capaclities
Node.js, and many others Ruby, PHP, JavaScrint wisL dcorfguration set in code Appium Server UIAulomator
Advantages Appium: that have Selenium client libraries. UIAutomator request
of Appium Request (Android) to bootstrap.jar
1. Appium
is an open-source tool, (server)
Selenium (Client
install. which means it is ib and all the jars)
(Written in
freely available. It is easy Node Js)
2 ta Appium Server UIAutomation
It allows the automated JSON Wire
3. Unlike testing of hybrid,
native, and web applications. Protocol Request (1OS) UIAutomator request
other testing tools, you to bootstrap.js
your aPp to do not need to
make Appium compatible include any additional
with automation. It agents in
which is going to upload tests the samne apn IOS
4. An additional in App Store. Mobile
feature added to Appium.
testing for windows as Now it would support Bootstrap jar works as TCP server.
well along with mobile desktop application And then it executes the command
5. Appium is a application testing.
cross-platform, freely on the devices.
the cross-platform available mobile testing tool,
mobile testing. This means which allows us
(single API for both you can test on Fig. 6.3: Appium Architecture
Android and i0S platforms). multiple platforms
Disadvantages Test Scripts written by the tester executes on the Emulator or device by sending them
of Appium:
Appium has some as requests to the Appium server. Each vendor, such as IOS or Android, has a different
drawbacks too, which are
1. Lack as follows: method and mechanism to execute test cases on the device. So, the test case executes
of detailed reports.
2. Since the tests after listening commands from the Appium server. Appium uses JSON wire protocols
dependon the remote to send command requests to Appium server.
3. It is not a web driver, so
limitation, but an it is a bit slow.
that only supports Android overhead that Appium uses UIAutomator 6.4.2.2 How Appium Works?
SDK, API16, or higher. for Android
older APIs, but not However, Appium When we install the Appium, server is also installed with it on our machine that
a
directly. It uses supports
support older APIs. another open-source exposes the REST API.
4. In iOS, only one
library Selendroid to
instance (i0S Script) can It receives command and connection requests from the client and executes that
one test can run on one Mac
be executed at a OS device, which means command on devices like ios or Android.
multiple ioS devices time per Mac.
at the same time, you If you want to run your It replies with the HTTP responses.
Mac machines. need to arrange the same tests on
But it would be
expensive to arrange number ot To execute requests, 2Ses a mobile test autonation tramework to run the user
problem can be resolved
Lab. Currently, if you will run your script various Mac machines. This interface of the app. For example,
it allows scripts to run on in the mobile cloud of Sauce
time. multiple ioS simulators Apple instruments used for ios.
at the same 15 or less.
(6.4.2.1 Appium Architecture Selendroid used for Android API
used for Android API 16 or higher.
Appium is an HTTP server UIAutomator
that gives rise to aserver that is written in Node.is. It starts a "test Appium in Android:
and listens for proxies' case" on the device to a olAutomator script unn:
server. Tester commands On Androjd, Appium proxies the command
writes automation framework of Android
Webdriver sessions the Test scripts to execute on devicefrom or
the main APpium device. UIAutomator is
a native UI that allows you
for into the device using command line. Although uses
handled by the Appium. different platforms like Android and Emulator. Several to run Junit test cases directly
allows to run it
ios are createa ana language, but Appium it from any WebDriver
Java programming
supported language.
 STSQA- ACA(At.):Sm 610 Tool Support
for Testina - AICA (Agt.) : Som
ST S QA 6.11 Tool Support for Tosting
Andniu uses bootstrapjar. which works as a
TCP server. It is 1sed to send
the test InstallAppium Deslktop Client
0Mmands torform the actions on Android device using UlAutomator.
In the below tigun, s the Appiun architeture in respect to Android Iautomation Install Eclipse IDE for Java
6.4.3 JMeter
Refore going into the details of JMeter, let us first
understand a few terminologics
nssociated with the testing of any application.
UAutom,ator
Controller Performance Test: This test sets the best possible performance
(android) a given configuration expectation under
Web Driver Script of infrastructure. It also highlights early in the
UiAutomator process if any changes need to testing
Command be made before the application goes into
def tes! case: Server production.
e'ement cch(10g in')
buton submt() Load Test: This test is basically used for testing
the system under the top load it
UIAutomator was designed to operate under.
Command
Client TCP Server Stress Test: This test is an attempt to break the system by
overwhelming its
resources.
At a basic level, JMeter works by simulating
TCP Client visitors to your application or service by
allowing users to create and send HTTP (Hypertext Transfer Protocol) requests to
server. The server response data is the
then collected, and the statistical data is displayed
Fig. 6.4: Appium Architecture visually for users in the torm of charts and reports.
in respect to Android Automation
Appium in i0S: It is used to execute perfcrmance testing. load testing
and functional testing of web
As Android uses UIAutomator, applications. JMeter can also simulate a heavy load on a server by
i0S uses UIAutomation, Similar to creating tons of
Appiumn proxies
the command to a ULAutomation test case the Android, virtual concurrent users to web server.
instruments environment. Apple provides running on the Mac Stefano Mazzocchi of the Apache Software Foundation was the original developer
this application "instrument" that of
performs various activities like JMeter. He wrote it primarily to test the performance
building, profiling, and controlling of Apache JServ (now called as
On the other hand, ios apps. Apache Tomcat project). Apache later redesigned JMeter to enhance the GUI and to
it also has an automation component
commands in JavaScript. It uses where you can write add functional testing capabilities.
UIAutomation API to interact
Appium uses same libraries to with Application UI. JMeter is a Java desktop appiication with a graphical interface that uses the Surinn
automate iOS Apps. granhical APL, It can there fore run on any enironment
/workstation that accepts a
6.4.2.3 Requirements to use Java virtual machine, for example - Windows, Linux, Mac, etc.
Appium The protocols supported
by JMeter are:
Install Java jDK).
Install Android studio. Web- HTTP, HITPS sites weu 1.0 web 2.0 (ajax, flex and flex-WS-ama
- SOAP / XML-RPC
Web Services
Install additional Android SDK
tools. Database via JDBC drivers
Install Appium jar file.
Directory - LDAP
js (Not required - It by via JMS
default comes with "node. is" Messaging Oriented service
Appium server is installed. and "NPM", whenever te SMTP
Therefore, it is not required Service - POP3,
IMAP,
separately. It is already included to install node.js and N

in current version Appium.). FTP Service

of
 -
ST & QA HCA (Mgt.) : Sem
l 6.12
Tool Support
for Testing
QA- MCA (Mgt.) Sem l!
: 6.13 Tool Support for Testing
ST&
JMeter Features:
Following are some of the features of JMeter: Summary
Being an open source software, it is freely available. The CAST Certification demonstrates a foundation-level understanding of quality
It has a simple and intuitive GUI. testing principles and practices
JMeter can conduct load and performance test for many different server Tools from asoftware testing context can be defined asa product that supportsone or
tm.
Web - HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail - POP3, etc. more test activities right fronm planning requirements, creating a build, test
It is a platform-independent tooL On execution, defect logging and test analysis
Linux/Ünix, JMeter can be invoked h.
clicking on JMeter shell script. On Windows, it can Selenium WebDriver is a web automation framework which allows us to execute test
be invoked by starting the
jmeter.bat file. across various browsers.
It has full Swing and lightweight component TestNG is an open source framework where NG means Next Generation. It is an
support (precompiled JAR uses
packages javax.swing." ). automation testing framework and uses annotations.
JMeter store its test plans in XML
format. This mneans you can generate a test plan Appium is an open-source automation mobile testing tool, which is used to test the
using a text editor. application.
Its full multi-threading framework JMeter is a Java desktop application with a graphical interface that uses the Swing
allows concurrent sampling by many
and simultaneous sampling of different threads graphical API.
functions by separate thread groups.
o It is highly extensible. Check Your Understanding
It can also be used to
perform automated and functional
testing of the
1 Standard Enforcer is a
applications. (a) Dynamic Testing Tool (b) Static Testing Tool
How JMeter Works?
(c) Static & Dynamic Testing (d) None of the mentioned
JMeter simulates a group
of users sending requests to a target server, 2. The Web driver is used
statistics that show the performance/functionality and returns
(a) To execute tests on the HtmlUnit browser.
via tables, graphs, etc. of the target server/application
(b) To design a test using Selenese
Take a look at the following
figure that shows how JMeter works : (c) To quickly create tests
(d) To test a web application against Firefox only.
Start Creates requests to target server
and simulates a number of users
3. Which operating system is not supported by Selenium Webdriver?
End
(a) Unix (b) Chrome
(c)
Firefox (d) Saffari
4. Which language is supported by Selenoum Web Driver?
Jmeter gathers
data
to calculate statistical (b) ASP
(a) SQL
info Server Responds (d) Perl
Report (c) COBOL.
5. Which tool is used for static testing?
(a) Test management tool
(b) Static analysis tools
Jmeter saves allresponses
(c) Test comparator tool.
(d) Test execution tools
Fig. 6.5: Working
of JMeter
 ST & QA- MCA (Mgt.) : Sem Tool Support
Il 6.14 for Testing : ToolSupport for Testing
ST&QA- MCA (Mgt.) Sem
lll 6.15
6
is developed and supported by Sauce Labs to automate native and hrhts
mobile apps. 7. Which are Risks using tools?

(a) Selenium Webdríver (b) TestNG o.lI Answer the following questions.
(c)
Appium (d) JMeter
1. Explain Appium testing tool.
7 is a Java desktop application with a
graphical interface that uses the Swing
2. What are advantages of TestNG?
graphical API. 3. How JMeter Works?
(a) JMeter
(b) TestNG 4. Write the difference between Webdriver and TestNG tools,
(c) Appium
(d) Webdriver 5. Explain how to introduce a testing Tool into organization?
8. Appium is an HTIP server
that is written in 0.III Write a short note on:
(a) XML
(b) PHP 1. Potential benefits of using testing tools.
(c) Node.js
(d) C 2. WebDriver Architecture
9. In testing tools, CAST stand
for 3. Advarntages of Appium testing tool
(a) Certified Associate
in Software Testing 4. Features
(b) Certified Associate
of JMeter
in Software Technology
(c)
Certified Associate in System
Testing
(d) Classified Associate
in Software Testing
10. On which parameter,
testing tools can be classified?
(a) Purpose of the tool.
(b) Activities that are
supported within the tool
(c) Type/level of testing it supports.
(d) All of the above

ANSWERS
1. (b) 2. (a) 3. (a) 4. (d) 5. (b) 6. (c) 7. (a) 8. (c)
9. (a) 10. (d)

PracticeQuestions
Q.I Answer the following
questions in short.
1. What is TestNG?
2. Is the cast science test mandatory?
3. What is cast in testing?
4. Which are types of testing tools?
5
How to classify testing tools?
6. Write applications of testing tools?