Software Testing

MODULE-IMODULE-I
SOFTWARE TESTING BASICSSOFTWARE TESTING BASICS

DefinitionsDefinitions
 Testing is the process of exercising aTesting is the process of exercising a
program with the specific intent of findingprogram with the specific intent of finding
errors prior to delivery to the end user.errors prior to delivery to the end user.
 ““The process ofThe process of analyzing a softwareanalyzing a software item toitem to
detect the differences between existing anddetect the differences between existing and
required conditions (required conditions (i.e.,i.e., bugsbugs) and) and to evaluateto evaluate
the features ofthe features of thethe software item”software item” (IEEE-1993)(IEEE-1993)
 ““The process of analyzing a program with theThe process of analyzing a program with the
intent of finding errors” (intent of finding errors” (Myers 1979Myers 1979))
2201/24/1901/24/19

Software Testing…Software Testing…
Mission Critical SystemsMission Critical Systems
failure is simply unacceptable.failure is simply unacceptable.
send a patch and tell install itsend a patch and tell install it
please shutdown and rebootplease shutdown and reboot
ad-hoc approachad-hoc approach
hit and miss approachhit and miss approach
Banks, Air traffic control, pace maker, medicalBanks, Air traffic control, pace maker, medical
instrumentsinstruments
01/24/1901/24/19 33

 It should focus on finding defects beforeIt should focus on finding defects before
customers find themcustomers find them
 It can only prove the presence of defects,It can only prove the presence of defects,
never their absence.never their absence.
 A test in time…A test in time…
01/24/1901/24/19 44

A saint sat meditating. A cat that was prowlingA saint sat meditating. A cat that was prowling
around was disturbing his concentration. Hencearound was disturbing his concentration. Hence
he asked his disciples to tie the cat to a pillar whilehe asked his disciples to tie the cat to a pillar while
he meditates. This sequence of events became ahe meditates. This sequence of events became a
daily routine. The tradition continued over thedaily routine. The tradition continued over the
years with the saint’s descendent and cat’syears with the saint’s descendent and cat’s
descendent. One day, there were no cat in thedescendent. One day, there were no cat in the
hermitage. The disciples got panicky and searchedhermitage. The disciples got panicky and searched
for a cat, saying,for a cat, saying, “We need a cat. Only when we“We need a cat. Only when we
get a cat, we can tie it to a pillar and only afterget a cat, we can tie it to a pillar and only after
that can the saint start meditating!”that can the saint start meditating!”
01/24/1901/24/19 55

Theme:Theme:
““ Why one testsWhy one tests is as important asis as important as what to testwhat to test
andand how to testhow to test.”.”
01/24/1901/24/19 66

An audiologist was testing a patient, telling her, “I want toAn audiologist was testing a patient, telling her, “I want to
test the range within which you can hear. I will ask youtest the range within which you can hear. I will ask you
from various distances to tell me your name and youfrom various distances to tell me your name and you
should tell me your name. Please turn back andshould tell me your name. Please turn back and
answer”. The patient understood what needs to be done.answer”. The patient understood what needs to be done.
Doctor(from 30 feet):Doctor(from 30 feet): What is your name?What is your name?
……..
Doctor (from 20 feet):Doctor (from 20 feet): What is your name?What is your name?
……..
Doctor( from 10 feet) :Doctor( from 10 feet) : What is your name?What is your name?
Patient: For the third time, let me repeat, my name isPatient: For the third time, let me repeat, my name is
Ramesh.Ramesh.
01/24/1901/24/19 77

Theme:Theme:
““ Test the tests firstTest the tests first- a defective test is more- a defective test is more
dangerous than a defective product”dangerous than a defective product”
01/24/1901/24/19 88

 How do you test a system?How do you test a system?
 Input test dataInput test data to the system.to the system.
 Observe the outputObserve the output::
 Check if the systemCheck if the system behaved as expected orbehaved as expected or
not?not?
 If the programIf the program does not behave as expecteddoes not behave as expected::
 note thenote the conditionsconditions under which it failed.under which it failed.
 laterlater debugdebug andand correctcorrect..
9901/24/1901/24/19

 Overview ofOverview of Testing ActivitiesTesting Activities
