This document provides best practices for writing and organizing QA tests. It discusses test plans, test suites, test cases, and different types of testing. Guidelines are provided for writing test plans, test suites, and test cases. Tips are given for writing effective test cases, including naming conventions, descriptions, assumptions, test data, and expected results. Different levels of testing are also outlined.

1. Best Practices for Writing
and Organizing QA Tests
Best Practices
Guidelines
Using Test Plans, Test Suites and Test Cases

2. Restaurant.com Best Practices for Writing and Organizing QA Tests 2 | P a g e
Revision History
Date Version Description Author
July 14, 2014 1.0 Initial Creation Sarah Goldberg
March 14, 2016 2.0 Revised/Updated Sarah Goldberg
Contents
Agile Testing.......................................................................................................................................4
What is a Test Plan?............................................................................................................................4
How to Write a Test Plan.................................................................................................................5
What is a Test Suite?...........................................................................................................................6
Creating Test Suites and Adding Test Cases ......................................................................................6
What Is A Test Case?...........................................................................................................................7
Designing Test Cases.......................................................................................................................7
Best Practices for Test Case Writing.................................................................................................7
Testing Levels.................................................................................................................................8
Tips for Writing Effective Test Cases.................................................................................................8
Test Case Naming Conventions ....................................................................................................8
Description .................................................................................................................................8
Assumptions and Preconditions ...................................................................................................9
Input Test Data............................................................................................................................9
Cover all Verification Points in Test Design Steps...........................................................................9
Attach the Relevant Artifacts .....................................................................................................10
Expected Result.........................................................................................................................10
Divide Special Functional Test Casesinto Sets.............................................................................10
Legible & Easily Understandable by Others.................................................................................10
Review......................................................................................................................................11
Reusable...................................................................................................................................11
Maintenance & Updates............................................................................................................11
Post Conditions.........................................................................................................................11
Test Case Area Classification......................................................................................................11
Types of Tests That Can Be Used To Build Test Cases.......................................................................11

3. Restaurant.com Best Practices for Writing and Organizing QA Tests 3 | P a g e
Development Testing.................................................................................................................11
Installation Testing....................................................................................................................12
Smoke and Sanity Testing..........................................................................................................12
Functional Testing.....................................................................................................................12
Non-functional Testing..............................................................................................................12
Unit Testing..............................................................................................................................12
Integration Testing....................................................................................................................13
Compatibility Testing.................................................................................................................13
Graphical User Interface Testing.................................................................................................14
Database Testing.......................................................................................................................14
Security Testing.........................................................................................................................14
User Acceptance Testing............................................................................................................15
Application Programming Interface Testing.................................................................................16
Performance Testing.................................................................................................................16
Destructive Testing....................................................................................................................17
Regression Testing.....................................................................................................................17
Internationalization and Localization..........................................................................................18
Resources ........................................................................................................................................19

4. Restaurant.com Best Practices for Writing and Organizing QA Tests 4 | P a g e
Agile Testingisa software testingpractice thatfollowsthe principlesof agile software
development.Agiletestinginvolvesall membersof across-functional agile team, withspecial expertise
contributedbytesters,toensure deliveringthe businessvalue desiredbythe customeratfrequent
intervals,workingata sustainable pace.
Agile developmentrecognizesthattestingisnotaseparate phase,butan integral partof software
development,alongwithcoding.Agile teamsuse a "whole-team"approachto"bake qualityin"tothe
software product.Testersonagile teamslendtheirexpertiseinelicitingexamplesof desiredbehavior
fromcustomersand collaboratingwiththe developmentteamtoturnthose intoexecutable
specificationsthatguide coding.Testingandcodingare done incrementallyanditeratively,buildingup
each feature until itprovidesenoughvalue torelease toproduction.
The role of a testerinan agile projectrequiresawidervarietyof skills:
 Domainknowledgeaboutthe systemundertest
 The abilitytounderstandingthe technologybe used
 A level of technical competencytobe able to interacteffective withthe development
team
Since workingincrementsof the software are releasedofteninagilesoftwaredevelopmentthere isa
needtotestoften.Thisisdone by usingautomatedacceptance testingtominimize the amountof
manual labor.Doingonlymanual testinginagile developmentwouldlikelyresultineitherbuggy
software orslipping schedulesbecause itwouldmost oftennotbe possible totestthe whole software
manuallybefore everyrelease.
What is a Test Plan?
A TestPlandocumentsthe strategythatwill be usedtoverifyandensure thata product or system
meetsitsdesignspecificationsandotherrequirements.The plantypicallycontainsadetailed
understandingof the eventual workflow.A testplanisusuallypreparedbyorwithsignificantinputfrom
the Testers. More simplyitisa wayof keepingtestcasesorganized.
Dependingonthe productandthe responsibilitytowhichthe testplanapplies,atestplanmay include a
strategyfor one or more of the following:
 DesignVerificationor Compliance Test - to be performedduringthe developmentorapproval
stagesof the product,typicallyonasmall sample of units.
 Manufacturing or Production Test - to be performedduringpreparationorassemblyof the
productin an ongoingmannerforpurposesof performance verificationandqualitycontrol.
 Acceptance or CommissioningTest- to be performedatthe time of deliveryorinstallationof
the product.

5. Restaurant.com Best Practices for Writing and Organizing QA Tests 5 | P a g e
 Service and Repair Test - to be performedasrequiredoverthe service life of the product.
 RegressionTest - to be performedonanexistingoperationalproduct,toverifythatexisting
