IJREAT International Journal of Research in Engineering & Advanced Technology, Volume 2, Issue 3, June-July, 2014 ISSN: 2320 – 8791 (Impact Factor: 1.479) www.ijreat.org www.ijreat.org Published by: PIONEER RESEARCH & DEVELOPMENT GROUP (www.prdg.org) 1 Rakhee Kundu 1 , Umesh Kulkarni 2 1 Computer Engineering, ARMIET, Affiliated to Mumbai University, India 2 Computer Engineering, VIT, Affiliated to Mumbai University, India ABSTRACT : Although software inspection has led to improvements in software quality, many software systems continue to be deployed with unacceptable numbers of errors, even when software inspection is part of the development process. The difficulty of manually verifying that the software under inspection conforms to the rules is partly to blame. We describe the design and development of a tool designed to help alleviate this problem. The tool provides mechanisms for inspection of software by exposing the results of sophisticated whole-program static analysis to the inspector. The tool computes many static-semantic representations of the program, forward and backward slicing and dependence factors. Whole- program pointer analysis is used to make sure that the representation is precise with respect to aliases induced by pointer usage. Views on the dependency and related representations are supported. Queries on the dependence graph allow an inspector to answer detailed questions about the semantics of the program. Facilities for openness and extensibility permit the tool to be integrated with many software- development processes. The main challenge of the approach is to provide facilities to navigate and manage the enormous complexity of the dependence graph. Which will test the correctness of the program by identifying some of the rules .Whether particular variable in the program is working or malfunctioning, Checking the malfunctioning by the dependency factors by using backward and forward slicing. This will identify the checkpoints and not to identify the errors and which area a particular checkpoint is getting effected will be reflected. Keywords – Abstract Syntax Tree, Program Dependence Graph (PDG), Predecessor, Slicing, Successor. 1. Introduction 1.1 Why use testing? "Testing can consume over 50 percent of software development costs (note that testing costs should not include debugging and rework costs). In one particular case, NASA's Apollo program, 80 percent of the total software development effort was incurred by testing."Some projects can t afford any failures at all during operation like the Apollo project. It can also be that the customers accept some faults that are fixed later under maintenance because the product will be cheaper. So the time spent during testing much depends on what reliability level that are asked for. One advantage with testing can be that it is closer to the way the end- user will use the system. They will fell that the product has a higher quality because the defects is outside the normal execution. The program will become more reliable by finding the most common failures. Inspection will more look for correctness there a more common executed fault and a more rarely fault is equally easy to find. I have found in the project that I have been involved in that the test phase often has less priority than other phases. If the project is getting late is it likely that the time for testing will be cut down. This can especially be a problem if the test phase is located at the end of the project and not during the entire project. Inspection can be effective when same method can be used on a lot of different documents and testing is effective when it comes to rerunning the same test. A good tool for automated testing can take some time to develop but can be executed many times. This can save a lot of time because many systems today are released over and over again. One problem with automated tools is that we need to write additional code and we will not know if the defect is in the systems code or in the test code. There exist areas where testing is