--Test Suite DesignTest Suite Design
--Run test cases and observe results toRun test cases and observe results to
detect failures i.e. test executiondetect failures i.e. test execution
-Test case evaluation/comparison-Test case evaluation/comparison
101001/24/1901/24/19

111101/24/1901/24/19

 Error, Faults, and FailuresError, Faults, and Failures
-A failure is a manifestation of an error (defect-A failure is a manifestation of an error (defect
or bug ).or bug ).
–– Mere presence of an error may not lead to aMere presence of an error may not lead to a
failure.failure.
-- A fault is an incorrect state entered duringA fault is an incorrect state entered during
program execution:program execution:
–– A variable value is different from what it shouldA variable value is different from what it should
be.be.
-- A fault may or may not not lead to a failureA fault may or may not not lead to a failure
121201/24/1901/24/19

Error, Faults, and Failures…Error, Faults, and Failures…
 IEEE DefinitionsIEEE Definitions
FailureFailure:: External behavior is incorrectExternal behavior is incorrect
Fault:Fault: Discrepancy in code that causes a failure.Discrepancy in code that causes a failure.
Error:Error: Human mistake that caused faultHuman mistake that caused fault
01/24/1901/24/19 1313

(Test Case Design)(Test Case Design)
Test a software using a set of carefully designedTest a software using a set of carefully designed
test cases:test cases:
––The set of all test cases is called theThe set of all test cases is called the test suitetest suite..
●● A test case is a triplet [A test case is a triplet [I,S,OI,S,O]]
–– II is the data to be input to the system,is the data to be input to the system,
–– SS is the state of the system at which the datais the state of the system at which the data
will be input,will be input,
–– OO is the expected output of the system.is the expected output of the system.
141401/24/1901/24/19

 If test cases are selectedIf test cases are selected randomlyrandomly::
–– Many test cases wouldMany test cases would not contributenot contribute to theto the
significance of the test suitesignificance of the test suite,,
–– Would not detect errors not already beingWould not detect errors not already being
detected by other test cases in the suite.detected by other test cases in the suite.
●● Number ofNumber of test cases in a randomly selectedtest cases in a randomly selected
test suite:test suite:
–– Not an indication of effectiveness of testingNot an indication of effectiveness of testing
151501/24/1901/24/19

Testing a system using a large number ofTesting a system using a large number of
randomly selected test cases:randomly selected test cases:
–– Does not mean that many errors in theDoes not mean that many errors in the
system will be uncovered.system will be uncovered.
●● Consider following example:Consider following example:
–– Find the maximum of two integers x and y.Find the maximum of two integers x and y.
161601/24/1901/24/19

The code has a simple programming error:The code has a simple programming error:
●● if (x>y) max = x; else max = x;if (x>y) max = x; else max = x;
Test Suits:Test Suits:
●● {(x=3,y=2);(x=2,y=3)}{(x=3,y=2);(x=2,y=3)}
●● {(x=3,y=2);(x=4,y=3);(x=5,y=1);(x=23,y=-3)}{(x=3,y=2);(x=4,y=3);(x=5,y=1);(x=23,y=-3)}
171701/24/1901/24/19

 Systematic approaches are required toSystematic approaches are required to
design an optimal test suite:design an optimal test suite:
–– Each test case in the suiteEach test case in the suite should detectshould detect
different errors.different errors.
 An optimal test suite:An optimal test suite:
–– OfOf reasonable sizereasonable size andand
–– Uncovers as many errors as possible.Uncovers as many errors as possible.
181801/24/1901/24/19

191901/24/1901/24/19

 Positive Test Case(Successful)Positive Test Case(Successful)
 Negative Test Case(Unsuccessful)Negative Test Case(Unsuccessful)
202001/24/1901/24/19

212101/24/1901/24/19

222201/24/1901/24/19

232301/24/1901/24/19

Test DataTest Data
 ExhaustiveExhaustive testing of real life program is nevertesting of real life program is never
possible.possible.
““A program accepts a six-character code and it isA program accepts a six-character code and it is
to be ensured that first character is numericto be ensured that first character is numeric
and rests of the character are alphanumericand rests of the character are alphanumeric.”.”
01/24/1901/24/19 2424

Test Data…Test Data…
Valid Inputs:Valid Inputs: 9,161,328,3209,161,328,320
Time: AboutTime: About 2905 years2905 years
01/24/1901/24/19 2525