functionalitydidn'tgetbrokenwhenotheraspectsof the environmentare changed(e.g.,
upgradingthe platformonwhichan existingapplicationruns).
A complex systemmayhave ahighlevel testplantoaddressthe overall requirementsandsupporting
testplansto addressthe designdetailsof subsystemsandcomponents.
In MicrosoftTestManager, a testplan defineswhattotest,and storesthe resultsof yourtests.All
your testsare plannedandperformedinthe contextof atest plan.A teamprojecttypicallyhasmultiple
testplans.You create a separate testplanfor eachsprint,milestone,feature,orotheriteration.If your
projectisdevelopingseveral functional areasconcurrently,youwouldalsohave separatetestplansfor
each area.
How to Write a Test Plan
Testplansoutline the processof testingthe functionalityof software.A testplandetailseachsteptaken
to achieve acertainresultandstatesthe objective of eachaction.The planalsohighlightsthe projected
resources,risks,andpersonnelinvolvedinthe test.Youshoulduse atestplan if youare seekingto
eliminatebugsandothererrorsinyour software before itbecomesavailable tocustomers.Follow the
stepsbelowtocreate a testplan.
1. Write an introduction. Anintroductionincludesageneral descriptionandschedule of atest,as
well asany relateddocuments.
 A documentdescriptionprovidesanoverall missionstatement,coveringthe
methodsthatwill be usedinthe testingprocessandthe projectedresults.Related
documentsinclude anyperipheralmaterial thatisrelevanttothe currentproject,
such as listsof specifications.A schedule detailsthe incrementsof time inwhich
each phase of the testwill be completed.
2. Write a section on requiredresources.Thissectiondescribesall of the resourcesneededto
complete the testing,includinghardware,software,testingtools,andstaff.
 Whenaccountingfor yourstaff,make sure to detail the responsibilitiesrequiredof
each memberandthe trainingneeded toexecute those responsibilities.
3. Write a section on what you are going to test. Listwhat new aspectsyouwill be testingand
whatold aspectsyouwill be re-testing.
4. Write a section on what you will not be testing. List anyfeaturesthatwill notbe testedduring
the current project.
5. Write a list of documentsthat will be produced duringtesting.

6. Restaurant.com Best Practices for Writing and Organizing QA Tests 6 | P a g e
6. Write a section on risks and dependencies. Detail all the factorsthatyourprojectdependson
and the risksinvolvedineachstep.
7. Write a section on the results ofyour project. Outline all the goalsthatyouhope to achieve
duringthe testingprocess.Detail the parametersforwhichsuccessandfailure canbe
measured.
What is a Test Suite?
Testcases can be organizedintoa hierarchyof TestSuites inside testplans.Testsuitescanidentifygaps
ina testingeffortwherethe successfulcompletionof one testcase mustoccur before beginningthe
nexttestcase.For instance,youcannotadd new productsto a shoppingcart before yousuccessfullylog
into the application.A testcase can be sharedbetweentestplans,sothatyoucan repeatthe same test
insuccessive sprints.
Creating Test Suites and Adding Test Cases
There are differenttypesof testsuiteswhichcanbe usedintest plans. Youcan add a test case to more
than one suite ortestplan,or none.Deletingasuite doesnotdelete itstestcases.
MicrosoftTest Manager allowsyoutocreate three typesof suites:
 StaticTest Suites are like folders.A statictestsuite cancontainbothtest casesand
othersuites.The rootsuite of the test planisa static suite.
 Requirements-based TestSuites are derivedfromProductBacklogItems,User
Stories,orotherrequirements.The suite containsall the testcasesthatare linked
to itsrequirement.Thistype helpsyoutrackhow well eachrequirementhasbeen
tested.Wheneveryouaddor remove atestcase froma requirements-basedsuite,
the linkbetweenthe requirementandthe testcase is createdor destroyed.
 Query-based TestSuites show the resultsof aquerythat youdefine.Forexample,
youcouldselectall the testcasesthat have Priority= 1. Youeditit to selectthe test
case workitemsthatyou want.You can edititagainlater.The queryruns
automaticallyeverytimeyouopenorrunthe suite.Youshouldnotchange the first
twoclausesinthe workitemquery.Theyensure thatthe workitemsare testcases
inyour project.
Whenyoucreate a newtestplan,youmightwant to copysome of the suitesfromanearliertestplan.
The Copy buttondoesnotcreate newtestcases.Instead,the copiedtestsuitesrefertothe same test
cases.
Delete asuite onlyif ithas notbeenused.Otherwise,setitsstate to Completed.Whenyoudelete atest
suite,anynestedtestsuitesare deleted,butthe testcasesitrefersto are unchanged.

7. Restaurant.com Best Practices for Writing and Organizing QA Tests 7 | P a g e
What Is A Test Case?
A TestCase is simplyalistof actionswhichneedtobe executedtoverifyaparticularfunctionalityor
feature of yourapplicationundertest.
Lesssimply,atestcase isa setof conditionsorvariablesandinputsthatare developedforaparticular
goal or objective tobe achievedona certainapplicationtojudge itscapabilitiesorfeatures.
It mighttake more than one testcase to determine the true functionalityof the applicationbeing
tested.Everyrequirementorobjective tobe achievedneedsatleastone testcase.Some software
developmentmethodologieslikeRational UnifiedProcess(RUP) recommendcreatingatleasttwotest
casesfor each requirementorobjective;one forperformingtestingthroughpositive perspectiveand
the otherthroughnegative perspective.
Designing Test Cases
Testcases shouldbe designedandwrittenbysomeone whounderstandsthe functionortechnology
beingtested.A testcase shouldinclude the followinginformation -
 Purpose of the test
 Software requirementsandHardware requirements(ifany)
 Specificsetuporconfigurationrequirements
 Descriptiononhowto performthe test(s)
 Expectedresultsorsuccesscriteriaforthe test
