Testing Vs. Inspection Research 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

Abstract

This research addresses the use of theinspection and testing tools, theirdefinitions, importance, and principles.There are different perspectives amongcompanies and organization about theapplicability of each. This research willaddress these perspectives.

IntroductionSeveral studies were done to compare inspection and testing with the result that the inspection is more favorable than the testing but it is not as widely used as testing.

Both inspection and testing have the same objective to raise the quality of the software product which will save time and money, developers should be aware of the advantages and disadvantages of both of them in order to make their decisions, this research will help developers to make such a decision.

Software Testing

Software testing is a process, or a series of processes, designed to make sure computer code does what it was designed to do and that it does not do anything unintended. Software should be predictable and consistent, offering no surprises to users

Software Testing

Testing shouldn’t be done to show that the program works; rather, you should start with the assumption that the program contains errors (a valid assumption for almost any program) and then test the program to find as many of the errors as possible.

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

Software Testing

To combat the challenges associated withtesting economics, some strategies shouldbe established before beginning. Two ofthe most prevalent strategies include:

1. Black-box – input/output driven testing2. White-box – logic driven testing

Software TestingA set of vital testing principles or guidelines wereIdentified from “The Art of Software Testing” Book

Principle 1: A necessary part of a test case is adefinition of the expected output or result.Principle 2: A programmer should avoid attemptingto test his or her own program.Principle 3: A programming organization should nottest its own programs.Principle 4: Thoroughly inspect the results of eachtest.Principle 5: Test cases must be written for inputconditions that are invalid and unexpected, as wellas 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 doesnot 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 the program 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 andintellectually challenging task.

Software TestingMoving beyond the psychological issues mentioned in the principles above, themost important consideration in programtesting is the design and creation ofeffective test cases.

The recommended procedure is to develop

test cases using the black-box methodsand 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 are removed 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 byinspections.

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 theireffectiveness:- 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 project team knowledge.

- When fewer defects enter test, the productivity of test improves; i.e., the costs of test are lower and the time to complete 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 as mentioned above will reduce costs during a project

4- With the advent of each new development tool or language, the providers and users seem to believe that Inspections do not add value or are less necessary

ConclusionBecause of these and other factors,shortcuts in Inspection process have beentaken without any proof that the change isan 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 thesoftware 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 with

inspection and testing, Winkler, D.; Riedl, B.; Biffl, S.,IEEE 2005

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

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