Test ScenarioTest Scenario
01/24/1901/24/19 2626

Test ScenarioTest Scenario
 Test ScenarioTest Scenario
Staff enters customer informationStaff enters customer information
 Test CaseTest Case
a. Enter customer information(Name, address, ph no)a. Enter customer information(Name, address, ph no)
b. Click on save.b. Click on save.
01/24/1901/24/19 2727

Verification Vs Validation…Verification Vs Validation…
 Verification (Process Oriented)Verification (Process Oriented)
 Is the process of determining whether the output ofIs the process of determining whether the output of
one phase of software development conforms toone phase of software development conforms to
that of its previous phasethat of its previous phase
 Refers to the set of activities that ensure thatRefers to the set of activities that ensure that
software correctly implements a specific functionsoftware correctly implements a specific function
 It is a static testing strategies.It is a static testing strategies.
 Involves code walk-through, Inspections andInvolves code walk-through, Inspections and
reviewsreviews
282801/24/1901/24/19

 CODE REVIEWCODE REVIEW
 It is done after the moduleIt is done after the module successfullysuccessfully
compiledcompiled andand all syntax errors areall syntax errors are
eliminated.eliminated.
 Used forUsed for reducing coding errorreducing coding error..
01/24/1901/24/19 2929

 Code Walk-ThroughCode Walk-Through
 It is anIt is an informal code analysis techniqueinformal code analysis technique
 Main objective is to discover theMain objective is to discover the algorithmicalgorithmic
and logical errorsand logical errors in the code.in the code.
 Some developers are given the code to readSome developers are given the code to read
and understand before the code walk-throughand understand before the code walk-through
meeting.meeting.
 Each member of the team selects someEach member of the team selects some testtest
cases to simulatecases to simulate the execution manually.the execution manually.
01/24/1901/24/19 3030

 Code Walk-Through…Code Walk-Through…
 The members note down their findings to beThe members note down their findings to be
discussed in adiscussed in a walk-through meetingwalk-through meeting wherewhere
thethe codercoder is also present.is also present.
 Guidelines:Guidelines:
.team should contain.team should contain threethree toto sevenseven
members.members.
.discussion should be on.discussion should be on discovery of errorsdiscovery of errors
not on how to fix it.not on how to fix it.
..managermanager should not attend the meetingshould not attend the meeting
01/24/1901/24/19 3131

 Code InspectionCode Inspection
-to discover some-to discover some common typecommon type of errorsof errors
due todue to oversightoversight oror improperimproper programmingprogramming
-Good s/w companies collect statistics to-Good s/w companies collect statistics to
identify the type ofidentify the type of errors most frequentlyerrors most frequently
committedcommitted by their engineers.by their engineers.
01/24/1901/24/19 3232

 Code Inspection…Code Inspection…
-classical programming error are:-classical programming error are:
.use of.use of uninitializeduninitialized variables.variables.
..JumpsJumps into loopsinto loops
..Non terminatingNon terminating loopsloops
..IncompatibleIncompatible assignmentsassignments
.Array indices.Array indices out of boundout of bound
.Improper.Improper storage locationstorage location
01/24/1901/24/19 3333

Validation (Product oriented)Validation (Product oriented)
 Is the process of determining whether the fully developedIs the process of determining whether the fully developed
system conforms to its requirement specifications.system conforms to its requirement specifications.
 Refers to a different set of activities that ensure that theRefers to a different set of activities that ensure that the
software that has been build is traceable to customersoftware that has been build is traceable to customer
requirementrequirement
 Aim is to ensure that the final product is error free.Aim is to ensure that the final product is error free.
 RequireRequire Black Box testing techniquesBlack Box testing techniques
343401/24/1901/24/19

Testing Life Cycle and V-modelTesting Life Cycle and V-model
 Similar to theSimilar to the Waterfall ModelWaterfall Model
 The new perspective that the V Model bringsThe new perspective that the V Model brings
in is thatin is that different types of testing apply atdifferent types of testing apply at
different leveldifferent level..
 Splits intoSplits into twotwo parts-parts- designdesign andand executionexecution
 DesignDesign donedone earlyearly where aswhere as executionexecution donedone
only at theonly at the endend of the life cycle.of the life cycle.
01/24/1901/24/19 3636