Designingtestcasescanbe time consumingina testingschedulebut theyare worth it.Designingproper
testcases isvital forsoftware testingplansasa lotof bugs,ambiguities,inconsistenciesandslipupscan
be recoveredintime.Italsohelpsinsaving time oncontinuousdebuggingandre-testingtestcases.
One of the mostchallengingaspectsof software testingisdesigninggoodtestcases.Since testcaseslay
a foundationforeffective testmanagement,andfurtherforsustenance engineering,itshouldbe
treatedas a productitself andtestprofessionalsshouldtake pride inthe qualityof the testcases
because itistheircreation.
Best Practices for Test Case Writing
Writingeffective testcasesisaskill thatcan be achievedbysome experience andin-depthstudyof the
applicationonwhichtestcasesare beingwritten.The basicobjectiveof writingtestcasesistovalidate
the testingcoverage of the application.The testcasesshouldbe writteninenoughdetailthattheycould
be givento a newteammemberwhowouldbe able toquicklystartto carry out the testsand find
defects.
The most extensive effortinpreparingtotestanapplication,iswritingtestcases.Documentingthe test
casesprior to testexecutionensuresthatthe testerdoesthe ‘homework’andispreparedforthe
‘attack’on the Application undertest.

8. Restaurant.com Best Practices for Writing and Organizing QA Tests 8 | P a g e
Testing Levels
There are levelsinwhicheachtestcase will fall inordertoavoidduplicationefforts.
Level 1: In thislevel youwillwrite the basictestcasesfromthe available specificationanduser
documentation.Itisagood ideato coverthe entire positivescenariosfirstandthenthinkabout
all possibilitiesof negative scenarios;thesewilleffectivelyfindmostof the bugs.
Level 2: Thisis the practical stage in which writingtestcasesdependonactual functional and
systemflowof the application.
Level 3: Thisis the stage in whichyouwill groupsome testcasesandwrite a testprocedure.
Testprocedure isnothingbuta group of small testcases maximumof 10
Level 4: Automationof the project.Thiswill minimize humaninteractionwithsystemandthus
QA can focuson currentupdatedfunctionality'stotestratherthanremainingbusywith
regressiontesting.
Tips for Writing Effective Test Cases
TestCase NamingConventions.It’salwaysagoodpractice toname yourtestcases ina way that it
makessense toanyone whoisgoingto referthe testinfuture.Name the testcase to representthe
module name orfunctional areayouare goingto verifyinthattestcase.
For example,if Iamworkingona project“Mainsite”whichhasa functional areacalled“Login”andwant
to write a testto verifyasimple checkwhetherthe userisable tologintothe website usinganemail
and password,insteadof namingthe testsasTC_01, I coulduse the below namingconventionsothatI
can make out whatthe testisfor justby lookingatitsname.
 Mainsite _Login_ValidCredentials
 Mainsite _Login_InvalidCredentials
Descriptioniswhere youmentionall the detailsaboutwhatyouare goingto test, and the particular
behaviorbeingverifiedbythe test.Tryto make the descriptionof the testprocessandthe possible
resultsascomprehensiveanddetailedaspossible.Trytothinkof any assumptionsyoumaybe making
aboutthe processand insteadwrite themoutexplicitly.Examplesinclude specifyingwhetheratest
shouldstartwitha cleaninstallationof the software tobe tested(orthe distributionasawhole),or
whethertocreate some initial configurationbefore runningatest.Try to place yourself inthe shoesof
someone whoisentirelyunfamiliarwiththe functiontobe tested,andmake sure theycansuccessfully
complete the testsimplybyfollowingthe procedure.Asmuchaspossible,withoutcompromising
comprehensiveness,tryto write the testcase suchthat it will notgo'stale'.Try to ensure yourtestcase
will be usable foralongtime withoutregularediting.
The followinginformationwouldbe foundinawell-writtentestcase description:
 Testto be carriedout / behavior beingverified
 PreconditionsandAssumptions(anydependencies)
 TestData to be used

9. Restaurant.com Best Practices for Writing and Organizing QA Tests 9 | P a g e
 TestEnvironmentDetails(ifapplicable)
 Any Testingtools tobe usedforthe test
AssumptionsandPreconditions.While writingtestcases,youshouldcommunicate all assumptions
that applyto a test,alongwithanypreconditionsthatmustbe metbefore the testcan be executed.
Beloware the kindof detailsthatshouldbe coveredinthissection:
 Anyuserdata dependency(e.g.the usershouldbe loggedin,whichpage shouldthe userstart
the journey,etc.)
 Dependenciesontestenvironment
 Anyspecial setuptobe done before TestExecution
 Dependenciesonanyothertestcases – doesthe Test Case needtobe run before/aftersome
otherTest Case?
Again,the more detailedinformationprovidedthe more accurate the testcaseswill be.
Input Test Data. Identifyingtestdatacan be a time consumingactivity –manya timestestdata
preparationtakesmostof the time ina testingcycle.
To make life easyasa tester(whereverapplicable)recordtestdatato be usedfor the testcase within
T.C. descriptionorwiththe specifictestcase steps.Thissavesalot of time inthe longrunas you won’t
have to huntfor newtestdata everytime youneedtoexecute the test.
A fewpointers:
 In manycaseswhere youknowthe testdata can be re-usedovertime,youcanmentionthe
