Upload
gouthamstrikes
View
228
Download
1
Embed Size (px)
Citation preview
8/18/2019 Manual Testing document
1/138
Manual Testing Testing Tools MindQ
Software
Computer software has become a driving force. It is the engine that drives businessdecision making. It serves as the basis for modern scientific investigation and engineering problem solving. It is a key factor that differentiates modern products and services. It is
embedded in systems of all kinds: Transportation, Medical, Telecommunications Military,
Industrial processes, Entertainment, ffice products,!, the list is almost endless.
"oftware is virtually inescapable in a modern world. #nd as we move into the twenty$first century, it will become the driver for new advances in everything from elementary
education to genetic engineering.
It affects nearly every aspect of our lives and has become pervasive in our commerce, our
culture, and our everyday activities.
Why Software has bugs?
"oftware have bugs because of% Mis$interpretation of re&uirements or no communication,
software comple'ity, programming errors, changing re&uirements, time pressure, egos of
people, poorly documented code, and software development tools used.
5 common problems in the Software Development Process
(. Poor requirement – if re&uirements are unclear, incomplete, too general, or not
testable, there will be problems
). Unrealistic schedule – If too much work is crammed in too little time, problems
are inevitable*. nadequate testing – no one will know whether or not the program is any good
until the customer complains or systems crash.+. !uturities – e&uests to pile on new features after development is underway,
e'tremely common.
-. "iscommunications – If developers dont know whats needed or customers
have erroneous e'pectations, problems are guaranteed.
5 #ommon Solutions to Software Development Problems$
(. "olid re&uirements). ealistic schedule
*. #de&uate Testing+. "tick to initial re&uirements as much as possible-. Communication
(
8/18/2019 Manual Testing document
2/138
Manual Testing Testing Tools MindQ
Software %ngineering$&
The application of a systematic, disciplined, &uantifiable approach to the development,
operation, and maintenance of software% that is, the application of engineering tosoftware.
Software 'uality$& /uality software is reasonably bug$free, delivered on time, within
budget, meets re&uirements, and is maintainable% 0owever, &uality is obviously a
sub1ective term. It will depend on who the 2customer is and their overall influence in the
scheme of things.
Software 'uality (ssurance )S'(*$ &Involves the entire "oftware development 3rocess
4 monitoring and improving the process, and making sure that any agreed$upon standardsand procedures are followed, and ensuring that problems are found and dealt with. It is
oriented to 2prevention of bugs.
Software 'uality #ontrol $& )'#*
It is a process in which actual testing of the software happens by following the process
defined by the /# team, it is mainly driven by the 56efect 6etection7Measuring and monitoring the &uality of s8w by conducting reviews after completion of
every development phase through review meetings.
+esting Definitions$
• Testing is the process of e'ecuting a program with the intent of finding errors
r
• 9erifying and validating the application with respect to customer re&uirements
r
inding the differences between customer e'pected and actual values
Testing should also ensure that a &uality product is delivered to the customer.
+ester ,esponsibilities$
• Identifying the most appropriate implementation approach for a given test
• Implementing individual tests.
• "etting up and e'ecuting the tests
• ;ogging outcomes and verifying test e'ecution• #naly
8/18/2019 Manual Testing document
3/138
Manual Testing Testing Tools MindQ
• easibility = #nalysis
• 6esign
• Coding• Testing
• elease = Maintenance
./ Software Development -ife #ycle )SD-#*
#ll of the stages from start to finish that take place when developing a new software
is known as "6;C.
• The "oftware ;ife Cycle is a description of the events that occur between the
birth and death of a software pro1ect inclusively.
• 6efines the concrete strategy to engineer "oftware artifacts
• "6;C is separated into phases >steps, stages?
• "6;C also determines the order of the phases, and the criteria for
transitioning from phase to phase
• !easibility Study and Problem (nalysis
& @hat e'actly is this system supposed to doA
6etermine and spell out the details of the problem.
• Design
& 0ow will the system solve the problemA
;ogical implementation of the s8w happens.
• #oding
&Translating the design into the actual system $ 3hysical construction of the s8w product
• +esting
&6oes the system completely solve the problemA
&0ave the re&uirements been satisfiedA
&6oes the system work properly in all situationsA
• "aintenance"mall Enhancements to the s8w happens and the
support is provided to solve the real time problems that
the system faces when the system goes live
*
easibility study
#nalysis
6esign
Coding
Testing
Installation =
Maintenance
8/18/2019 Manual Testing document
4/138
Manual Testing Testing Tools MindQ
!easibility Study$
The Feasibility Report
easibility report contains, #pplications areas to be considered eg stock control, purchasing, accounts etc
"ystem investigations for each application
Cost estimates
"ystem re&uirements
Timescale for implementation
E'pected benefits
System (nalysis$
"ystem analysis and design is the process of investigating a business with a view todetermining how best to manage the various procedures and information processing
tasks that it involves.
+
easibility "tudy
#nalysis
6esign
Coding
easibility "tudy
#nalysis
6esign
Coding
Testing
Installation =
Maintenance
The #nalyst conducts an initial
study of the problem and asks if
the solution is!Technologically
possibleA
Economically possibleA;egally possibleA
perationally possibleA
8/18/2019 Manual Testing document
5/138
Manual Testing Testing Tools MindQ
System (nalysis ,eport
System (nalysis ,eport consists of0
B" >Business e&uirement 6ocument?
" >unctional e&uirement 6ocument? or unctional specifications
se Cases >ser action and system esponse?
D These * are the base documents for writing Test Cases
6ocumenting the results
"ystems flow charts
6ata flow diagramsrgani
8/18/2019 Manual Testing document
6/138
Manual Testing Testing Tools MindQ
System Design ,eport
•
6esign 6ocument consists of #rchitectural 6esign, 6atabase 6esign, Interface6esign
#oding$
+esting
Testing is e'ecuting a program with an intent of finding Error 8 ault and ailure. ault is
a condition that causes the software to fail to perform its re&uired function. Error refers
to difference between #ctual utput and E'pected utput. ailure is the inability of asystem of a system or component to perform re&uired function according to its
specification. ailure is an event% fault is a state of the software, caused by an error.
F
easibility "tudy
#nalysis
6esign
Coding
Testing
Installation = Maintenance
3rogram development
6raft up user guides
8/18/2019 Manual Testing document
7/138
Manual Testing Testing Tools MindQ
Why Software +esting?
To discover defects.
To learn about the reliability of the software
To ensure that product works as user e'pected.
To avoid being sued by customers To detect defects early, which helps in
reducing the cost of defect fi'ing.
#ost of Defect ,epair
Phase 2 #ost
e&uirements G
6esign (G
Coding )G
Testing -G
Customer "ite (GG
H
easibility "tudy
#nalysis
6esign
Coding
Testing
Installation =
Maintenance
8/18/2019 Manual Testing document
8/138
Manual Testing Testing Tools MindQ
e&uire 6esign Coding Testing Customer "ite Cost G (G )G -G (GG
Installation = Maintenance:
Installation:
• ile conversion
• "ystem changeover
• Jew system becomes operational
K
easibilit "tud
#nal sis
6esi n
Codin
Testin
Installation =
Maintenance
8/18/2019 Manual Testing document
9/138
Manual Testing Testing Tools MindQ
• "taff training
Maintenance:• Corrective maintenance
• 3erfective maintenance
• #daptive maintenance
Software Development "odels
Water!all "odel
This model is same like as "6;C . This is a step by step model, after completion
of one phase then the ne't phase is implemented. #lso, known as ;inear "e&uentialModel or Classical Model.
Waterfall Strengths
L Easy to understand, easy to useL 3rovides structure to ine'perienced staff
L Milestones are well understood
L "ets re&uirements stabilityL ood for management control >plan, staff, track?
L @orks well when &uality is more important than cost or
schedule
Disadvantages
The waterfall model is the oldest and the most widely used paradigm.0owever, many pro1ects rarely follow its se&uential flow. This is due to the inherent
problems associated with its rigid format. Jamely:
N
(nalysis
Design
#oding
"aintenance
+esting
8/18/2019 Manual Testing document
10/138
Manual Testing Testing Tools MindQ
• It only incorporates iteration indirectly, thus changes may cause considerable
confusion as the pro1ect progresses.
•#s the client usually only has a vague idea of what is re&uired from the software product, @aterfall Model has difficulty accommodating the natural uncertainty
that e'ists at the beginning of the pro1ect.
• The customer only sees a working version of the product after it has been coded.
This may result in disaster if any undetected problems are precipitated to this
stage.
When to use the Waterfall "odel
L e&uirements are very well known
L 3roduct definition is stable
L Technology is understoodL Jew version of an e'isting product
L 3orting an e'isting product to a new platform.
Prototyping "odelL 6evelopers build a prototype during the re&uirements phaseL 3rototype is evaluated by end users
L sers give corrective feedback
L 6evelopers further refine the prototypeL @hen the user is satisfied, the prototype code is brought up to the standards needed for
a final product.
Prototyping Steps
L # preliminary pro1ect plan is developed
L #n partial high$level paper model is created
L The model is source for a partial re&uirements specificationL # prototype is built with basic and critical attributes
L The designer builds
4 the database 4 user interface
4 algorithmic functions
L The designer demonstrates the prototype, the user evaluates for problems and suggests
improvements.L This loop continues until the user is satisfied
(G
8/18/2019 Manual Testing document
11/138
Manual Testing Testing Tools MindQ
Prototyping Strengths
L Customers can 5see7 the system re&uirements as they are being gatheredL 6evelopers learn from customers
L # more accurate end productL ne'pected re&uirements accommodated
L #llows for fle'ible design and development
L "teady, visible signs of progress produced
L Interaction with the prototype stimulates awareness of additional needed functionality
Prototyping Wea3nesses
L Tendency to abandon structured program development for 5code$and$fi'7 developmentL Bad reputation for 5&uick$and$dirty7 methods
L verall maintainability may be overlooked
L The customer may want the prototype delivered.L 3rocess may continue forever >scope creep?
When to use Prototyping "odel
L e&uirements are unstable or have to be clarified
L #s the re&uirements clarification stage of a waterfall model
L 6evelop user interfaces
L "hort$lived demonstrationsL Jew, original development
L @ith the analysis and design portions of ob1ect$oriented development.
Prototype "odel
This model is suitable when the client is not clear about the re&uirements. This isa cyclic version of the linear model. In this model, once the re&uirement analysis is done
and the design for a prototype is made, the development process gets started. nce the
prototype is created, it is given to the customer for evaluation. The customer tests the
package and gives his8her feed back to the developer who refines the product accordingto the customerOs e'act e'pectation. #fter a finite number of iterations, the final software
package is given to the customer. In this methodology, the software is evolved as a result
of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful
software products have been developed using this model $ as it is very difficult >even for
a whi< kidP? to comprehend all the re&uirements of a customer in one shot. There aremany variations of this model skewed with respect to the pro1ect management styles of
the companies. Jew versions of a software product evolve as a result of prototyping.
((
8/18/2019 Manual Testing document
12/138
Manual Testing Testing Tools MindQ
,apid (pplication Development "odel
The #6 model is a linear se&uential software development process that emphasiwhen possible? or createreusable components >when necessary?. In all cases, automated tools are used to facilitate
construction of the software.
F. +esting and turnover"ince the #6 process emphasi
8/18/2019 Manual Testing document
13/138
Manual Testing Testing Tools MindQ
Spiral "odel or terative "odel or %volutionary "odel
It is the most generic of the models Most life cycle models can be derived as special
cases of the spiral model. The spiral uses a risk management approach to "8@
development some advantages of the spiral model are:
• 6efers elaboration of low risk "8@ elements
• Incorporates prototyping as a risk reduction strategy
• ives an early focus to reusable "8@
•
#ccommodates life$cycle evolution, growth, and re&uirement changes• Incorporates "8@ &uality ob1ectives into the product
• ocus on early error detection and design flaws
• "ets completion criteria for each pro1ect activity to answer the &uestion: 5how
much is enoughA
• ses identical approaches for development and maintenance.
• Can be used for 08@$"8@ system development
6raw backs: $ Even though there is no technical draw back the maintanance is very high
(*
8/18/2019 Manual Testing document
14/138
Manual Testing Testing Tools MindQ
8 "odel
9 model stands for 9erification = 9alidation model which has the above stages of
software development, left side is all development and involves more verification where
as right side involves more validation and little bit of verification. It is a suitable modelfor large scale companies to maintain testing process. This model defines co$e'istence
relation between development process and testing process.
There are different levels of testing involved in 9$model
• nit Testing
•
Integration Testing• "ystem Testing
• ser #cceptance Testing
#fter Completion of every development phase the corresponding testing activities should
be initiated.
Draw 4ac3s$&
The cost of Maintaining of independent testing team is very high.
(+
" stem e
" stem Testin
8/18/2019 Manual Testing document
15/138
Manual Testing Testing Tools MindQ
(gile SD-#9sL "peed up or bypass one or more life cycle phasesL sually less formal and reduced scopeL sed for time$critical applications
L sed in organi#"6?
L eature 6riven 6evelopment >66?
L Crystal Clear L 6ynamic "oftware 6evelopment Method >6"6M?
L apid #pplication 6evelopment >#6?L "crumL E'treme 3rogramming >S3?
L ational nify 3rocess >3?
%:treme Programming – ;P
or small$to$medium$si
8/18/2019 Manual Testing document
16/138
Manual Testing Testing Tools MindQ
+. "imple design 4 system is designed as simply as possible >e'tra comple'ity removed
as soon as found?
-. Testing 4 programmers continuously write unit tests% customers write tests for featuresF. efactoring 4 programmers continuously restructure the system without changing its
behavior to remove duplication and simplifyH. 3air$programming $$ all production code is written with two programmers at one
machine
K. Collective ownership 4 anyone can change any code anywhere in the system at any
time.N. Continuous integration 4 integrate and build the system many times a day 4 every time
a task is completed.
(G. +G$hour week 4 work no more than +G hours a week as a rule((. n$site customer 4 a user is on the team and available full$time to answer &uestions
(). Coding standards 4 programmers write all code in accordance with rules emphasi
8/18/2019 Manual Testing document
17/138
Manual Testing Testing Tools MindQ
• Initiali
8/18/2019 Manual Testing document
18/138
Manual Testing Testing Tools MindQ
arithmetic e'pression. If a condition is incorrect, then at least one component of the
condition is incorrect. Thus the type of errors that may occur is.
• Boolean opearator error
• Boolean variable error
• Boolean 3arenthesis error
• elational operator error
• #rithmetic e'pression error
"tructure ( Entry R ( E'it with certain Constraints, Conditions and ;oops.
(pproach $&
Basic Path Testing :
Cyclomatic Comple'ity and McCabe Method Structure Testing :
Condition Testing , 6ata low Testing and ;oop Testing
>rey 4o: +esting $&
rey Bo' Testing is a new term, which evolved due to the different behaviors of thesystem.This is 1ust a combination of both Black Bo' = @hite Bo' Testing.Tester should
have the knowledge of both the internals and e'ternals of the function.
Even though you probably dont have full knowledge of the internals of the product you
test, a test strategy based partly on internals is a powerful idea. @e call this rey Bo'Testing. The concept is simple: If you know something about how the product works onthe inside, you can test it better from the outside. This is not to be confused with @hite
Bo' Testing, which attempts to cover the internals of the product in detail. In ray Bo'
mode, you are testing from the outside of the product, 1ust as you do with Black Bo', but
your testing choices are informed by your knowledge of how the underlying componentsoperate and interact.
ray Bo' Testing is especially important with @eb and Internet applications, because the Internet is built around loosely integrated components that connect via
relatively well$defined interfaces. nless you understand the architecture of the Jet,
your testing will be skin deep
+he +est Development -ife #ycle )+D-#*
sually, Testing is considered as a part of the "ystem 6evelopment ;ife Cycle. @ith our
practical e'perience, we framed this Test 6evelopment ;ife Cycle.
(K
8/18/2019 Manual Testing document
19/138
Manual Testing Testing Tools MindQ
The diagram does not depict where and when you write your Test 3lan and "trategy
documents. But, it is understood that before you begin your testing activities these
documents should be ready. Ideally, when the 3ro1ect 3lan and 3ro1ect "trategy are beingmade, this is the time when the Test 3lan and Test "trategy documents are also made.
+esting at %ach Stage of Development
(N
Requirement Study
Software RequirementSpecification
Requirement Checklist
Software RequirementSpecification
Functional SpecificationChecklist
Functional SpecificationDocument
Functional SpecificationDocument
Architecture Design
Architecture Design Detailed Design Document
Coding
Functional SpecificationDocument
Performance Criteria
Performance Test Casesand Scenarios
Software RequirementSpecificationRegression Test CaseDocument
Performance Test Casesand Scenarios
User Acceptance Test CaseDocumentsScenarios
Coding
Functional SpecificationDocument
Unit Test Case Documents
Design Document
Functional SpecificationDocument
Unit Test Case Document
System Test CaseDocument
!ntegration Test CaseDocument
Unit!ntegrationSystem
Test Case Documents
Regression Test Case
Document
8/18/2019 Manual Testing document
20/138
Manual Testing Testing Tools MindQ
8erification$&9erification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that
phase.
mportance of the 8erification Phase$&
9erification process helps in detecting defects early, and preventing their leakage
downstream. Thus, the higher cost of later detection and rework is eliminated.
,eviews$&
# process or meeting during which a work product, or set of work products, is presentedto pro1ect personnel, managers, users, customers, or other interested parties for comment
or approval.
The main goal of reviews is to find defects. eviews are a good compliment to testing to
help assure &uality. # few purposes of "/# reviews can be as follows:
• #ssure the &uality of deliverable before the pro1ect moves to the ne't stage.
• nce a deliverable has been reviewed, revised as re&uired, and approved, it can be
used as a basis for the ne't stage in the life cycle.
+ypes of reviews$&
Types of reviews include Management eviews, Technical eviews, Inspections,
@alkthroughs and #udits.
"anagement ,eviews$&
)G
8/18/2019 Manual Testing document
21/138
Manual Testing Testing Tools MindQ
Management reviews are performed by those directly responsible for the system in order
to monitor progress, determine status of plans and schedules, confirm re&uirements andtheir system allocation.
Therefore the main ob1ectives of Management eviews can be categori
8/18/2019 Manual Testing document
22/138
Manual Testing Testing Tools MindQ
In technical reviews, the following "oftware products are reviewed
• "oftware re&uirements specification
•"oftware design description
• "oftware test documentation
• "oftware user documentation
• Installation procedure
• elease notes
The participants of the review play the roles of 6ecision$maker, eview leader, ecorder,
Technical staff.
,equirement ,eview$&
# process or meeting during which the re&uirements for a system, hardware item, or software item are presented to pro1ect personnel, managers, users, customers, or other
interested parties for comment or approval. Types include system re&uirements review,
software re&uirements review.
@ho is involved in e&uirement eviewA
• 3roduct management leads e&uirement eview. Members from every affected
department participate in the review which includes functional consultants from
customer end.
nput #riteria
"oftware re&uirement specification is the essential document for the review. #
checklist can be used for the review.
%:it #riteria
E'it criteria include the filled = completed checklist with the reviewers
comments = suggestions and the re$verification whether they are incorporated in thedocuments.
Design ,eview$&# process or meeting during which a system, hardware, or software design is presented to
pro1ect personnel, managers, users, customers, or other interested parties for comment or
approval. Types include critical design review, preliminary design review, and systemdesign review.
))
8/18/2019 Manual Testing document
23/138
Manual Testing Testing Tools MindQ
@ho involves in 6esign eviewA
• /# team member leads design review. Members from development team and /#
team participate in the review.
nput #riteria$&
6esign document is the essential document for the review. # checklist can be used
for the review.
%:it #riteria$&
E'it criteria include the filled = completed checklist with the reviewers
comments = suggestions and the re$verification whether they are incorporated in thedocuments.
#ode ,eview$&# meeting at which software code is presented to pro1ect personnel, managers, users,
customers, or other interested parties for comment or approval.
@ho is involved in Code eviewA
• /# team member >In case the /# Team is only involved in Black Bo' Testing, then
the 6evelopment team lead chairs the review team? leads code review. Members from
development team and /# team participate in the review.
nput #riteria$&
The Coding "tandards 6ocument and the "ource file are the essential documentsfor the review. # checklist can be used for the review.
%:it #riteria$&
E'it criteria include the filled = completed checklist with the reviewers
comments = suggestions and the re$verification whether they are incorporated in the
documents.
Wal3throughs$&
# static analysis techni&ue in which a designer or programmer leads members of the
development team and other interested parties through a segment of documentation or
code, and the participants ask &uestions and make comments about possible errors,violation of development standards, and other problems.
The ob1ectives of @alkthrough can be summari
8/18/2019 Manual Testing document
24/138
Manual Testing Testing Tools MindQ
• Ensure >re?established standards are followed:
• Train and e'change technical information among pro1ect teams, which participate in
the walkthrough.• Increase the &uality of the pro1ect, thereby improving morale of the team members.
The participants in @alkthroughs assume one or more of the following roles:a? @alk$through leader
b? ecorder
c? #uthor d? Team member
To consider a review as a systematic walk$through, a team of at least two members shall
be assembled. oles may be shared among the team members. The walk$through leader
or the author may serve as the recorder. The walk$through leader may be the author.Individuals holding management positions over any member of the walk$through team
shall not participate in the walk$through.
Input to the walk$through shall include the following:
a? # statement of ob1ectives for the walk$through b? The software product being e'amined
c? "tandards that are in effect for the ac&uisition, supply, development, operation, and8or
maintenance of the software product
Input to the walk$through may also include the following:d? #ny regulations, standards, guidelines, plans, and procedures against which the
software product is to be inspectede? #nomaly categories
The walk$through shall be considered complete when
a? The entire software product has been e'amined b? ecommendations and re&uired actions have been recorded
c? The walk$through output has been completed
nspection$&
# static analysis techni&ue that relies on visual e'amination of development products to
detect errors, violations of development standards, and other problems. Types includecode inspection% design inspection, #rchitectural inspections, Test ware inspections etc.
The participants in Inspections assume one or more of the following roles:
a? Inspection leader
)+
8/18/2019 Manual Testing document
25/138
Manual Testing Testing Tools MindQ
b? ecorder
c? eader
d? #uthor e? Inspector
#ll participants in the review are inspectors. The author shall not act as inspection leader
and should not act as reader or recorder. ther roles may be shared among the team
members. Individual participants may act in more than one role.
Individuals holding management positions over any member of the inspection team shallnot participate in the inspection.
Input to the inspection shall include the following:a? # statement of ob1ectives for the inspection
b? The software product to be inspected
c? 6ocumented inspection procedured? Inspection reporting forms
e? Current anomalies or issues list
Input to the inspection may also include the following:
f? Inspection checklists
g? #ny regulations, standards, guidelines, plans, and procedures against which the
software product is to be inspectedh? 0ardware product specifications
i? 0ardware performance data
1? #nomaly categories
The individuals may make additional reference material available responsible for the
software product when re&uested by the inspection leader.The purpose of the e'it criteria is to bring an unambiguous closure to the inspection
meeting. The e'it decision shall determine if the software product meets the inspection
e'it criteria and shall prescribe any appropriate rework and verification. "pecifically, the
inspection team shall identify the software product disposition as one of the following:a? #ccept with no or minor rework. The software product is accepted as is or with only
minor rework. >or e'ample, that would re&uire no further verification?.
b? #ccept with rework verification. The software product is to be accepted after theinspection leader or
a designated member of the inspection team >other than the author? verifies rework.
c? e$inspect. "chedule a re$inspection to verify rework. #t a minimum, a re$inspectionshall e'amine the software product areas changed to resolve anomalies identified in the
last inspection, as well as side effects of those changes.
)-
8/18/2019 Manual Testing document
26/138
Manual Testing Testing Tools MindQ
White 4o: +esting$&
@hite bo' testing involves looking at the structure of the code. @hen you know theinternal structure of a product, tests can be conducted to ensure that the internal
operations performed according to the specification. #nd all internal components have been ade&uately e'ercised. In other word @BT tends to involve the coverage of the
specification in the code.
Code coverage is defined in si' types as listed below.
• "egment coverage 4 Each segment of code b8w control structure is e'ecuted at
least once.
• Branch Coverage or Jode Testing 4 Each branch in the code is taken in each
possible direction at least once.• Compound Condition Coverage 4 @hen there are multiple conditions, you must
test not only each direction but also each possible combinations of conditions,which is usually done by using a 2Truth Table
• Basis 3ath Testing 4 Each independent path through the code is taken in a pre$
determined order. This point will further be discussed in other section.
• 6ata low Testing >6T? 4 In this approach you track the specific variables
through each possible calculation, thus defining the set of intermediate paths
through the code i.e., those based on each piece of code chosen to be tracked.
Even though the paths are considered independent, dependencies across multiple
paths are not really tested for by this approach. 6T tends to reflect dependencies but it is mainly through se&uences of data manipulation. This approach tends to
uncover bugs like variables used but not initiali
8/18/2019 Manual Testing document
27/138
Manual Testing Testing Tools MindQ
• uarantee that all independent paths within a module have been e'ercised at
least once.
•E'ercise all logical decisions on their true and false values.
• E'ecute all loops at their boundaries and within their operational bounds
• E'ercise internal data structures to ensure their validity.
@hite bo' testing >@BT? is also called "tructural or lass bo' testing.
@hy @BTA
@e do @BT because Black bo' testing is unlikely to uncover numerous sorts of defects
in the program. These defects can be of the following nature:
• ;ogic errors and incorrect assumptions are inversely proportional to the probability that a program path will be e'ecuted. Error tend to creep into our
work when we design and implement functions, conditions or controls that are
out of the program
• The logical flow of the program is sometimes counterintuitive, meaning that
our unconscious assumptions about flow of control and data may lead to
design errors that are uncovered only when path testing starts.
• Typographical errors are random, some of which will be uncovered by synta'
checking mechanisms but others will go undetected until testing begins.
-imitations$&
nfortunately in @BT, e'haustive testing of a code presents certain logistical problems.
Even for small programs, the number of possible logical paths can be very large. or
instance, a (GG line C ;anguage program that contains two nested loops e'ecuting ( to )Gtimes depending upon some initial input after some basic data declaration. Inside the
interior loop four if$then$else constructs are re&uired. Then there are appro'imately (G (+
logical paths that are to be e'ercised to test the program e'haustively. @hich means that amagic test processor developing a single test case, e'ecute it and evaluate results in one
millisecond would re&uire *(HG years working continuously for this e'haustive testing
which is certainly impractical. E'haustive @BT is impossible for large software systems.But that doesnt mean @BT should be considered as impractical. ;imited @BT in which
a limited no. of important logical paths are selected and e'ercised and important datastructures are probed for validity, is both practical and @BT. It is suggested that white
and black bo' testing techni&ues can be coupled to provide an approach that thatvalidates the software interface selectively ensuring the correction of internal working of
the software.
)H
8/18/2019 Manual Testing document
28/138
Manual Testing Testing Tools MindQ
4asis Path +esting$&
Basis path testing is a white bo' testing techni&ue first proposed by Tom McCabe. The
Basis path method enables to derive a logical comple'ity measure of a procedural designand use this measure as a guide for defining a basis set of e'ecution paths. Test Cases
derived to e'ercise the basis set are guaranteed to e'ecute every statement in the program
at least one time during testing.
The flow graph depicts logical control flow using a diagrammatic notation. Eachstructured construct has a corresponding flow graph symbol.
#yclomatic #omple:ity$&
Cyclomatic comple'ity is a software metric that provides a &uantitative measure of the
logical comple'ity of a program. @hen used in the conte't of a basis path testing method,the value computed for Cyclomatic comple'ity defines the number for independent paths
in the basis set of a program and provides us an upper bound for the number of tests that
must be conducted to ensure that all statements have been e'ecuted at least once.#n independent path is any path through the program that introduces at least one new set
of processing statements or a new condition.
#omputing #yclomatic #omple:ity$&
Cyclomatic comple'ity has a foundation in graph theory and provides us with e'tremely
useful software metric. Comple'ity is computed in one of the three ways:(. The number of regions of the flow graph corresponds to the Cyclomatic comple'ity.
). Cyclomatic comple'ity, 9>?, for a flow graph, is defined as
9 >? E$JR)@here E, is the number of flow graph edges, J is the number of flow graph nodes.
*. Cyclomatic comple'ity, 9 >? for a flow graph, is also defined as:
9 >? 3R(
@here 3 is the number of predicate nodes contained in the flow graph .
>raph "atrices$&
The procedure for deriving the flow graph and even determining a set of basis paths isamenable to mechani
8/18/2019 Manual Testing document
29/138
Manual Testing Testing Tools MindQ
#ontrol Structure +esting$&
6escribed below are some of the variations of Control "tructure Testing.
#ondition +esting$&
Condition testing is a test case design method that e'ercises the logical conditions
contained in a program module.
Data !low +esting$&
The data flow testing method selects test paths of a program according to the locations of
definitions and uses of variables in the program.
-oop +esting$&
;oop Testing is a white bo' testing techni&ue that focuses e'clusively on the validity of loop constructs. our classes of loops can be defined: "imple loops, Concatenated loops,
nested loops, and unstructured loops.
Simple -oops$&
The following sets of tests can be applied to simple loops, where 2n is the ma'imum
number of allowable passes through the loop.
(. "kip the loop entirely.
). nly one pass through the loop.*. Two passes through the loop.
+. 2m passes through the loop where mVn.
-. n$(, n, nR( passes through the loop.
1ested -oops$&
If we e'tend the test approach from simple loops to nested loops, the number of possibletests would grow geometrically as the level of nesting increases.
(. "tart at the innermost loop. "et all other loops to minimum values.
). Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values. #dd other tests for out$of$range or e'clude values.
)N
8/18/2019 Manual Testing document
30/138
Manual Testing Testing Tools MindQ
*. @ork outward, conducting tests for the ne't loop, but keep all other outer loops at
minimum values and other nested loops to 5typical7 values.
+. Continue until all loops have been tested.
#oncatenated -oops$&
Concatenated loops can be tested using the approach defined for simple loops, if each of
the loops is independent of the other. 0owever, if two loops are concatenated and the
loop counter for loop ( is used as the initial value for loop ), then the loops are notindependent.
Unstructured -oops$&
@henever possible, this class of loops should be redesigned to reflect the use of the
structured programming constructs.
4lac3 4o: +esting$
Black bo' is a test design method. Black bo' testing treats the system as a Qblack$bo'Q,so it doesnOt e'plicitly use Unowledge of the internal structure. r in other words the Test
engineer need not know the internal working of the 5Black bo'7.
It focuses on the functionality part of the module.
"ome people like to call black bo' testing as behavioral, functional, opa&ue$bo', andclosed$bo'. @hile the term black bo' is most popularly use, many people prefer the
terms QbehavioralQ and QstructuralQ for black bo' and white bo' respectively. Behavioral
test design is slightly different from black$bo' test design because the use of internal
knowledge isnOt strictly forbidden, but itOs still discouraged.
3ersonally we feel that there is a trade off between the approaches used to test a product
using white bo' and black bo' types.There are some bugs that cannot be found using only black bo' or only white bo'. If the
test cases are e'tensive and the test inputs are also from a large sample space then it isalways possible to find ma1ority of the bugs through black bo' testing.
#dvantages:$
$ Tester can be non$technical.
$ This testing is most likely to find those bugs as the user would find.
*G
8/18/2019 Manual Testing document
31/138
Manual Testing Testing Tools MindQ
$ Testing helps to identify the vagueness and contradiction in functional specifications.
$ Test cases can be designed as soon as the functional specifications are complete
Disadvantages$&
$ Chances of having repetition of tests that are already done by programmer.$ The test inputs needs to be from large sample space.
$ It is difficult to identify all possible inputs in limited testing time. "o writing test cases
is slow and difficult
Chances of having unidentified paths during this testing
8alidation Phase$&
The 9alidation 3hase falls into picture after the software is ready or when the code is
being written. There are various techni&ues and testing types that can be appropriatelyused while performing the testing activities. ;et us e'amine a few of them.
Unit Testing:-
This is a typical scenario of Manual nit Testing activity$
# nit is allocated to a 3rogrammer for programming. 3rogrammer has to use
2unctional "pecifications document as input for his work. 3rogrammer prepares
23rogram "pecifications for his nit from the unctional "pecifications. 3rogram"pecifications describe the programming approach, coding tips for the nits coding.
The programmer implements some functionality for the system to be developed. The
same is tested by referring the unit test cases. @hile testing that functionality if
any defects have been found, they are recorded using the defect logging toolwhichever is applicable. The programmer fi'es the bugs found and tests the
same for any errors.
Stubs and Drivers$&
# software application is made up of a number of 2nits, where output of one 2nit
goes as an 2Input of another nit. e.g. # 2"ales rder 3rinting program takes a 2"ales
rder as an input, which is actually an output of 2"ales rder Creation program.
6ue to such interfaces, independent testing of a nit becomes impossible. But that iswhat we want to do% we want to test a nit in isolationP "o here we use 2"tub and
26river.# Driver9 is a piece of software that drives >invokes? the nit being tested. # driver
creates necessary 2Inputs re&uired for the nit and then invokes the nit.
*(
8/18/2019 Manual Testing document
32/138
Manual Testing Testing Tools MindQ
# nit may reference another nit in its logic. # 2"tub takes place of such subordinate
unit during the nit Testing. # 2"tub is a piece of software that works similar to a unit
which is referenced by the nit being tested, but it is much simpler that the actual unit. #Stub works as a 2"tand$in for the subordinate unit and provides the minimum re&uired
behavior for that unit.3rogrammer needs to create such 26rivers and 2"tubs for carrying out nit Testing.
Both the 6river and the "tub are kept at a minimum level of comple'ity, so that they do
not induce any errors while testing the nit in &uestion.
E'ample $ or nit Testing of 2"ales rder 3rinting program, a 26river program will
have the code which will create "ales rder records using hardcoded data and then call
2"ales rder 3rinting program. "uppose this printing program uses another unit whichcalculates "ales discounts by some comple' calculations. Then call to this unit will be
replaced by a 2"tub, which will simply return fi' discount data.
ntegration Testing:-
Integration testing is a systematic techni&ue for constructing the program structure while
at the same time conducting tests to uncover errors associated with interfacing. Theob1ective is to take unit tested components and build a program structure that has been
dictated by design.
sually, the following methods of Integration testing are followed:
(. Top$down Integration approach.
). Bottom$up Integration approach.
+op&Down ntegration$&
Top$down integration testing is an incremental approach to construction of programstructure. Modules are integrated by moving downward through the control hierarchy,
beginning with the main control module. Modules subordinate to the main control
module are incorporated into the structure in either a depth$first or breadth$first manner.
(. The Integration process is performed in a series of five steps:
). The main control module is used as a test driver and stubs are substituted for allcomponents directly subordinate to the main control module.
*. 6epending on the integration approach selected subordinate stubs are replacedone at a time with actual components.+. Tests are conducted as each component is integrated.
-. n completion of each set of tests, stub is replaced with the real component.
F. egression testing may be conducted to ensure that new errors have not been
introduced.
*)
8/18/2019 Manual Testing document
33/138
Manual Testing Testing Tools MindQ
4ottom&Up ntegration$&
Bottom$up integration testing begins construction and testing with atomic modules >i.e.
components at the lowest levels in the program structure?. Because components areintegrated from the bottom up, processing re&uired for components subordinate to a given
level is always available and the need for stubs is eliminated.
(. # Bottom$up integration strategy may be implemented with the following steps:
). ;ow level components are combined into clusters that perform a specific softwaresub function.
*. # driver is written to coordinate test case input and output.
+. The cluster is tested.6rivers are removed and clusters are combined moving upward in the program structure.
Syste! Testing:-
"ystem testing concentrates on testing the complete system with a variety of techni&ues
and methods. "ystem Testing comes into picture after the nit and Integration Tests.
#ompatibility +esting$&
Compatibility Testing concentrates on testing whether the given application goes wellwith third party tools, software or hardware platform.
or e'ample, you have developed a web application. The ma1or compatibility issue is, the
web site should work well in various browsers. "imilarly when you develop applications
on one platform, you need to check if the application works on other operating systems aswell. This is the main goal of Compatibility Testing.
Before you begin compatibility tests, our sincere suggestion is that you should have across reference matri' between various softwares, hardware based on the application
re&uirements. or e'ample, let us suppose you are testing a web application. # sample list
can be as follows:
0ardware "oftware perating "ystem
3entium 4 II, ()K MB #M IE +.', pera, Jetscape @indows N-
3entium 4 III, )-F MB
#M
IE -.', Jetscape @indows S3
3entium 4 I9, -() MB
#M
Mo
8/18/2019 Manual Testing document
34/138
Manual Testing Testing Tools MindQ
Compatibility Testing is very crucial to organi
8/18/2019 Manual Testing document
35/138
Manual Testing Testing Tools MindQ
"tress testing e'ecutes a system in a manner that demands resources in abnormal
&uantity, fre&uency, or volume. The following types of tests may be conducted during
stress testing%• "pecial tests may be designed that generate ten interrupts per second, when
one or two is the average rate.
• Input data rates may be increases by an order of magnitude to determine how
input functions will respond.
• Test Cases that re&uire ma'imum memory or other resources.
• Test Cases that may cause e'cessive hunting for disk$resident data.
• Test Cases that my cause thrashing in a virtual operating system.
Performance +esting3erformance testing of a @eb site is basically the process of understanding how the @ebapplication and its operating environment respond at various user load levels. In general,
we want to measure the esponse Time, Throughput, and tili
8/18/2019 Manual Testing document
36/138
Manual Testing Testing Tools MindQ
The ob1ective of load testing is to check whether the system can perform well for
specified load. The system may be capable of accommodating more than (GGG concurrentusers. But, validating that is not under the scope of load testing. Jo attempt is made to
determine how many more concurrent users the system is capable of servicing. Table (illustrates the e'ample specified.
Stress testing$&
"tress testing is another industry term of performance testing. Though load testing =
"tress testing are used synonymously for performance4related efforts, their goal is
different.
nlike load testing where testing is conducted for specified number of users, stresstesting is conducted for the number of concurrent users beyond the specified limit. Theob1ective is to identify the ma'imum number of users the system can handle before
breaking down or degrading drastically. "ince the aim is to put more stress on system,
think time of the user is ignored and the system is e'posed to e'cess load. The goals of load and stress testing are listed in Table ). efer to table * for the inference drawn
through the 3erformance Testing Efforts.
;et us take the same e'ample of online shopping application to illustrate the ob1ective of stress testing. It determines the ma'imum number of concurrent users an online system
can service which can be beyond (GGG users >specified limit?. 0owever, there is a
possibility that the ma'imum load that can be handled by the system may found to besame as the anticipated limit.
"tress testing also determines the behavior of the system as user base increases. It checkswhether the system is going to degrade gracefully or crash at a shot when the load goes
beyond the specified limit.
;oad and stress testing of illustrative e'ample
Types of Testing Jumber of Concurrent users 6uration
;oad Testing ( ser
-G sers
(GG sers
)-Gsers-GG sers!!!!.
(GGGsers
() 0ours
"tress Testing ( ser -G sers (GG sers )-G
sers-GG sers!!!!.
() 0ours
*F
8/18/2019 Manual Testing document
37/138
Manual Testing Testing Tools MindQ
(GGGsers Beyond (GGG
sers!!!..Ma'imum sers
oals of load and stress testing
Types of testing oals
;oad testing • Testing for anticipated user base
• 9alidates whether system is
capable of handling load under
specified limit
"tress testing • Testing beyond the anticipated
user base
• Identifies the ma'imum load a
system can handle
• Checks whether the system
degrades gracefully or crashes at
a shot
,egression +esting$&
egression testing as the name suggests is used to test 8 check the effect of changes madein the code. Most of the time the testing team is asked to check last minute changes in the
code 1ust before making a release to the client, in this situation the testing team needs to
check only the affected areas. "o in short for the regression testing the testing teamshould get the input from the development team about the nature 8 amount of change in
the fi' so that testing team can first check the fi' and then the side effects of the fi'.
In fact the regression testing is the testing in which ma'imum automation can be done.The reason being the same set of test cases will be run on different builds multiple times.
But again the e'tent of automation depends on whether the test cases will remain
applicable over the time, In case the automated test cases do not remain applicable for some amount of time then test engineers will end up in wasting time to automate and
dont get enough out of automation.
*H
8/18/2019 Manual Testing document
38/138
Manual Testing Testing Tools MindQ
egression Testing is retesting unchanged segments of application. It involves rerunning
tests that have been previously e'ecuted to ensure that the same results can be achieved
currently as were achieved when the segment was last tested.
The selective retesting of a software system that has been modified to ensure that any bugs have been fi'ed and that no other previously working functions have failed as a
result of the reparations and that newly added features have not created problems with
previous versions of the software. #lso referred to as verification testing, regression
testing is initiated after a programmer has attempted to fi' a recogni
8/18/2019 Manual Testing document
39/138
Manual Testing Testing Tools MindQ
document must provide generic test approach as well as specific details regarding the
pro1ect. The following areas are addressed in the test strategy document.
or e'ample we should have a master Test "trategy document at a pro1ect level and weshould have a detailed Test 3lan for every release. This document should give the overall
scope of pro1ect at a high level.
( +est -evels
The test strategy must talk about what are the test levels that will be carried out for that particular pro1ect. nit, Integration = "ystem testing will be carried out in all pro1ects.
But many times, the integration = system testing may be combined. 6etails like this may
be addressed in this section.
,oles and ,esponsibilities
The roles and responsibilities of test leader, individual testers, pro1ect manager are to beclearly defined at a pro1ect level in this section. This may not have names associated: but
the role has to be very clearly defined. The review and approval mechanism must be
stated here for test plans and other test documents. #lso, we have to state who reviews thetest cases, test records and who approved them. The documents may go thru a series of
reviews or multiple approvals and they have to be mentioned here.
6 +esting +ools
#ny testing tools, which are to be used in different test levels, must be, clearly identified.
This includes 1ustifications for the tools being used in that particular level also.
7 ,is3s and "itigation
#ny risks that will affect the testing process must be listed along with the mitigation. By
documenting the risks in this document, we can anticipate the occurrence of it well aheadof time and then we can proactively prevent it from occurring. "ample risks are
dependency of completion of coding, which is done by sub$contractors, capability of
testing tools etc.
5 ,egression +est (pproach
@hen a particular problem is identified, the programs will be debugged and the fi' will
be done to the program. To make sure that the fi' works, the program will be testedagain. egression test will make sure that one fi' does not create some other problems in
that program or in any other interface. "o, a set of related test cases may have to be
repeated again, to make sure that nothing else is affected by a particular fi'. 0ow this isgoing to be carried out must be elaborated in this section. In some companies, whenever
there is a fi' in one unit, all unit test cases for that unit will be repeated, to achieve a
higher level of &uality.
*N
8/18/2019 Manual Testing document
40/138
Manual Testing Testing Tools MindQ
@ +est >roups
rom the list of re&uirements, we can identify related areas, whose functionality issimilar. These areas are the test groups. or e'ample, in a railway reservation system,
anything related to ticket booking is a functional group% anything related with reportgeneration is a functional group. "ame way, we have to identify the test groups based on
the functionality aspect.
A +est Priorities
#mong test cases, we need to establish priorities. @hile testing software pro1ects, certain
test cases will be treated as the most important ones and if they fail, the product cannot be
released. "ome other test cases may be treated like cosmetic and if they fail, we canrelease the product without much compromise on the functionality. This priority levels
must be clearly stated. These may be mapped to the test groups also.
B +est Status #ollections and ,eporting
@hen test cases are e'ecuted, the test leader and the pro1ect manager must know, where
e'actly we stand in terms of testing activities. To know where we stand, the inputs fromthe individual testers must come to the test leader. This will include, what test cases are
e'ecuted, how long it took, how many test cases passed and how many$failed etc. #lso,
how often we collect the status is to be clearly mentioned. "ome companies will have a
practice of collecting the status on a daily basis or weekly basis. This has to be mentionedclearly.
C +est ,ecords "aintenance
@hen the test cases are e'ecuted, we need to keep track of the e'ecution details like
when it is e'ecuted, who did it, how long it took, what is the result etc. This data must be
available to the test leader and the pro1ect manager, along with all the team members, in acentral location. This may be stored in a specific directory in a central server and the
document must say clearly about the locations and the directories. The naming
convention for the documents and files must also be mentioned.
. ,equirements +raceability "atri:
Ideally each software developed must satisfy the set of re&uirements completely. "o, right
from design, each re&uirement must be addressed in every single document in thesoftware process. The documents include the 0;6, ;;6, source codes, unit test cases,
integration test cases and the system test cases. efer the following sample table which
describes e&uirements Traceability Matri' process. In this matri', the rows will have there&uirements. or every document D0;6, ;;6 etcX, there will be a separate column. "o,
in every cell, we need to state, what section in 0;6 addresses a particular re&uirement.
Ideally, if every re&uirement is addressed in every single document, all the individual
+G
8/18/2019 Manual Testing document
41/138
Manual Testing Testing Tools MindQ
cells must have valid section ids or names filled in. Then we know that every re&uirement
is addressed. In case of any missing of re&uirement, we need to go back to the document
and correct it, so that it addressed the re&uirement. or testing at each level, we may haveto address the re&uirements. ne integration and the system test case may address
multiple re&uirements.
.. +est Summary
The senior management may like to have test summary on a weekly or monthly basis. If
the pro1ect is very critical, they may need it on a daily basis also. This section mustaddress what kind of test summary reports will be produced for the senior management
along with the fre&uency.
The test strategy must give a clear vision of what the testing team will do for the whole
pro1ect for the entire duration. This document will8may be presented to the client also, if
needed. The person, who prepares this document, must be functionally strong in the product domain, with a very good e'perience, as this is the document that is going to
drive the entire team for the testing activities. Test strategy must be clearly e'plained to
the testing team members tight at the beginning of the pro1ect.
Test Plan:-
The test strategy identifies multiple test levels, which are going to be performed for the pro1ect. #ctivities at each level must be planned well in advance and it has to be formally
documented. Based on the individual plans only, the individual test levels are carried out.
The plans are to be prepared by e'perienced people only. In all test plans, the ET9SDEntry$Task$9alidation$E'itX criteria are to be mentioned. Entry means the entry point to
that phase. or e'ample, for unit testing, the coding must be complete and then only one
can start unit testing. Task is the activity that is performed. 9alidation is the way in whichthe progress and correctness and compliance are verified for that phase. E'it tells the
completion criteria of that phase, after the validation is done. or e'ample, the e'it
criterion for unit testing is all unit test cases must pass.
ET9S is a modeling techni&ue for developing worldly and atomic level models. It sands
for Entry, Task, 9erification and E'it. It is a task$based model where the details of eachtask are e'plicitly defined in a specification table against each phase i.e. Entry, E'it, Task,
eedback In, eedback ut, and measures.There are two types of cells, unit cells and implementation cells. The implementationcells are basically unit cells containing the further tasks.
or e'ample if there is a task of si
8/18/2019 Manual Testing document
42/138
Manual Testing Testing Tools MindQ
The unit cell containing these further tasks will be referred to as the implementation cell
and a separate table will be constructed for it.
# purpose is also stated and the viewer of the model may also be defined e.g. topmanagement or customer.
Unit +est Plan$&The test plan is the overall plan to carry out the unit test activities.The lead tester prepares it and it will be distributed to the individual testers, which
contains the following sections.
. What is to be tested?
The unit test plan must clearly specify the scope of unit testing. In this, normally the basic
input8output of the units along with their basic functionality will be tested. In this casemostly the input units will be tested for the format, alignment, accuracy and the totals.
The T3 will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be e'haustive% but it is better tohave a complete list of these details.
Sequence of +esting
The se&uences of test activities that are to be carried out in this phase are to be listed in
this section. This includes whether to e'ecute positive test cases first or negative test
cases first, to e'ecute test cases based on the priority, to e'ecute test cases based on test
groups etc. 3ositive test cases prove that the system performs what is supposed to do%negative test cases prove that the system does not perform what is not supposed to do.
Testing the screens, files, database etc., are to be given in proper se&uence.
6 4asic !unctionality of Units
0ow the independent functionalities of the units are tested which e'cludes any
communication between the unit and other units. The interface part is out of scope of thistest level. #part from the above sections, the following sections are addressed, very
specific to unit testing.
• nit Testing Tools
• 3riority of 3rogram units
• Jaming convention for test cases
• "tatus reporting mechanism
• egression test approach
• ET9S criteria
ntegration +est PlanThe integration test plan is the overall plan for carrying out the activities in the
integration test level, which contains the following sections.
+)
8/18/2019 Manual Testing document
43/138
Manual Testing Testing Tools MindQ
/.What is to be tested?
This section clearly specifies the kinds of interfaces fall under the scope of testinginternal, e'ternal interfaces, with re&uest and response is to be e'plained. This need not
go deep in terms of technical details but the general approach how the interfaces aretriggered is e'plained.
/Sequence of ntegration
@hen there are multiple modules present in an application, the se&uence in which theyare to be integrated will be specified in this section. In this, the dependencies between the
modules play a vital role. If a unit B has to be e'ecuted, it may need the data that is fed
by unit # and unit S. In this case, the units # and S have to be integrated and then usingthat data, the unit B has to be tested. This has to be stated to the whole set of units in the
program. iven this correctly, the testing activities will lead to the product, slowly
building the product, unit by unit and then integrating them.
/6 -ist of "odules and nterface !unctions
There may be J number of units in the application, but the units that are going tocommunicate with each other, alone are tested in this phase. If the units are designed in
such a way that they are mutually independent, then the interfaces do not come into
picture. This is almost impossible in any system, as the units have to communicate to
other units, in order to get different types of functionalities e'ecuted. In this section, weneed to list the units and for what purpose it talks to the others need to be mentioned. This
will not go into technical aspects, but at a higher level, this has to be e'plained in plain
English.
6 System +est Plan ES+PFThe system test plan is the overall plan carrying out the system test level activities. In thesystem test, apart from testing the functional aspects of the system, there are some special
testing activities carried out, such as stress testing etc. The following are the sections
normally present in system test plan.
6/.What is to be tested? )Should define both in scope and out scope of testing*
This section defines the scope of system testing, very specific to the pro1ect. Jormally,
the system testing is based on the re&uirements. #ll re&uirements are to be verified in thescope of system testing. This covers the functionality of the product. #part from this what
special testing is performed are also stated here.
6/ !unctional >roups and the Sequence
The re&uirements can be grouped in terms of the functionality. Based on this, there may
be priorities also among the functional groups. or e'ample, in a banking application,
+*
8/18/2019 Manual Testing document
44/138
Manual Testing Testing Tools MindQ
anything related to customer accounts can be grouped into one area, anything related to
inter$branch transactions may be grouped into one area etc. "ame way for the product
being tested, these areas are to be mentioned here and the suggested se&uences of testingof these areas, based on the priorities are to be described.
6/6Special +esting "ethods
This covers the different special tests like load8volume testing, stress testing,
interoperability testing etc. These testing are to be done based on the nature of the
product and it is not mandatory that every one of these special tests must be performedfor every product.
#part from the above sections, the following sections are addressed, very specific to
system testing.
•
"ystem Testing Tools• 3riority of functional groups
• Jaming convention for test cases
• "tatus reporting mechanism
• egression test approach
• ET9S criteria
• Build8efresh criteria
6/7 (cceptance +est Plan E(+PFThe client at their place performs the acceptance testing. It will be very similar to the
system test performed by the "oftware 6evelopment nit. "ince the client is the one whodecides the format and testing methods as part of acceptance testing, there is no specific
clue on the way they will carry out the testing. But it will not differ much from the
system testing. #ssume that all the rules, which are applicable to system test, can beimplemented to acceptance testing also.
"ince this is 1ust one level of testing done by the client for the overall product, it may
include test cases including the unit and integration test level details.
# sample Test 3lan utline along with their description is as shown below:
+est Plan Gutline
(. B#CUJ6 4 This item summari
8/18/2019 Manual Testing document
45/138
Manual Testing Testing Tools MindQ
*. #""M3TIJ" 4 Indicates any anticipated assumptions which will be made
while testing the application.
+. TE"T ITEM" $ ;ist each of the items >programs? to be tested.-. E#TE" T BE TE"TE6 $ ;ist each of the features >functions or
re&uirements?, which will be tested or demonstrated by the test.
F. E#TE" JT T BE TE"TE6 $ E'plicitly lists each feature, function, or
re&uirement which wonOt be tested and why not.
H. #33#C0 $ 6escribe the data flows and test philosophy.
"imulation or ;ive e'ecution, Etc. This section also mentions all the approaches,
which will be followed at the various stages of the test e'ecution.
K. ITEM 3#""8#I; CITEI# Blanket statement $ Itemi
8/18/2019 Manual Testing document
46/138
Manual Testing Testing Tools MindQ
(+. "T#IJ = T#IJIJ
(-. "C0E6;E
(F. E"CE"
(H. I"U" = CJTIJEJCIE"
(K. #339#;"
The schedule details of the various test pass such as nit tests, Integration tests, "ystemTests should be clearly mentioned along with the estimated efforts.
+est Plan ,eview$
#fter completion of preperation of test plan test lead conducts a review meeting for
completeness and correctness.In most of the companies review meetings conducted
through coverage analysis.
Coverage analysis are driven by the Checklist for the following,
"" Based Coverage
B" Based Coverage
+est #ase Design$&
6esigning good test cases is a comple' art. The comple'ity comes from three sources:
Test cases help us discover information. 6ifferent types of tests aremore effective for different classes of information.
Test cases can be 5good7 in a variety of ways. Jo test case will be
good in all of them. 3eople tend to create test cases according to certain testing styles,
such as domain testing or risk$based testing. ood domain tests are
different from good risk$based tests.
What9s a test case?
5# test case specifies the pretest state of the IT and its environment, the test inputs or conditions, and the e'pected result. The e'pected result specifies what the IT should
produce from the test inputs. This specification includes messages generated by the IT,
e'ceptions, returned values, and resultant state of the IT and its environment. Test casesmay also specify initial and resulting conditions for other ob1ects that constitute the IT
and its environment.7
+F
8/18/2019 Manual Testing document
47/138
Manual Testing Testing Tools MindQ
r
# Test Case is a description of what to be tested, what data to be given, what data to be
done to check the actual result against the e'pected.
r
The process of designing test cases, including e'ecuting them as thought e'periments,
will often identify bugs before the software has even been built. It is not uncommon tofind more bugs when designing tests than when e'ecuting tests.
;et us now see how to design test cases in a generic manner:
nderstand the re&uirements document.
Break the re&uirements into smaller re&uirements >if it improves your testability?.
or each e&uirement, decide what techni&ue you should use to derive the test
cases. or e'ample, if you are testing a ;ogin page, you need to write test cases
basing on error guessing and also negative cases for handling failures.
0ave a Traceability Matri' as follows:
e&uirement Jo >In 6? e&uirement Test Case Jo
@hat this Traceability Matri' provides you is the coverage of Testing. Ueep filling in theTraceability matri' when you complete writing test cases for each re&uirement.
What9s a scenario?
# scenario is a hypothetical story, used to help a person think through a comple' problem
or system.
#haracteristics of good test case$&
TC should start with 5what are u testing7
TC should be independent
TC should be not contain If 8 2or statements.
+H
8/18/2019 Manual Testing document
48/138
Manual Testing Testing Tools MindQ
TC should be uniform.
Every TC designed should be traced back to at least one re&uirement.
# TC should have high probability of finding errors.
ssues to consider during test case design$&
#ll testcases should be traceble
There shold not be many duplicate test cases
ut dated test cases should be cleared off
#ll test cases should be e'ecutable.
+est #ases +echniques$&
Error uessing Boundary value #nalysis
E&uivalence Class partition
%rror >uessing$&uessing is the art of guessing where errors can be hidden. There are no specific tools
and techni&ues for this, but you can write test cases depending on the situation: Either
when reading the functional documents or when you are testing and find an error that youhave not documented.
Error guessing is based mostly upon e'perience, with some assistance from other
techni&ues such as boundary value analysis. Based on e'perience, the test designer guesses the types of errors that could occur in a particular type of software and designs
test cases to uncover them. or e'ample, if any type of resource is allocated dynamically,a good place to look for errors is in the de$allocation of resources. #re all resources
correctly de$allocated, or are some lost as the software e'ecutesA
Error guessing by an e'perienced engineer is probably the single most effective methodof designing tests, which uncover bugs. # well$placed error guess can show a bug, which
could easily be missed by many of the other test case design techni&ues presented in this
paper.
Conversely, in the wrong hands error guessing can be a waste of time. To make thema'imum use of available e'perience and to add some structure to this test case designtechni&ue, it is a good idea to build a checklist of types of errors. This checklist can then
be used to help 5guess7 where errors may occur within a unit.The checklist should be
maintained with the benefit of e'perience gained in earlier unit tests, helping to improve
the overall effectiveness of error guessing.
+K
8/18/2019 Manual Testing document
49/138
Manual Testing Testing Tools MindQ
4oundary 8alue (nalysis$&
Boundary 9alue #nalysis >B9#? is a test data selection techni&ue >unctional Testingtechni&ue? where the e'treme values are chosen. Boundary values include ma'imum,
minimum, 1ust inside8outside boundaries, typical values, and error values. The hope is
that, if a system works correctly for these special values then it will work correctly for allvalues in between.
E'tends e&uivalence partitioning
Test both sides of each boundary
;ook at output boundaries for test cases too
Test min, min$(, ma', ma'R(, typical values B9# focuses on the boundary of the input space to identify test cases
ational is that errors tend to occur near the e'treme values of an input
variable
There are two ways to generali
8/18/2019 Manual Testing document
50/138
Manual Testing Testing Tools MindQ
-imitations of 4oundary 8alue (nalysis$&
B9# works best when the program is a function of several independent variables thatrepresent bounded physical &uantities
Independent 9ariables
o Je't6ate test cases derived from B9# would be inade&uate: focusing
on the boundary would not leave emphasis on ebruary or leap yearso 6ependencies e'ist with Je't6ateOs 6ay, Month and Wear
o Test cases derived without consideration of the function
3hysical /uantitieso #n e'ample of physical variables being tested, telephone numbers $
what faults might be revealed by numbers of GGG$GGGG, GGG$GGG(,
---$----, NNN$NNNK, NNN$NNNNA
%quivalence Partitioning$&
E&uivalence partitioning is a black bo' testing method that divides the input domain of a
program into classes of data from which test cases can be derived.
E3 can be defined according to the following guidelines:
(. If an input condition specifies a range, one valid and one two invalid classes are
defined.
). If an input condition re&uires a specific value, one valid and two invalid e&uivalenceclasses are defined.
*. If an input condition specifies a member of a set, one valid and one invalid e&uivalence
class is defined.
+. If an input condition is Boolean, one valid and one invalid class is defined.
#omparison +esting$&
There are situations where independent versions of software be developed for criticalapplications, even when only a single version will be used in the delivered computer
based system. It is these independent versions which form the basis of a black bo' testing
techni&ue called Comparison testing or back$to$back testing.
-G
8/18/2019 Manual Testing document
51/138
Manual Testing Testing Tools MindQ
Grthogonal (rray +esting$&
The rthogonal #rray Testing "trategy >#T"? is a systematic, statistical way of testing
pair$wise interactions by deriving a suitable small set of test cases >from a large number of possibilities?.
#haracteristics of >ood Scenarios
# scenario has five key characteristics. It is >a? a story that is >b? motivating, >c? credible,
>d? comple', and >e? easy to evaluate.
The primary ob1ective of test case design is to derive a set of tests that have the highest
attitude of discovering defects in the software. Test cases are designed based on theanalysis of re&uirements, use cases, and technical specifications, and they should be
developed in parallel with the software development effort.
# test case describes a set of actions to be performed and the results that are e'pected. #
test case should target specific functionality or aim to e'ercise a valid path through a usecase. This should include invalid user actions and illegal inputs that are not necessarily
listed in the use case. # test case is described depends on several factors, e.g. the number
of test cases, the fre&uency with which they change, the level of automation employed,
the skill of the testers, the selected testing methodology, staff turnover, and risk.
The test cases will have a generic format as below.
Test case I6 $ The test case id must be uni&ue across the application
Test case description $ The test case description must be very brief.
Test prere&uisite $ The test pre$re&uisite clearly describes what should be present
in the system, before the test can be e'ecutes. Test Inputs $ The test input is nothing but the test data that is prepared to be fed to
the system. Test steps $ The test steps are the step$by$step instructions on how to carry out the
test. E'pected esults $ The e'pected results are the ones that say what the system
must give as output or how the system must react based on the test steps. #ctual esults 4 The actual results are the ones that say outputs of the action for
the given inputs or how the system reacts for the given inputs.
-(
8/18/2019 Manual Testing document
52/138
Manual Testing Testing Tools MindQ
3ass8ail $ If the E'pected and #ctual results are same then test is 3ass otherwise
ail.
The test cases are classified into positive and negative test cases. 3ositive test cases aredesigned to prove that the system accepts the valid inputs and then process themcorrectly. "uitable techni&ues to design the positive test cases are "pecification derived
tests, E&uivalence partitioning and "tate$transition testing. The negative test cases are
designed to prove that the system re1ects invalid inputs and does not process them.
"uitable techni&ues to design the negative test cases are Error guessing, Boundary valueanalysis, internal boundary value testing and "tate$transition testing. The test cases details
must be very clearly specified, so that a new person can go through the test cases step and
step and is able to e'ecute it. The test cases will be e'plained with specific e'amples inthe following section.
or e'ample consider online shopping application. #t the user interface level the client
re&uest the web server to display the product details by giving email id and sername.The web server processes the re&uest and will give the response. or this application we
will design the unit, Integration and system test cases.
@eb based application
+est %ngineers can write testcases based on ,equiremnets or use casesH the use cases
are described as below
Use #ase
Each use case focuses on describing how to achieve a goal or task. or most software pro1ects this means that multiple, perhaps do
8/18/2019 Manual Testing document
53/138
Manual Testing Testing Tools MindQ
se cases should not be confused with the features of the system under consideration. #
use case may be related to one or more features, a feature may be related to one or more
use cases.# use case defines the interactions between e:ternal actors and the system under
consideration to accomplish a goal. #n actor is a role that a person or thing plays wheninteracting with the system. The same person using the system may be represented as two
different actors because they are playing different roles. or e'ample, QYoeQ could be
playing the role of a Customer when using an #utomated Teller Machine to @ithdraw
Cash, or playing the role of a Bank Teller when using the system to estock the Cash6rawer.
se cases treat the system as a black box, and the interactions with the system, including
system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done,
and avoids the trap of making assumptions about how this functionality will be
accomplished.se cases may be described at the abstract level >business use case, sometimes called
essential use case?, or at the system level >system use case?. The difference between these
is the scope.The business use case is described in technology free terminology which treats the
business process as a black bo' and describes the business process that is used by its
business actors >people or systems? to achieve their goals >e.g., manual payment
processing, e'pense report approval, manage corporate real estate.? The business use casewill describe a process that provides value to the business actor, and it describes what the
process does.
The system use cases are normally described at the sub process level >for e'ample, createvoucher? and specify the data input and the e'pected data response. The system use case
will describe how the actor and the system interact. or this reason it is recommended
that a system use case specification begin with a verb >e.g., create voucher, select payments, exclude payment, cancel voucher.?
# use case should:
6escribe how the system shall be used by an actor to achieve a particular goal. 0ave no
implementation$specific language. Be at the appropriate level of detail. Jot include detailregarding user interfaces and screens. This is done in user$interface design.
Sample Use #ase Diagrams
# use case is a set of scenarios that describing an interaction between a user and a
system. # use case diagram displays the relationship among actors and use cases. The
two main components of a use case diagram are use cases and actors.
-*
8/18/2019 Manual Testing document
54/138
Manual Testing Testing Tools MindQ
#n actor represents a user or another system that will interact with the system you are
modeling. # use case is an e'ternal view of the system that represents some action the
user might perform in order to complete a task.
@hen to se: se Cases 6iagrams
se cases are used in almost every pro1ect. They are helpful in e'posing re&uirements
and planning the pro1ect. 6uring the initial stage of a pro1ect most use cases should bedefined, but as the pro1ect continues more might become visible.
0ow to 6raw: se Cases 6iagramsse cases are a relatively easy M; diagram to draw, but this is a very simplified
e'ample. This e'ample is only meant as an introduction to the M; and use cases.
"tart by listing a se&uence of steps a user might take in order to complete an action. or e'ample a user placing an order with a sales company might follow these steps.
(. Browse catalog and select items.
). Call sales representative.*. "upply shipping information.
+. "upply payment information.
-. eceive conformation number from salesperson.
These steps would generate this simple use case diagram:
-+
8/18/2019 Manual Testing document
55/138
Manual