Testing Life Cycle and V-model…Testing Life Cycle and V-model…
01/24/1901/24/19 3737

01/24/1901/24/19 3838

01/24/1901/24/19 3939

Levels of TestingLevels of Testing
 Unit TestingUnit Testing
 Integration TestingIntegration Testing
 System TestingSystem Testing
 Acceptance TestingAcceptance Testing
 Regression testingRegression testing
01/24/1901/24/19 4040

Unit TestingUnit Testing
 A unit is smallest testable piece of softwareA unit is smallest testable piece of software
can be compiled, linked, loadedcan be compiled, linked, loaded
e.g. functions/procedures, classes, interfacese.g. functions/procedures, classes, interfaces
––normally done by programmernormally done by programmer
––Test cases written after codingTest cases written after coding
••DisadvantageDisadvantage
Test cases written to suit programmer’s‐Test cases written to suit programmer’s‐
implementation (not necessarily specification)implementation (not necessarily specification)
 ••Better to use “Better to use “Buddy TestingBuddy Testing””
01/24/1901/24/19 4141

Unit Testing…Unit Testing…
Buddy TestingBuddy Testing
 Team approach to coding and testingTeam approach to coding and testing
 One programmer codes the other tests and viceOne programmer codes the other tests and vice
versaversa
 Test cases written by tester(before coding starts)‐Test cases written by tester(before coding starts)‐
01/24/1901/24/19 4242

 It focuses on theIt focuses on the verification effortverification effort on theon the
smallest unit of software designsmallest unit of software design, i.e. the, i.e. the
softwaresoftware component or modulescomponent or modules..
 It focuses on theIt focuses on the internal processing logic andinternal processing logic and
data structuredata structure within the boundaries of awithin the boundaries of a
componentcomponent..
 Unit testing isUnit testing is simplifiedsimplified whenwhen high cohesionhigh cohesion
is designed.is designed.
01/24/1901/24/19 4343

01/24/1901/24/19 4444

Integration TestingIntegration Testing
 The primary objective of integration testing is toThe primary objective of integration testing is to testtest
the module interfacethe module interface in order toin order to ensure that there areensure that there are
no errors in the parameter passing, when one moduleno errors in the parameter passing, when one module
invokes another moduleinvokes another module..
 In integration testing,In integration testing, different modules making ofdifferent modules making of
the system are integratedthe system are integrated in a planned manner usingin a planned manner using
an integration plan.an integration plan.
 Two Strategies:Two Strategies:
 Phased integration testingPhased integration testing
 Incremental integration testingIncremental integration testing
01/24/1901/24/19 4545

Integration Testing…Integration Testing…
 Phased integrationPhased integration
 AA group of related modules are addedgroup of related modules are added, each time, to the, each time, to the
partial system under test.partial system under test.
 Incremental integrationIncremental integration
 OnlyOnly one new module is addedone new module is added, each time, to the partial, each time, to the partial
system under test.system under test.
Different approaches for integration testing:Different approaches for integration testing:
 Big-bang approachBig-bang approach
 Top-down approachTop-down approach
 Bottom–up approachBottom–up approach
 Mixed approachMixed approach
01/24/1901/24/19 4646

01/24/1901/24/19 4747

 Top Down IntegrationTop Down Integration
01/24/1901/24/19 4848

 Bottom-Up IntegrationBottom-Up Integration
01/24/1901/24/19 4949

 Sandwich TestingSandwich Testing
01/24/1901/24/19 5050

System Testing: Alpha and BetaSystem Testing: Alpha and Beta
TestingTesting
 TheThe alpha testalpha test isis conducted at theconducted at the
developer’s site by end users.developer’s site by end users.
 The alpha test is conducted in a controlledThe alpha test is conducted in a controlled
environment.environment.
 TheThe beta testbeta test isis conducted at the end-user’sconducted at the end-user’s
site and done by the end usersite and done by the end user..
 Beta test is aBeta test is a ““livelive” application” application of the softwareof the software
in an environment that can not be controlledin an environment that can not be controlled
by the developerby the developer..
01/24/1901/24/19 5151

Acceptance Testing..Acceptance Testing..
 Demonstrates satisfaction of userDemonstrates satisfaction of user
 Users are essential part of processUsers are essential part of process
 Usually merged with System TestingUsually merged with System Testing
 Done by test team and customerDone by test team and customer
 Done in simulated environment/realDone in simulated environment/real
