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
market.Degree to which a set of inherent characteristics of the
product / service fulfills the requirement.Ability to a product or
service that bears upon its ability to satisfy implied or expressed
needQuality is:Fitness for use, i.e. Usability of software.Conformance
to specificationJudgment of the customer /user about the attributes
of a product.Meet customer as per national/ international
standardsFulfill customers need as max as possible.Software 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 out.Exhaustive testing not
possible; Program testing can only show the presence of defects,
never their absence.Testing applied all through the software life
cycleUnderstand the reason behind the test.Test the tests first.Tests
develop immunity and have to be revised constantly.Defects occur in
convoy or clusters, and testing, should focus on those clusters.Testing
encompasses defect prevention.Testing is a fine balance of defect
prevention and defect detection.Intelligent and well-planned
automation - Benefits of testing.Requires 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 software.Gaining
confidence in and providing information about the level of quality.To prevent
defects.To make sure that the end result meets the business and user
requirements.To ensure that it satisfies the BRS that is Business Requirement
Specification and SRS that is System Requirement Specifications.To gain the
confidence of the customers by providing them a quality product.Long-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 plans.Estimate the testing, and management to acquire the necessary
resources.Recognize 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 suites.Ensure proper configuration management of the test-ware
produces traceability of the tests.Schedule the tests for execution and monitor, measure, control and
report on the test progress, the product quality status and the test results.Write summary reports on
test status.Test 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 developed.Bug 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 used.ii. 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
scenario.Test cases are executed through test data.Actors (Person,
system, hardware, or software) are taking part in transaction. (Simple,
Complex, Average Actors),Transactions represent the interactions of
the actors with system under testing.Test 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 testing.Basic principles of writing a good test
case are:Must be testable.What 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 response.Use simple
conversational language for writing test case, which improves clarity
and avoid communication losses.Use consistent names of fields must
be used in place of generic names. Any change in field name must be
incorporated in test cases.Tester should aware windows basics.Order
of the test cases must follow business scenario. Avoid time wastage,
Basic principles of writing a good test case
• Test case must be testable.Tester should know what 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 response.Use simple conversational language for writing test
case, which improves clarity and avoid communication losses.Use
consistent names of fields must be used in place of generic names.
Any change in field name must be incorporated in test cases.Tester
should aware windows basics.Order 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 testers.Steps should be made very
clear in test case steps.Test case changes must be updated in software
user interface.Define 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 artifacts.Follow
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 ratio.Component 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/correction.Entry criteria –specifies when that phase can be
started also included are the inputs for the phase.Tasks or steps that need to
be carried out in that phase, along with measurements that characterize the
tasks.Verification, which specifies methods of checking that tasks have been
carried out correctly.Exit criteria, which stipulate the conditions under which
one can consider the phases as done and included are the outputs for only
the phase.This is known as the Entry Task Verification exit or EVTX model
which offers several advantages for effective verification and validation.Clear
entry criteria make sure that a given phase does not start prematurely.
Exit Criteria for Validation Testing
• All test scripts have been executed.All 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 basis.All
changes made as a result of SPRs have been tested.All documentation
associated with the software (such as SRS, SDD, test documents) has
been updated to reflect changes made during validation testing.The
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 objectives.The 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
product.Concentrates on specific productDefect-prevention
oriented.Defect-detection and correction-orientedUsually done
throughout the life cycle.Usually 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.Concentrates on the process of producing the
product.Concentrates on specific productDefect-prevention
oriented.Defect-detection and correction-orientedUsually done
throughout the life cycle.Usually 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.
1.Acceptance 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 use.Testing activities like
planning, test designing happens well before coding.Saves a lot of time.Higher chance of success
over the waterfall model.Proactive defect tracking – that is defects are found at early stage.Avoids
the downward flow of the defects.Works well for small projects where requirements are easily
understood.Very rigid and least flexible.Software is developed during the implementation phase, so
no early prototypes of the software are produced.If any changes happen in midway, then the test
documents along with requirement documents has to be updated.When to use the V-model:The V-
shaped model should be used for small to medium sized projects where requirements are clearly
defined and fixed.The V-Shaped model should be chosen when ample technical resources are
available with needed technical expertise.