Testing vs. Inspection Research Paper

7/30/2019 Testing vs. Inspection Research Paper

http://slidepdf.com/reader/full/testing-vs-inspection-research-paper 1/21

Testing Vs. InspectionResearch Paper

Diala T. Gammoh, Ph.D. Student

Dr. Damla Turgut, Ph.D.

University of Central Florida,

Orlando Florida - 2007



Paper Outline – IEEE paper

format using Latex

Abstract

• Introduction

• Description

2.1 Testing2.2 Inspection

• Testing Vs. Inspection

• Conclusion

References



AbstractThis research addresses the use of the

inspection and testing tools, their

definitions, importance, and principles.There are different perspectives among

companies and organization about the

applicability of each. This research will

address these perspectives.



IntroductionSeveral studies were done to compareinspection and testing with the result that theinspection is more favorable than the testing

but it is not as widely used as testing.

Both inspection and testing have the sameobjective to raise the quality of the softwareproduct which will save time and money,

developers should be aware of the advantagesand disadvantages of both of them in order tomake their decisions, this research will helpdevelopers to make such a decision.



Software TestingSoftware testing is a process, or a seriesof processes, designed to make surecomputer code does what it was designed

to do and that it does not do anythingunintended. Software should bepredictable and consistent, offering nosurprises to users



Software TestingTesting shouldn’t be done to show thatthe program works; rather, you shouldstart with the assumption that the

program contains errors (a validassumption for almost any program) andthen test the program to find as many of the errors as possible.

“Testing is the process of executing aprogram with the intent of finding error”.



Software TestingTo combat the challenges associated with

testing economics, some strategies should

be established before beginning. Two of the most prevalent strategies include:

1. Black-box – input/output driven testing

2. White-box – logic driven testing



Software TestingA set of vital testing principles or guidelines were

Identified from “The Art of Software Testing” Book

Principle 1: A necessary part of a test case is a

definition of the expected output or result. Principle 2: A programmer should avoid attempting

to test his or her own program.

Principle 3: A programming organization should not

test its own programs.

Principle 4: Thoroughly inspect the results of each

test.

Principle 5: Test cases must be written for input

conditions that are invalid and unexpected, as well

as for those that are valid and expected.



Software TestingA set of vital testing principles or guidelines wereIdentified:

Principle 6: Examining a program to see if it does

not do what it is supposed to do is only half thebattle, the other half is seeing whether the programdoes what it is not supposed to do. Principle 7: Avoid throwaway test cases unless theprogram is truly a throwaway program. Principle 8: Do not plan a testing effort under thetacit assumption that no errors will be found. Principle 9: The probability of the existence of moreerrors in a section of a program is proportional tothe number of errors already found in that section. Principle 10: Testing is an extremely creative and

intellectually challenging task.



Software TestingMoving beyond the psychological issuesmentioned in the principles above, themost important consideration in program

testing is the design and creation of effective test cases.

The recommended procedure is to developtest cases using the black-box methods

and then develop supplementary testcases as necessary with white-boxmethods.



Software Testing



Software TestingFrom the previous figure, we can see that:

- Defects are generated in each life cycle

production activity.- Injected defects are removed in testing

activities after code is completed.- Not all defects are removed at SHIP.



Software InspectionWe need inspections to remove softwaredefects at early stages and reduced cost.

Inspections enable us to remove defectsearly in the software life cycle and it isalways cheaper to remove defects earlierthan later in the software life cycle.

It is important to note that inspectionsare a way to remove defects at a lowercost, not a way to prevent defects fromoccurring.



Software Inspection



Software InspectionAfter Inspections, residual defects areremoved during testing, but typically notall injected defects are removed.

There is still a gap of latent defects thatthe users could potentially find. In thescenario, with inspections, the gap issmaller, due to the defects removed by

inspections.

This reduced gap represents a qualityimprovement in the product delivered tothe users.



Testing Vs. InspectionWe can notice that the inspections providesignificant benefit and the publiclypublished data clearly demonstrate their

effectiveness:- Defects are not discovered all at once

during test or by the users- The increased labor hours required for

fixing defects after the product is

shipped is often due to loss of projectteam knowledge.- When fewer defects enter test, the

productivity of test improves; i.e., thecosts of test are lower and the time tocomplete test is reduced.



Testing Vs. InspectionIt is found that testing is more popularthan inspection. This is partially due to:1- Views that Inspections can only be

done one way2- Views that they are not easy to do well3- Management often views Inspections

as an added cost, when in fact and asmentioned above will reduce costsduring a project

4- With the advent of each newdevelopment tool or language, theproviders and users seem to believethat Inspections do not add value orare less necessary



ConclusionBecause of these and other factors,shortcuts in Inspection process have beentaken without any proof that the change is

an improvement. Some of thesehomegrown changes cause theInspections process to be less effective. Inturn the value of what was defined as theInspection process is diminished.



ConclusionInspections may not be the mostenjoyable engineering task compared todesigning and coding.

Also, programmers are very possessiveabout artifacts they create. Inspectionsare labor intensive and low tech, but theydo work.



ConclusionSince Inspections do work, they should beused until the software community hastruly evolved to a position where the

software process and environment permitfewer defects to be generated whensoftware products are created.



References− The Art of Software Testing Book, Glenford J.

Myers ,2004− High Quality Low Cost Software Inspections

Book, Ronald A. Radice,2002

−Inspection vs. Testing, Gustav Evertsson, 2002

− Improvement of design specifications withinspection and testing, Winkler, D.; Riedl, B.;Biffl, S.,IEEE 2005

− http://www.featuredrivendevelopment.com/node/566

− http://en.wikipedia.org/wiki/Main_Page

http://www.featuredrivendevelopment.com/node/566


http://en.wikipedia.org/wiki/Main_Page

http://en.wikipedia.org/wiki/Main_Page



Testing vs. Inspection Research Paper

Documents