UNIT-I

Basics of Software Testing and

Testing Methods

Marks-14
1.1 Software Quality, Definition of Software
Testing
• Role of Testing1 Software Quality,Definition(s) of Quality:Predictable
degree of uniformity, dependability at low cost and suited to
[Link] to which a set of inherent characteristics of the
product / service fulfills the [Link] to a product or
service that bears upon its ability to satisfy implied or expressed
needQuality is:Fitness for use, i.e. Usability of [Link]
to specificationJudgment of the customer /user about the attributes
of a [Link] customer as per national/ international
standardsFulfill customers need as max as [Link] quality
is: the degree to which a system, component, or process meets
specified requirements.
Fundamental principles of testing are:
• Find defects before customers find them [Link] testing not
possible; Program testing can only show the presence of defects,
never their [Link] applied all through the software life
cycleUnderstand the reason behind the [Link] the tests [Link]
develop immunity and have to be revised [Link] occur in
convoy or clusters, and testing, should focus on those [Link]
encompasses defect [Link] is a fine balance of defect
prevention and defect [Link] and well-planned
automation - Benefits of [Link] talented, committed people
who work in teams.
Goals of Software Testing
• Testing produces reliability and qualityQuality leads to customer
satisfactionImmediate Goals:Bug DiscoveryBug PreventionThe major
objectives of Software testing are as follows:Finding defects which may get
created by the programmer while developing the [Link]
confidence in and providing information about the level of [Link] prevent
[Link] make sure that the end result meets the business and user
[Link] ensure that it satisfies the BRS that is Business Requirement
Specification and SRS that is System Requirement [Link] gain the
confidence of the customers by providing them a quality [Link]-term
Goals:ReliabilityQualityCustomer satisfactionRisk ManagementPost-
Implementation Goals:Reduced maintenance costImproved testing process
Roles And Responsibilities of A Test Leader
• Involved in the planning, monitoring, and controlDevise the test objectives, organizational test policies,
test strategies and test [Link] the testing, and management to acquire the necessary
[Link] when test automation is appropriate, select the tools, and ensure training of the
team. Testers lead, guide and monitor the analysis, design, implementation and execution of the test
cases, test procedures and test [Link] proper configuration management of the test-ware
produces traceability of the [Link] the tests for execution and monitor, measure, control and
report on the test progress, the product quality status and the test [Link] summary reports on
test [Link] leaders also known as Test Manager or Test Coordinator

• 6 Bug TerminologyBug: defined in simple term as any error or mistake that leads to the failure of the
product or software either due to the specification problem or due to communication problem,
regarding what is developed and what had to be [Link] Terminology: Failure, Error, FaultThe
various terms related to software failure with respect to the area of application are listed as Defect,
Variance, Fault, Failure, Problem, Inconsistency, Error, Feature, Incident, Bug, and Anomaly.i. Problem,
error, and bug are probably the most generic terms [Link]. Anomaly, incident, and variance don’t sound
quite so negative and infer more unintended operation than an all-out failure.
Causes Of Software Defects
• Some of them are:Faulty requirements definitionClient-developer
communication failuresDeliberate deviations from software
requirementsLogical design errorsCoding errorsNon-compliance with
documentation and coding instructionsShortcomings of the testing
processUser interface and procedure errorsDocumentation errors
Test Scenario and its design aspect
• Test cases are written using test scenario. It describes each
transaction and expected result of each transaction included in test
[Link] cases are executed through test [Link] (Person,
system, hardware, or software) are taking part in transaction. (Simple,
Complex, Average Actors),Transactions represent the interactions of
the actors with system under [Link] case characteristics:
Accurate, Economical, Real, and reusable, Traceable to requirements,
Appropriate, Self standing, Self-cleaning… etc.)
How to write a good test case?
• Test case is an important document from validation of system
perspective. These must be written at each stage of validation from
unit test till acceptance [Link] principles of writing a good test
case are:Must be [Link] is to be done when to wait for system
to do it?Inform tester each transaction displayed/ replied by the
system on screen at each step. And wait for user [Link] simple
conversational language for writing test case, which improves clarity
and avoid communication [Link] consistent names of fields must
be used in place of generic names. Any change in field name must be
incorporated in test [Link] should aware windows [Link]
of the test cases must follow business scenario. Avoid time wastage,
Basic principles of writing a good test case
• Test case must be [Link] should know what is to be done
when to wait for system to do [Link] tester each transaction
displayed/ replied by the system on screen at each step. And wait for
user [Link] simple conversational language for writing test
case, which improves clarity and avoid communication [Link]
consistent names of fields must be used in place of generic names.
Any change in field name must be incorporated in test [Link]
should aware windows [Link] of the test cases must follow
business scenario. Avoid time wastage,
Common Mistakes in writing test cases
• Making test cases too long and combining two or more test cases in single
test should be avoidedIncomplete, incorrect, and incoherent test cases
can create confusion and frustrate [Link] should be made very
clear in test case [Link] case changes must be updated in software
user [Link] pass/fail criteria correctly, i.e. test are successful or
not, there is a defect or not?Essential activities in Testing:Maintain test
strategy, test plan, test scenario and test cases in a location so that they
are available to concerned people when required for test [Link]
configuration management standards, and reasons for updates, Test cases
used for testing must be reviewed before using them.
Entry and Exit Criteria related to Testing
• Sample Criteria For Component TestingEntry CriteriaExit
CriteriaPeriodic unit test progress report showing 70% completion
rateNo extreme and critical outstanding defects in featuresStable
build with basic features workingAll 100% components test executed
with at least 98% pass [Link] test cases can ready for
executionComponent test progress report and defect trends sorted
based on features and analyzed---Component level performance and
load testing report and analysis of the same
Exit Criteria for Validation Testing
• When to Start and Stop Testing of Software (Entry and Exit Criteria)Process
model - way to represent any given phase of software development that
prevent and minimize the delay between defect injection and defect
detection/[Link] criteria –specifies when that phase can be
started also included are the inputs for the [Link] or steps that need to
be carried out in that phase, along with measurements that characterize the
[Link], which specifies methods of checking that tasks have been
carried out [Link] criteria, which stipulate the conditions under which
one can consider the phases as done and included are the outputs for only
the [Link] is known as the Entry Task Verification exit or EVTX model
which offers several advantages for effective verification and [Link]
entry criteria make sure that a given phase does not start prematurely.
Exit Criteria for Validation Testing
• All test scripts have been [Link] Software Planning Resolutions
have been satisfactorily resolved. (Resolution could include bugs
being fixed, deferred to a later release, determined not to be bugs,
etc.) All parties must agree to the resolution. This criterion could be
further defined to state that all high-priority bugs must be fixed while
lower-priority bugs can be handled on a case-by-case [Link]
changes made as a result of SPRs have been [Link] documentation
associated with the software (such as SRS, SDD, test documents) has
been updated to reflect changes made during validation [Link]
test report has been reviewed and approved.
 Software quality assurance is:
