Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Software testing myths

•Download as DOCX, PDF•
•
Rakesh Hansalia
Rakesh Hansalia

Testing software is often misunderstood and many myths exist. Some of the more common myths include that testing is too expensive, when in reality early testing saves both time and costs. It is also a myth that testing is time consuming or that complete testing is possible, as it is impossible to test all scenarios. Additionally, while testers aim to find bugs, their role extends beyond only bug finding, as they are domain experts for the overall software.

1 of 2
SOFTWARE TESTING MYTHS Givenbeloware some of the more popularand commonmythsaboutSoftware testing. Source:http://www.tutorialspoint.com/software _te sting/te sting_myths.htm 1 Myths: Testingis too expensive. Reality: There isa saying, pay lessfortestingduringsoftware developmentorpaymore for maintenance orcorrectionlater.Earlytestingsavesbothtime andcostin manyaspectshowever, reducingthe costwithouttestingmayresultinthe improperdesignnof a software application rendering the product useless. 2 Myths: Testingis time consuming. Reality: Duringthe SDLC phasestestingisneveratime consumingprocess.Howeverdiagnosing and fixingthe errorwhichisidentifiedduringpropertestingisatime consumingbutproductive activity. 3 Myths: Testingcannot be started if the product isnot fullydeveloped. Reality: Nodoubt,testingdependsonthe source code but reviewingrequirementsanddeveloping testcases isindependentfromthe developedcode.Howeveriterative orincremental approachasa developmentlife cycle model mayreduce the dependencyof testingonthe fullydevelopedsoftware. 4 Myths: Complete TestingisPossible. Reality: Itbecomesan issue whenaclientortesterthinksthatcomplete testingispossible.Itis possible thatall pathshave beentestedbythe teambutoccurrence of complete testingisnever possible. There might be some scenariosthatare neverexecutedbythe testteamorthe clientduring the software developmentlife cycle andmaybe executedonce the projecthasbeendeployed. 5 Myths: If the software is testedthenit must be bug free. Reality:T hisisa verycommonmythwhichclients,ProjectManagersandthe managementteam believein. Noone cansay withabsolute certaintythatasoftware applicationis100% bug free evenif a testerwithsuperbtestingskillshastestedthe application. 6 Myths: Misseddefectsare due to Testers. Reality: Itis not a correct approachto blame testers forbugs that remaininthe applicationevenafter testinghasbeenperformed.ThismythrelatestoTime,Cost,and Requirementschanging Constraints. Howeverthe teststrategyymay alsoresultinbug s beingmissedbythe testingteam. 7 Myths: T estersshould be responsible forthe qualityof a product. Reality: Itis a verycommonmisinterpretationthatonlytestersorthe testingteamshouldbe
responsible forproductquality.Tester.responsibilitiesinclude the identificationof bugsto the stakeholdersandthenitistheirdecisionwhethertheywillfix the bugorrelease the software.Releasing the software at the time putsmore pressure onthe testersas theywill be blamedforanyerror. 8 Myths: Test Automationshould be usedwhereverit is possible touse it and to reduce time. Reality: Yesit istrue that Test Automationreducesthe testingtime butitisnotpossible tostartTest Automationatany time duringSoftware development.TestAutomatonshouldbe startedwhenthe software has beenmanuallytestedandisstable tosome extent.Moreover,TestAutomationcannever be usedif requirementskeepchanging. 9 Myths: Any one can test a Software application. Reality: People outside the ITindustrythinkandevenbelievethatanyone can testthe software and testingisnota creative job.Howevertestersknow verywell thatthisismyth.Thinkingalternatives Scenarios,tryto crash the Software withthe intenttoexplore potential bugsisnot possible forthe personwhodevelopedit. 10 Myths: A tester'stask isonly to find bugs. Reality: Findingbugsinthe Software isthe taskof testersbutat the same time theyare domainexperts of the particularsoftware.Developersare onlyresponsible forthe specificcomponentorareathat is assignedtothembuttestersunderstandthe overall workingsof the software,whatthe dependencies are and whatthe impactsof one module onanothermodule are.