environmentenvironment
01/24/1901/24/19 5252

Object Oriented TestingObject Oriented Testing
 More than 50% of development effort is beingMore than 50% of development effort is being
spent on testing.spent on testing.
 Quality and effective reuse of software dependQuality and effective reuse of software depend
to a large extent:to a large extent:
 on thorough testing.on thorough testing.
 It was expected during initial years that OOIt was expected during initial years that OO
would help substantially reduce testing effort:would help substantially reduce testing effort:
 But, as we find it out today --- it only complicatesBut, as we find it out today --- it only complicates
testing.testing.
01/24/1901/24/19 5353

Issue in Object Oriented SystemIssue in Object Oriented System
 An object-oriented system is activated throughAn object-oriented system is activated through
message passing. So it should be ensured thatmessage passing. So it should be ensured that
all the inter-object and intra-object messageall the inter-object and intra-object message
dependencies are taken care of.dependencies are taken care of.
01/24/1901/24/19 5454

Issue in Object Oriented System…Issue in Object Oriented System…
 Inheritance ensures reusability by whichInheritance ensures reusability by which
several repeatable tasks in object–orientedseveral repeatable tasks in object–oriented
programming can be eliminated. But at theprogramming can be eliminated. But at the
same time deep class hierarchy increases thesame time deep class hierarchy increases the
testing burden. This increases the cost oftesting burden. This increases the cost of
testing.testing.
01/24/1901/24/19 5555

 Polymorphism is another issue. InPolymorphism is another issue. In
polymorphism due to run time binding, thepolymorphism due to run time binding, the
invocation of a method is unknown until runinvocation of a method is unknown until run
time. So it is becomes difficult for creation oftime. So it is becomes difficult for creation of
integration test plan.integration test plan.
01/24/1901/24/19 5656

 AbstractAbstract andand genericgeneric classes provide importantclasses provide important
means for code reuse. But as they don’tmeans for code reuse. But as they don’t
provide instance of them, to test them becomesprovide instance of them, to test them becomes
a problem. Many of the times in inheritance,a problem. Many of the times in inheritance,
classes used in the root are declared asclasses used in the root are declared as
abstract, in such cases any fault in the abstractabstract, in such cases any fault in the abstract
class can percolate down in the inheritanceclass can percolate down in the inheritance
hierarchy and results in multiple bugs.hierarchy and results in multiple bugs.
01/24/1901/24/19 5757

 Encapsulation results another problem in OOEncapsulation results another problem in OO
testing as debugger being an externaltesting as debugger being an external
procedure it can’t access the private attributeprocedure it can’t access the private attribute
values present in a class.values present in a class.
01/24/1901/24/19 5858

Code Based Testing(Evolution of S/W Testing)Code Based Testing(Evolution of S/W Testing)
01/24/1901/24/19 5959
Manual
Test design
and
Automated
Execution
Scripting
Manual
Test design
and
Execution
Capture and
Replay
Model-Based
Testing
Automated
Test design
and
Execution
1960-1990 1990-2000 2000-

Code Based Testing (CFG)Code Based Testing (CFG)
 ExampleExample Control Flow GraphControl Flow Graph
int f1(int x,int y){int f1(int x,int y){
1 while (x != y){1 while (x != y){
2 if (x>y) then2 if (x>y) then
3 x=x-y;3 x=x-y;
4 else y=y-x;4 else y=y-x;
5 }5 }
6 return x; }6 return x; }
01/24/1901/24/19 6060

Code Based Testing (CFG)…Code Based Testing (CFG)…
 Derivation of Test CasesDerivation of Test Cases
 Let us discuss the stepsLet us discuss the steps to derive pathto derive path
coverage-based test cases of a program.coverage-based test cases of a program.
 Draw control flow graph.Draw control flow graph.
 Determine V(G).Determine V(G).
 Determine the set of linearly independentDetermine the set of linearly independent
paths.paths.
 Prepare test cases to force execution alongPrepare test cases to force execution along
each path.each path.
01/24/1901/24/19 6161

Code vs. Model Based Testing…Code vs. Model Based Testing…
 Most of the application do integrate some third partyMost of the application do integrate some third party