• Software engineering is systematic, disciplined and quantitative approach at its
core, makes the software engineering environment a good infrastructure for
achieving SQA [Link] methodologies and tools applied, to a considerable
extent, the level of quality to be expected from the software process and the
maintenance services. Software quality assurance is:A systematic, planned set of
actions necessary to provide adequate confidence that the software development
process or the maintenance process of a software system product conforms to
established functional technical requirements as well as with the managerial
requirements of keeping the schedule and operating within the budgetary
confines.A planned and systematic pattern of all actions necessary to provide
adequate confidence that an item or product conforms to established technical
requirements.A set of activities designed to evaluate the process by which the
products are developed or manufactured. Contrast with: quality control
Quality Assurance Quality Control
• Concentrates on the process of producing the
[Link] on specific productDefect-prevention
[Link]-detection and correction-orientedUsually done
throughout the life [Link] done after the product is
buildThis is usually a staff functionThis is usually a line
functioni.e. Reviews and Auditsi.e. Software testing at various
[Link] on the process of producing the
[Link] on specific productDefect-prevention
[Link]-detection and correction-orientedUsually done
throughout the life [Link] done after the product is
buildThis is usually a staff functionThis is usually a line
functioni.e. Reviews and Auditsi.e. Software testing at various
levels.
V-Model
 V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC must
complete before the next phase starts. It follows a sequential design process same as the
waterfall model. Testing of the device is planned in parallel with a corresponding stage of
development.

Verification: It involves a static analysis method (review) done without executing code. It is the process of evaluation of the product
development process to find whether specified requirements meet.
Validation: It involves dynamic analysis method (functional, non-functional), testing is done by executing code. Validation is the process to
classify the software after the completion of the development process to determine whether the software meets the customer expectations and
requirements.
So V-Model contains Verification phases on one side of the Validation phases on the other side. Verification and Validation process is joined by
coding phase in V-shape. Thus it is known as V-Model.

There are the various phases of Verification Phase of V-model:

Business requirement analysis: This is the first step where product requirements understood from the
customer's side. This phase contains detailed communication to understand customer's expectations and
exact requirements.
System Design: In this stage system engineers analyze and interpret the business of the proposed system
by studying the user requirements document.
Architecture Design: The baseline in selecting the architecture is that it should understand all which
typically consists of the list of modules, brief functionality of each module, their interface relationships,
dependencies, database tables, architecture diagrams, technology detail, etc. The integration testing model
Module Design: In the module design phase, the system breaks down into small modules. The detailed design of the
modules is specified, which is known as Low-Level Design
Coding Phase: After designing, the coding phase is started. Based on the requirements, a suitable programming
language is decided. There are some guidelines and standards for coding. Before checking in the repository, the final
build is optimized for better performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

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 unit level. A unit is the smallest entity which can independently exist, e.g.,
a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of
the codes/ units.
Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These tests verify that
groups created and tested independently can coexist and communicate among themselves.
System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans,
System Tests Plans are composed by the client?s business team. System Test ensures that expectations from an
application developer are met.
[Link] Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.
Advantages / Disadvantages & usage of V-Model
Advantages of V-model:Disadvantages of V-model:Simple and easy to [Link] activities like
planning, test designing happens well before [Link] a lot of [Link] chance of success
over the waterfall [Link] defect tracking – that is defects are found at early [Link]
the downward flow of the [Link] well for small projects where requirements are easily
[Link] rigid and least [Link] is developed during the implementation phase, so
no early prototypes of the software are [Link] any changes happen in midway, then the test
documents along with requirement documents has to be [Link] to use the V-model:The V-
shaped model should be used for small to medium sized projects where requirements are clearly
defined and [Link] V-Shaped model should be chosen when ample technical resources are
available with needed technical expertise.