More Related Content

Software testing myths

  • 1. SOFTWARE TESTING MYTHS Givenbeloware some of the more popularand commonmythsaboutSoftware testing. Source:http://www.tutorialspoint.com/software _te sting/te sting_myths.htm 1 Myths: Testingis too expensive. Reality: There isa saying, pay lessfortestingduringsoftware developmentorpaymore for maintenance orcorrectionlater.Earlytestingsavesbothtime andcostin manyaspectshowever, reducingthe costwithouttestingmayresultinthe improperdesignnof a software application rendering the product useless. 2 Myths: Testingis time consuming. Reality: Duringthe SDLC phasestestingisneveratime consumingprocess.Howeverdiagnosing and fixingthe errorwhichisidentifiedduringpropertestingisatime consumingbutproductive activity. 3 Myths: Testingcannot be started if the product isnot fullydeveloped. Reality: Nodoubt,testingdependsonthe source code but reviewingrequirementsanddeveloping testcases isindependentfromthe developedcode.Howeveriterative orincremental approachasa developmentlife cycle model mayreduce the dependencyof testingonthe fullydevelopedsoftware. 4 Myths: Complete TestingisPossible. Reality: Itbecomesan issue whenaclientortesterthinksthatcomplete testingispossible.Itis possible thatall pathshave beentestedbythe teambutoccurrence of complete testingisnever possible. There might be some scenariosthatare neverexecutedbythe testteamorthe clientduring the software developmentlife cycle andmaybe executedonce the projecthasbeendeployed. 5 Myths: If the software is testedthenit must be bug free. Reality:T hisisa verycommonmythwhichclients,ProjectManagersandthe managementteam believein. Noone cansay withabsolute certaintythatasoftware applicationis100% bug free evenif a testerwithsuperbtestingskillshastestedthe application. 6 Myths: Misseddefectsare due to Testers. Reality: Itis not a correct approachto blame testers forbugs that remaininthe applicationevenafter testinghasbeenperformed.ThismythrelatestoTime,Cost,and Requirementschanging Constraints. Howeverthe teststrategyymay alsoresultinbug s beingmissedbythe testingteam. 7 Myths: T estersshould be responsible forthe qualityof a product. Reality: Itis a verycommonmisinterpretationthatonlytestersorthe testingteamshouldbe
  • 2. responsible forproductquality.Tester.responsibilitiesinclude the identificationof bugsto the stakeholdersandthenitistheirdecisionwhethertheywillfix the bugorrelease the software.Releasing the software at the time putsmore pressure onthe testersas theywill be blamedforanyerror. 8 Myths: Test Automationshould be usedwhereverit is possible touse it and to reduce time. Reality: Yesit istrue that Test Automationreducesthe testingtime butitisnotpossible tostartTest Automationatany time duringSoftware development.TestAutomatonshouldbe startedwhenthe software has beenmanuallytestedandisstable tosome extent.Moreover,TestAutomationcannever be usedif requirementskeepchanging. 9 Myths: Any one can test a Software application. Reality: People outside the ITindustrythinkandevenbelievethatanyone can testthe software and testingisnota creative job.Howevertestersknow verywell thatthisismyth.Thinkingalternatives Scenarios,tryto crash the Software withthe intenttoexplore potential bugsisnot possible forthe personwhodevelopedit. 10 Myths: A tester'stask isonly to find bugs. Reality: Findingbugsinthe Software isthe taskof testersbutat the same time theyare domainexperts of the particularsoftware.Developersare onlyresponsible forthe specificcomponentorareathat is assignedtothembuttestersunderstandthe overall workingsof the software,whatthe dependencies are and whatthe impactsof one module onanothermodule are.