tools over it’s API. We don’t have access to thattools over it’s API. We don’t have access to that
code base.code base.
 We don’t have access to the code of CompilerWe don’t have access to the code of Compiler
 We don’t have access to code of rum time engineWe don’t have access to code of rum time engine
that executes our application codethat executes our application code
 We don’t have access to the code of OperatingWe don’t have access to the code of Operating
System Services on top of which the applicationSystem Services on top of which the application
runsruns
01/24/1901/24/19 6262

 Certain aspects of behavior of a system areCertain aspects of behavior of a system are
difficult to extract from code but are easilydifficult to extract from code but are easily
obtained from design model.obtained from design model.
 Code based software testing is inadequate inCode based software testing is inadequate in
component based software development, sincecomponent based software development, since
the source code may not be available to thethe source code may not be available to the
developer.developer.
 Test case generation process is delayed till theTest case generation process is delayed till the
coding is over.coding is over.
01/24/1901/24/19 6363

 Testing techniques can be applied throughoutTesting techniques can be applied throughout
the development process the basis ofthe development process the basis of
requirement specification and design models.requirement specification and design models.
 Test cases are available early in the softwareTest cases are available early in the software
development cycle making the test planningdevelopment cycle making the test planning
more effective.more effective.
 Efficient algorithms for graph processing existEfficient algorithms for graph processing exist
as compared to text processing.as compared to text processing.
 The generated test data is independent of anyThe generated test data is independent of any
particular implementation of design.particular implementation of design.
01/24/1901/24/19 6464

Model Based TestingModel Based Testing
01/24/1901/24/19 6565
Run Result
Derive
Generate
Pass
Fail
Model
Implementation
Test Cases
Test Oracle Report
specification
Automated
Construction

Model DrivenModel Driven
Development(MDD)Development(MDD)
01/24/1901/24/19 6666

Activities in Model Based TestingActivities in Model Based Testing
01/24/1901/24/19 6767
Test Plan
Model
Test Case Generator
Test Cases
Test Script Generator
Test Scripts
Adaptor
Test Execution Tool
System under Test
Test Results
Requirements Traceability Matrix
Model Coverage
Requirements
1. Model
2. Generate
3. Concretize
5. Analyze
4. Execute

Model Based Testing : A Case StudyModel Based Testing : A Case Study
01/24/1901/24/19 6868

Sequence Diagram of PIN Authentication System
[M.Sharma, D.Kundu, R.Mall, Automatic Test case Generation From UML sequence Diagrams 15th
International
Conference on Advanced Computing and communications , IEEE pages 60-65 2007]

Sequence Diagram Graph of PIN Authentication System
Operation Scenario of Sequence Diagram
International

Test name = “ATM PIN Validation”Test name = “ATM PIN Validation” Test case :scenario 4Test case :scenario 4
Preconditions: ATM is idle and displaying a Input: Card = “ATM”, Status = “Okay”, welcomePreconditions: ATM is idle and displaying a Input: Card = “ATM”, Status = “Okay”, welcome
message. “User inserts a card “message. “User inserts a card “ Account = “Open”, PIN = “Invalid”Account = “Open”, PIN = “Invalid”
Test case: Scenario 1Test case: Scenario 1 Output: Message “Invalid PIN: Try Again”Output: Message “Invalid PIN: Try Again”
Input: Card = “Not ATM”Input: Card = “Not ATM” Postcondition: Displays welcome messagePostcondition: Displays welcome message
Output: Eject cardOutput: Eject card .. Input: Card = “ATM”, Status = “Okay”,Input: Card = “ATM”, Status = “Okay”,
Postcondition : Displays welcome messagePostcondition : Displays welcome message Account = “Open”, PIN = “InvalidAccount = “Open”, PIN = “Invalid
Output: Message “Invalid PIN: Try Again”Output: Message “Invalid PIN: Try Again”
Test case: Scenario 2Test case: Scenario 2 Postcondition: Displays welcome messagePostcondition: Displays welcome message
Input: Card = “ATM”, Status = “Stolen”Input: Card = “ATM”, Status = “Stolen” Input: Card = “ATM”, Status = “Okay”Input: Card = “ATM”, Status = “Okay”
Account =“Open”, PIN = “InvalidAccount =“Open”, PIN = “Invalid
Output: Eject cardOutput: Eject card Output: Message “Invalid PIN: Try Again”Output: Message “Invalid PIN: Try Again”
Postcondition: Back to the initial statePostcondition: Back to the initial state Postcondition: Displays welcome messagePostcondition: Displays welcome message
Test case: Scenario 3Test case: Scenario 3 Input: Card = “ATM”, Status = “Okay”,Input: Card = “ATM”, Status = “Okay”,
Account = “Open”, PIN = “Invalid , Try = <4>”Account = “Open”, PIN = “Invalid , Try = <4>”
Input: Card = “ATM”, Status = “Okay”,Input: Card = “ATM”, Status = “Okay”, Output: Message “Invalid PIN: Try Later”Output: Message “Invalid PIN: Try Later”
Account = “Close”Account = “Close” Eject cardEject card
Output: Eject cardOutput: Eject card Postcondition: Displays welcome messagePostcondition: Displays welcome message
Postcondition: Displays welcome messagePostcondition: Displays welcome message Test case: Scenario 5Test case: Scenario 5
Input: Card = “ATM”, Status = “Okay”,Input: Card = “ATM”, Status = “Okay”,
Account = “Open”, PIN = “valid “Account = “Open”, PIN = “valid “
Output: Display “Hello”Output: Display “Hello”
Postcondition: Eject cardPostcondition: Eject card
Postcondition: Display menu for transactionPostcondition: Display menu for transaction
International