exactTest Data to be usedfor the test.
 If the testonlyinvolvessome valuestobe verified,youcanoptto specifythe value range or
describe whatvaluesare tobe testedforwhichfield.Youcando so for negative scenariosas
well.
 Testingwitheveryvalue isimpractical,soyoucan choose a few valuesfromeachequivalence
classwhichshouldprovide goodcoverage foryourtest.
 You couldalsodecide tomentionthe type of datawhichis requiredtorunthe test andnot the
real testdata value.Thisappliesforprojectswhere the testdatakeepsonchangingasmultiple
teamsuse it andmay not be in the same state whenI use itthe nexttime.So,mentioning the
type/state of usertestdatato be usedhelpsagreat deal foranyone whoisrunningthe test
next!
Coverall VerificationPointsinTestDesignSteps.Anotherimportantpartof a well-writtentest
case isthe properlydefinedTestCase Steps. The stepsshouldnotonlycoverthe functional flow but
alsoeach verificationpointwhichshouldbe tested.

10. Restaurant.com Best Practices for Writing and Organizing QA Tests 10 | P a g e
By comparingyourTest Case stepswiththe Requirementdocuments,Use Cases,UserStoriesorProcess
Maps givenforyour project,youcan make sure that the Test Case optimallycoversall the verification
points.
Attach the RelevantArtifacts.Whereverpossible youshouldattachthe relevantartifactstoyourtest
case.If the change you are goingto testis veryminor,youcouldconsidermentioningitinthe teststep
itself.
ExpectedResult.A well-writtenTestCase clearlymentionsthe expectedresultof the
application/systemundertest.Eachtestdesignstepshouldclearlymentionwhatyouexpectas
outcome of that verificationstep. So,while writingtestcases,mentionindetail whatpage/screenyou
expecttoappearafterthe testand,any changesyouexpecttobe done toany backendlegacysystems
or Database.
You can alsoattach screenshotsorspecificationdocumentstothe relevantstepandmentionthatthe
systemshouldworkasoutlinedinthe givendocumenttomake thingssimpler.
DivideSpecial Functional TestCasesinto Sets Foreffectivetestcase writing,considerbreaking
downthe Test Casesintosetsandsub-setstotestsome special scenarioslikebrowserspecific
behaviors,cookie verification,usabilitytesting, WebService testingandcheckingerrorconditionsetc.
If you strive towrite effective testcases,youshouldwritethese special functionaltestcasesinisolation.
For instance,TestCasesthatcheck errorconditionsshouldbe writtenseparatelyfromthe functional
testcases andshouldhave stepstoverifythe errormessages.
For example, if youneedtoverifyhowthe loginfeatureforanyapplicationworkswithinvalidinput,you
can breakthisnegative testingforloginfunctionalityintosubtestsfordifferentvalues like:
 Verifywithinvalidemail-id
 Verifywithinvalidpassword
 Verifywithblankemail-idfieldandsoon…
Legible&EasilyUnderstandablebyOthers.WhendesigningTestCases,considerthattheywill not
alwaysbe executedbythe oneswhodesignthem.So,the testsshouldbe easilyunderstandable,legible
and to-the-point.
TestCase suitesthatare onlyclearto the oneswhodesignedthemare ubiquitous.
Write TestCases that:
 Are Simple andeasilyunderstandable byeveryone
 Are to-the-point. If aTest Case isgoingbeyonda certainamountof steps,breakitintoa new
TestCase
 Still have enoughcoverage

11. Restaurant.com Best Practices for Writing and Organizing QA Tests 11 | P a g e
Review. WithTestCasesplayinganimportantrole in Software TestingLife-cycle,makingsure theyare
correct and conformto standardsbecomesevenmore necessary.Testcase review canbe done bypeer
testers, BA,developers,productownersoranyrelevantstakeholders.
Reusable.Keepinmindwhen,writingtestcases,thattheycouldbe re-usedinthe future forsome
otherproject/teams.Onthatnote,before writinganew TestCase for yourproject/module,alwaystry
and findoutif there are TestCaseswrittenalreadyforthe same test.
If you spendbitof a time withotherteamsfindingoutthe existingtestcases,youwon’triskrepeating
any testcases,hence avoidinganyredundanciesinTestManagementTools.Also,if yougetthe existing
testcases writtenearlieraroundthe same module,youshouldbe updatingthose insteadof writingnew
TCs. Also,if youneedaparticulartestcase to execute some othertestcase,youcansimplycall the
existingtestcase inthe preconditionsoratthe specifictestdesignstep.
Maintenance&Updates. It’sof umpteenimportance tomake sure thatthe TestCasesare always
updatedasper the newlyintroducedchangesinthe applicationtheyapplyto.Alwaysconsiderupdating
the existingTestCases(if any) beforeyoustartwritingNew TestCases.
Reiteratingreusability, incase of any changesto an existingjourneyorfunctionality,youshould
considerupdatingthe existingTestCasesinsteadof writinganynew TestCaseshence avoiding
redundanciestothe existingset.
Thisalsomakessure you alwayshave updatedTestCasesforany journeyinyourapplication.
Post Conditions basicallyspecifythe variousthingsthatneedtobe verifiedafterthe Testhasbeen
carriedout. Inaddition,post-conditionsare alsousedtogive guidinginstructiontorestore the systemto
itsoriginal state forit notto interfere withsubsequenttesting.
For example,thisisquiteuseful if youmentionthe changestobe made to a testdata for it to be used
for a laterTestCase forthe same functionality.
TestCase AreaClassification.Use the TestCase AreaClassificationto‘link’the casestogetherand
ensure theycaneasilybe found bothmanuallyandautomatically.Youshouldalwaysuse the
appropriate areawhenevercreatingatestcase inorderto helppeople locate the testcase inthe future.
Types of Tests That Can Be Used To Build Test Cases
DevelopmentTesting isasoftware developmentprocessthatinvolvessynchronizedapplicationof a
broad spectrumof defectpreventionanddetectionstrategiesinordertoreduce software development
risks,time,andcosts.It isperformedbythe software developerorengineer duringthe construction
phase of the software developmentlifecycle.Ratherthanreplace traditional QA focuses,itaugmentsit.
Developmenttestingaimstoeliminate constructionerrorsbefore code ispromotedtoQA;thisstrategy