Fault models can be addressed…Fault models can be addressed…
 Interaction FaultInteraction Fault
 Scenario Faults.Scenario Faults.
01/24/1901/24/19 7272

Risk ManagementRisk Management
 Risk are events that could potentially affect aRisk are events that could potentially affect a
project’s outcome.project’s outcome.
 Beyond the control of project manager.Beyond the control of project manager.
 Risk Management includes:Risk Management includes:
--Identifying the possible risksIdentifying the possible risks
-Quantifying the risks-Quantifying the risks
-Planning to mitigate risk-Planning to mitigate risk
-Responding to risks when they became-Responding to risks when they became
realityreality
01/24/1901/24/19 7373

Risk Management…Risk Management…
 Risk managementRisk management is the identification, assessment,is the identification, assessment,
and prioritization ofand prioritization of risksrisks (defined in ISO 31000 as(defined in ISO 31000 as
the effect of uncertainty on objectives,the effect of uncertainty on objectives, whetherwhether
positive or negative) followed by coordinated andpositive or negative) followed by coordinated and
economical application of resources to minimize,economical application of resources to minimize,
monitor, and control the probability and/or impactmonitor, and control the probability and/or impact
of unfortunate eventsof unfortunate events
01/24/1901/24/19 7474

Identifying the possible risksIdentifying the possible risks
 Indentify risks that more likely to happenIndentify risks that more likely to happen
 Use of checklistUse of checklist,, Use of organization historyUse of organization history
andand Informal networking across industryInformal networking across industry cancan
help in identifying the risk.help in identifying the risk.
 It has to be up-to-date.It has to be up-to-date.
01/24/1901/24/19 7575

Quantifying the risksQuantifying the risks
 Probability of occurrenceProbability of occurrence
 Impact of occurrenceImpact of occurrence
01/24/1901/24/19 7676

Planning to mitigate riskPlanning to mitigate risk
 Identify alternative subsystem to combat riskIdentify alternative subsystem to combat risk
event.event.
01/24/1901/24/19 7777

Responding to risks when they becameResponding to risks when they became
realityreality
 If previous has not been taken care of.If previous has not been taken care of.
 May not be efficient/optimal as taken underMay not be efficient/optimal as taken under
pressure.pressure.
01/24/1901/24/19 7878

List of Potential Risk…List of Potential Risk…
 Unclear RequirementUnclear Requirement
 Schedule DependencySchedule Dependency
 Insufficient time for testingInsufficient time for testing
 ““Show stopper” defectsShow stopper” defects
 Availability of skilled and motivated people forAvailability of skilled and motivated people for
testing.testing.
 Inability to get a test automation tool.Inability to get a test automation tool.
[Software Testing[Software Testing Principle and Practices: S.Desikan &Principle and Practices: S.Desikan &
G.Ramesh]G.Ramesh]
01/24/1901/24/19 7979

Software Testing

More Related Content

Similar to Software Testing (20)

Recently uploaded (20)

Software Testing