12. Restaurant.com Best Practices for Writing and Organizing QA Tests 12 | P a g e
isintendedtoincrease the qualityof the resultingsoftware aswell asthe efficiencyof the overall
developmentandQA process.
Dependingonthe organization'sexpectationsforsoftware development,Developmenttestingmight
include staticcode analysis,dataflowanalysismetricsanalysis,peercode reviews,unittesting,code
coverage analysis,traceability,andothersoftware verificationpractices.
InstallationTesting assuresthatthe systemisinstalledcorrectlyandworkingwithactual customer's
hardware.
SmokeandSanity Testing can be usedas buildverificationtests.Sanitytestingdetermineswhetherit
isreasonable toproceedwithfurthertesting. Smoke testingconsistsof minimal attemptstooperate the
software,designedtodetermine whetherthere are anybasicproblemsthatwill preventitfromworking
at all.
Functional Testing isdesignedto measure the qualityof the functionalcomponentsof the system.
TestCasesverifythatthe systembehavescorrectlyfromthe user/businessperspectiveandfunctions
accordingto the requirements,models,storyboards,oranyother designparadigmusedtospecifythe
application.The functional testcasesmustdetermine if eachcomponentorbusinessevent:performsin
accordance to the specifications,respondscorrectlytoall conditionsthatmaybe presentedbyincoming
events/data,movesdatacorrectlyfromone businesseventtothe next(includingdatastores),andthat
businesseventsare initiatedinthe orderrequiredtomeetthe businessobjectivesof the system.
Non-functional Testing referstoaspectsof the software thatmay notbe relatedtoa specificfunction
or useraction,such as scalability orotherperformance,behaviorundercertain constraints,orsecurity.
Testingwill determine the breakingpoint,the pointatwhichextremesof scalabilityorperformance
leadstounstable execution.Non-functional requirementstendtobe those thatreflectthe qualityof the
product,particularlyinthe contextof the suitabilityperspective of itsusers.
Unit Testing verifiesthe individual unitof source code,setsof one ormore computerprogram
modulestogetherwithassociatedcontrol data,usage procedures,andoperatingproceduresare tested
to determine if theyare fitforuse.A unitcan be viewedasthe smallest testable partof an application.
In procedural programming,aunitcouldbe an entire module,butitismore commonlyanindividual
functionorprocedure.In object-orientedprogramming,aunitisoftenan entire interface,suchasa
class,but couldbe an individualmethod.Unittestsare shortcode fragmentscreatedbyprogrammersor
occasionallyby white box testers duringthe developmentprocess.
Unit testingprovidesasort of livingdocumentationof the systemandembodycharacteristicsthatare
critical to itssuccess.Developerslookingtolearnwhatfunctionalityisprovidedbyaunitand how to use
it can lookat the unitteststo gaina basicunderstandingof the unit'sinterface (API).Unittestcases
embodycharacteristicsthatare critical to the successof the unit.These characteristicscanindicate
appropriate/inappropriate use of aunitas well asnegative behaviorsthatare to be trappedbythe unit.
A unittestcase,in andof itself,documentsthesecritical characteristics,althoughmanysoftware
developmentenvironmentsdonotrelysolelyuponcode todocumentthe productindevelopment.

13. Restaurant.com Best Practices for Writing and Organizing QA Tests 13 | P a g e
IntegrationTesting isusedto identifyproblemsthatoccurwhenunitsare combined.Initssimplest
form,twounits(that have alreadybeentested) are combinedintoacomponentandthe interface
betweenthemistested.Thistype of testingistypicallydone afterunittestingandbefore system
testing.Some differenttypesof integrationtestingare bigbang, top-down,andbottom-up,and
Sandwich.
 Big Bang Testing,all or mostof the developedmodulesare coupledtogethertoforma
complete software systemormajorpart of the systemandthenusedforintegrationtesting.
The Big Bang methodisveryeffectiveforsavingtime in the integrationtestingprocess.
However,if the testcasesandtheirresultsare not recordedproperly,the entire integration
processwill be more complicatedandmaypreventthe testingteamfromachievingthe goal of
integrationtesting.
 Bottom-UpTesting isan approach to integratedtestingwhere the lowestlevel componentsare
testedfirst,thenusedtofacilitate the testingof higherlevelcomponents.The processis
repeateduntil the componentatthe top of the hierarchyistested.All the bottom orlow-level
modules,proceduresorfunctionsare integratedandthentested.Afterthe integrationtesting
of lowerlevel integratedmodules,the nextlevel of moduleswill be formedandcanbe usedfor
integrationtesting.Thisapproachishelpfulonly whenall ormostof the modulesof the same
developmentlevel are ready.Thismethodalsohelpstodeterminethe levelsof software
developedandmakesiteasiertoreporttestingprogressinthe formof a percentage.
 Top-Down Testingis an approachto integratedtestingwhere the topintegratedmodulesare
testedandthe branch of the module istestedstepbystepuntil the endof the relatedmodule.
 Sandwich Testingis an approachto combine topdowntestingwithbottomuptesting.
By usinga testplanthat requiresyoutotesteach unitand ensure the viabilityof eachbefore combining
units,youknowthat anyerrors discoveredwhencombiningunitsare likelyrelatedtothe interface
betweenunits.The overall ideaisa"buildingblock"approach,inwhichverifiedassemblagesare added
to a verifiedbase whichisthenusedtosupportthe integrationtestingof furtherassemblages.This
methodreducesthe numberof possibilitiestoafar simplerlevel of analysis.
CompatibilityTestingA commoncause of software failure (real orperceived) isalackof its
compatibility withotherapplicationsoftware, operatingsystems,ortargetenvironmentsthatdiffer
fromthe original.Forexample,inthe case of a lack of backwardcompatibility, thiscanoccur because
the programmersdevelopandtestsoftware onlyonthe latestversionof the targetenvironment,which
not all usersmaybe running.Thisresultsinthe unintendedconsequence thatthe latestworkmaynot
functiononearlierversions of the targetenvironment,oronolderhardware thatearlierversionsof the
target environmentwascapable of using.Sometimessuchissuescanbe fixedbyproactively abstracting
operatingsystemfunctionalityintoaseparate program module orlibrary.

14. Restaurant.com Best Practices for Writing and Organizing QA Tests 14 | P a g e
Graphical UserInterfaceTesting isusedtotest an application'sgraphical userinterface andto
detectif applicationisfunctionallycorrectandmeetsitswrittenspecifications.GUItestinginvolves
carryingset of tasks andcomparingthe resultof same withthe expectedoutputandabilitytorepeat
same setof tasksmultiple timeswithdifferentdatainputandsame level of accuracy.GUI Testing
includeshowthe applicationhandleskeyboardandmouse events,how differentGUIcomponentslike
menubars,toolbars,dialogs,buttons,editfields,listcontrols,imagesetc.reactstouserinputand
whetherornot itperformsinthe desiredmanner.ImplementingGUItestingforyourapplicationearlyin
the software developmentcycle speedsupdevelopment,improvesqualityandreducesriskstowards
the endof the cycle.GUI Testingcan be performedbothmanuallywithahumantesterorcouldbe
performedautomaticallywithuse of asoftware program.
DatabaseTesting involvestestingstrategiessuchasqualitycontrol andqualityassurance of the
productdatabases. Black-box testingandWhite-boxtestingare differentdatabase testingmethods.
Black Box Testinginvolvestestinginterfacesandthe integrationof the database,whichincludes:
1. Mappingof data (including metadata)
2. Verifyingincomingdata
3. Verifyingoutgoingdatafromqueryfunctions
4. VarioustechniquessuchasCause effectgraphingtechnique, equivalence partitioning and
boundary-valueanalysis.
Withthe helpof these techniques,the functionalityof the database canbe testedthoroughly.
White boxTesting mainlydealswiththe internalstructure of the database.The specificationdetailsare
hiddenfromthe user.
1. It involvesthe testingof database triggersandlogical viewswhich are goingtosupport database
refactoring.
2. It performsmodule testingof database functions,triggers,views, SQLqueriesetc.
3. It validatesdatabase tables,datamodels,databaseschemaetc.
4. It checksrulesof Referentialintegrity.
5. It selectsdefault table valuestocheckon database consistency.
6. The techniquesusedinwhite box testingare conditioncoverage,decisioncoverage,statement
coverage, cyclomaticcomplexity.
The main advantage of white box testingindatabase testingisthatcodingerrorare detected,so
internal bugsinthe database can be eliminated.The limitationof white box testingisthatSQL
statementsare notcovered.
SecurityTesting isusedto determinethataninformationsystemprotectsdataandmaintains
functionalityasintended.The securitytestingisperformedtocheckwhetherthere isanyinformation
leakage byencryptingthe applicationorusingwide range of software’sandhardware'sandfirewall etc.
securitytestingtechniquescommonlyusedare;Networkscanning,Vulnerabilityscanning,Password

15. Restaurant.com Best Practices for Writing and Organizing QA Tests 15 | P a g e
cracking,Log review,Integritycheckers,Virusdetection,Wardialing,Wardriving(wirelessLAN testing),
Penetrationtesting.
Securitytestingiscarriedoutwhensome importantinformationandassets,managedbythe software
application,are of significantimportance tothe organization.Failuresinthe software securitysystem
can be seriousespeciallywhennotdetected,therebyresultinginalossor compromise of information
withoutthe knowledge of thatloss.
The securitytestingshouldbe performedbothpriortothe systemgoingintothe operationandafterthe
systemisputintooperation.
Security testingasa termhas a numberof differentmeaningsandcanbe completedinanumberof
differentways. The six basicsecurity testingconcepts are:
 Authentication- Testingthe authenticationschemameansunderstandinghow the
authenticationprocessworksandusingthatinformationtocircumventthe authentication
mechanism.Basically,itallowsareceivertohave confidence thatinformationitreceives
originated fromaspecificknownsource.
 Authorization- Determiningthatarequesterisallowedtoreceive aservice orperforman
operation.
 Availability- Assuringinformationandcommunicationsserviceswill be readyforuse when
expected.Informationmustbe keptavailabletoauthorizedpersonswhentheyneedit.
 Confidentiality- A securitymeasure whichprotectsthe disclosure of dataor informationto
partiesotherthanthe intended.
 Integrity– Whetherthe intendedreceiverreceivesthe informationordatawhichisnot altered
intransmission.
 Non-repudiation- Interchange of authenticationinformationwithsome formof provable time
stampe.g.withsessionidetc.
UserAcceptanceTesting (inagile software development)are usuallycreatedbybusinesscustomers
and expressedinabusinessdomainlanguage.UserAcceptance Testingisalsoknownasbetatesting,
applicationtestingorendusertesting. These are high-level teststoverifythe completenessof auser
story or stories'played'duringanysprint/iteration.Thesetestsare createdideallythroughcollaboration
betweenbusinesscustomers,businessanalysts,testers,anddevelopers.It'sessentialthatthese tests
include bothbusinesslogictestsaswell asUI validationelements(if needbe).The businesscustomers
(productowners) are the primary projectstakeholderof these tests.The workassociatedwithUAT
beginsafterrequirementsare writtenandcontinuesthroughthe final stage of testingbeforethe
client/useracceptsthe newsystem.

16. Restaurant.com Best Practices for Writing and Organizing QA Tests 16 | P a g e
Agile UserAcceptance Testingbeginswhenuserstoriesare defined. A userstory shouldinclude both
storyand acceptance testcases (alsoknownasacceptance criteria). One techniqueforcreating and
groominguserstoriesgathersarepresentative fromthe business,professional testinganddevelopment
so that all majorconstituenciesare represented. Asa storyis defined,soare the acceptance criteria.
Addingthe focusonbusinessacceptance criteriaduringthe definitionof userstoriesbeginsthe UAT
process,ratherthan waitinguntil laterinthe project.Layingoutthe acceptance criteriawhenyoubegin
workon a story createsa focusthat helpsthe teamto stay focusedonwhatisactuallyneededand
reducesthe potential forreworkaddingextrafeatures.
ApplicationProgrammingInterfaceTesting islike testingsoftware atthe user-interface level,only
insteadof testingbymeansof standarduserinputsand outputs,youuse software tosend callstothe
API,getoutput,and logthe system’sresponse.Dependingonthe testingenvironment,youmayuse a
suite of preparedtestapplications,butveryoften,youwillwindupwritingcode specificallytotestthe
API.Regardlessof the actual testingconditions,itisimportanttoknow whatAPItestcode shoulddo.
An APIisa set of procedures,functions,andotherpointsof accesswhichan application,anoperating
system,alibraryetc.,makesavailable toprogrammersinordertoallow itto interactwithother
software.AnAPIisa bit like auserinterface,only insteadof auser-friendlycollectionof windows,dialog
boxes,buttons,andmenus,the APIconsistsof asetof directsoftware links,orcalls,tolower-level
functionsandoperations.Thoroughapplicationprogramminginterface testingshouldcoveratleastthe
following:
 Discovery Testing- Testersshouldmanuallyexercisethe setof callsdocumentedinthe API.
 UsabilityTesting- Usabilitytestingevaluateswhetherthe APIisfunctionalandfriendlyfromthe
perspective of acustomer(typicallyasoftware developer) whowill be usingittobuild
something.Doesthe APIintegratewellwiththe platformsitsintendedfor?Isitconsistent,and
at a reasonable levelof abstraction?Basically,doesitmake sense?
 Security Testing- Are securityrequirementsdefinedforthe API?Whattype of authentication,if
any,is required,andwhatpermissionsstructuresmayapply?Issensitive dataalwaysencrypted,
sentoverHTTPS, or both?Are there wayspeople cangetaccess to thingstheyshouldn't?
 Automated Testing- Ingeneral,APItestingshouldculminateinthe creationof a setof scripts,
or a tool,thatcan be usedtoregularlyexercisethe APIandreporterrorswithminimal human
interaction.
PerformanceTesting determineshowasystemperformsintermsof responsivenessandstability
undera particularworkload.Itcan alsoserve to investigate,measure,validateorverifyother quality
attributes of the system,suchas scalability,reliability andresource usage. Theydescribe the typesof
usersand numberof usersof each type that will be simulatedinaperformance test.TestDesigner
shouldgothroughthe non-functional requirementdocumentbefore authoringthe performance test
case. There are a fewtesttypesthat can be usedto testperformance of a system:

17. Restaurant.com Best Practices for Writing and Organizing QA Tests 17 | P a g e
 Load Testing- The simplestformof performance testing.A loadtestisusuallyconductedto
understandthe behaviorof the systemunderaspecificexpectedload.Thisloadcanbe the
expectedconcurrentnumberof usersonthe application performingaspecificnumberof
transactions withinthe setduration.Thistestwill giveoutthe response timesof all the
importantbusinesscritical transactions.If the database, applicationserver,etc.are also
monitored,thenthissimple testcanitself pointtowards bottlenecks inthe applicationsoftware.
 Stress Testing- Normallyusedtounderstandthe upperlimitsof capacitywithinthe system.This
kindof testis done to determinethe system'srobustnessintermsof extremeloadandhelps
applicationadministratorstodetermine if the systemwillperformsufficientlyif the currentload
goeswell above the expectedmaximum.
 Soak Testing - Alsoknownasendurance testing,isusuallydone todetermine if the systemcan
sustainthe continuousexpectedload.Duringsoaktests,memoryutilizationismonitoredto
detectpotential leaks.Alsoimportant,butoftenoverlookedisperformance degradation.That
is,to ensure thatthe throughputand/orresponse timesaftersome longperiodof sustained
activityare as good as or betterthanat the beginningof the test.Itessentiallyinvolvesapplying
a significantloadtoa systemforan extended,significantperiodof time.The goal istodiscover
howthe systembehavesundersustaineduse.
 Spike testing- Done by suddenlyincreasingthe numberof orload generatedbyusers - bya very
large amount- and observingthe behaviorof the system.The goal isto determinewhether
performance will suffer,the systemwill fail,oritwill be able tohandle dramaticchangesinload.
 Configurationtesting- Ratherthan testingforperformance fromthe perspective of load,tests
are createdto determinethe effectsof configurationchangestothe system'scomponentson
the system'sperformance andbehavior.A commonexample wouldbe experimentingwith
differentmethodsof load-balancing.
 Isolationtesting- It’s notunique toperformance testingbutinvolvesrepeatingatestexecution
that resultedinasystemproblem.Oftenusedtoisolate andconfirmthe faultdomain.
DestructiveTesting attemptstocause the software ora sub-systemtofail.Itverifiesthatthe
software functionsproperlyevenwhenitreceivesinvalidorunexpectedinputs,therebyestablishingthe
robustness of inputvalidationanderror-managementroutines.
RegressionTesting focusesonfindingdefectsafteramajorcode change has occurred.Specifically,it
seekstouncoversoftware regressions,asdegradedorlostfeatures,includingoldbugsthathave come
back. Suchregressionsoccurwheneversoftware functionalitythatwaspreviously working,correctly,
stopsworkingas intended.Typically,regressionsoccurasan unintendedconsequence of program
changes,whenthe newlydevelopedpartof the software collideswiththe previouslyexistingcode.

18. Restaurant.com Best Practices for Writing and Organizing QA Tests 18 | P a g e
Commonmethodsof regressiontestinginclude re-runningprevioussetsof test-casesandchecking
whetherpreviouslyfixedfaultshave re-emerged.The depthof testingdependsonthe phase inthe
release processandthe riskof the addedfeatures.Theycan eitherbe complete,forchangesaddedlate
inthe release ordeemedtobe risky,orbe veryshallow,consistingof positive testsoneachfeature,if
the changesare earlyinthe release ordeemedtobe of low risk.
Regressiontestingistypicallythe largesttesteffortincommercial softwaredevelopment,due to
checkingnumerousdetailsinpriorsoftware features,andevennewsoftware canbe developedwhile
usingsome oldtest-casestotestpartsof the new designtoensure priorfunctionalityisstill supported.
InternationalizationandLocalization,the generalabilityof software tobe internationalizedand
localized canbe automaticallytestedwithoutactual translation,byusing pseudo-localization.Itwill
verifythatthe applicationstill works,evenafterithasbeentranslatedintoanew language oradapted
for a newculture (suchas differentcurrenciesortime zones).
Actual translationtohumanlanguagesmustbe tested,too.Possible localizationfailuresinclude:
 Software isoftenlocalizedbytranslatingalistof stringsoutof context,andthe translatormay
choose the wrongtranslationforan ambiguoussource string.
 Technical terminologymaybecome inconsistentif the projectistranslatedbyseveral people
withoutpropercoordinationor if the translatorisimprudent.
 Literal word-for-wordtranslationsmaysoundinappropriate,artificial ortootechnical inthe
target language.
 Untranslatedmessagesinthe original language maybe left hardcoded inthe source code.
 Some messagesmaybe createdautomaticallyatruntime andthe resultingstringmaybe
ungrammatical,functionallyincorrect,misleadingorconfusing.
 Software mayuse a keyboardshortcut whichhasno functiononthe source language's keyboard
layout,butisusedfor typingcharactersin the layoutof the target language.
 Software maylacksupportfor the character encodingof the targetlanguage.
 Fontsand fontsizeswhichare appropriate inthe source language maybe inappropriate inthe
target language;forexample, CJKcharactersmaybecome unreadable if the fontistoosmall.
 A stringinthe targetlanguage maybe longerthanthe software canhandle.Thismaymake the
stringpartlyinvisible tothe useror cause the software tocrash or malfunction.
 Software maylackpropersupportfor readingor writing bi-directional text.
 Software maydisplayimageswithtextthatwasnot localized.
 Localizedoperatingsystemsmayhave differentlynamedsystem configurationfiles and
environmentvariables anddifferentformatsfordate andcurrency.

19. Restaurant.com Best Practices for Writing and Organizing QA Tests 19 | P a g e
Resources
http://en.wikipedia.org/wiki/Agile_testing
http://agiletesting.com.au/
http://quicksoftwaretesting.com/test-case-writing-tips/
http://www.testingexcellence.com/test-cases-best-practices/
http://softwaretestinggarbage.blogspot.com/2012/06/security-testing.html
http://softwaretestingguidetocrackinterviews.blogspot.com/2011/01/best-practice-for-test-case-
writing.html
http://university.utest.com/integration-testing-tips/
http://www.versionone.com/pdf/wp_agiletester.pdf
http://www.rbcs-us.com/blog/2012/06/08/test-plans-and-test-cases-in-agilescrum/