Dr. S.S.Riaz Ahamed / Internatinal Journal of Engineering Science and Technology Vol.1(3), 2009, 119-128 STUDYING THE FEASIBILITY AND IMPORTANCE OF SOFTWARE TESTING: AN ANALYSIS Dr.S.S.Riaz Ahamed Principal, Sathak Institute of Technology, Ramanathapuram,India. Email:[email protected], [email protected] ABSTRACT Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. Software testing is the process of testing the functionality and correctness of software by running it. Software testing is usually performed for one of two reasons: defect detection, and reliability estimation. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws, not their absence (unless the testing is exhaustive). The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. The key to software testing is trying to find the modes of failure - something that requires exhaustively testing the code on all possible inputs. Software Testing, depending on the testing method employed, can be implemented at any time in the development process. Keywords: verification and validation (V & V) 1 INTRODUCTION Testing is a set of activities that could be planned ahead and conducted systematically. The main objective of testing is to find an error by executing a program. The objective of testing is to check whether the designed software meets the customer specification. The Testing should fulfill the following criteria: ¾ Test should begin at the module level and work “outward” toward the integration of the entire computer based system. ¾ Test should be appropriate and different for different points in time. ¾ An independent test group should exist and should conduct testing for different software development projects. ¾ Though testing and debugging are different activities, debugging must be accommodated in any testing activity. ¾ A methodology for software testing must accommodate low-level tests that are necessary to verify that a small source code segment has been correctly implemented as well as high-level tests that validate major system functions against customer requirements. It should indeed provide guidance for the practitioner and a set of milestones for the manger. 2 TEST PLAN For performing any activity, planning is done and similarly testing commences with a test plan. A test plan is a general document for the entire project that defines the scope, approach to be taken, and the schedule of testing as well as identifies the test items for the entire testing process and the personnel responsible for the different activities of testing. The inputs for the test plan are viz, project plan, requirements documents and system design document. An ideal test plan should contain the following: ¾ Test unit specification ¾ Features to be tested ¾ Approach to testing ¾ Test deliverables ¾ Schedule ¾ Personnel allocation Testability Software testability is the process of testing how adequately a particular set of tests will cover the product. This enables the individuals charged with testing to design effective test cases more easily. As per the definition of ISSN: 0975-5462 119 Dr. S.S.Riaz Ahamed / Journal of Engineering Science and Technology Vol.1(3), 2009, 119-128 James Bach, Software testability is simply how a computer program can be tested. It is clear that testing is not small process and it is profoundly difficult, it pays to know what can be done to streamline it. The attributes of good test are ¾ It should have a high probability of finding an error: The tester must understand the software and attempt to develop a mental picture of the failure possibilities. ¾ It is not redundant: Since the testing time and resources are limited, there is no point of conducting the test of same procedure as like the other. Every test should have different purpose. ¾ It should be best of breed. ¾ It should be neither simple nor complex. Although it is sometimes possible to combine a series of tests into one test case, the possible side effects associated with this approach may mask errors. 3 DEVELOPMENT TESTING Development testing includes verification and validation (V & V). Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities that ensure that the software has been built is traceable to customer requirements. Verification: “Are we building the product right”? Validation: “Are we building the right product”? Some of the activities of verification and validation are part of the software quality assurance that include formal technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, document review, database review, algorithm analysis, development testing, qualification testing, and installation testing. Tom Gilb suggests that the following issues must be answered if testing strategy is to be implemented: 1. Specify product requirement in quantifiable manner long before testing commences. Although the overriding objective of testing is to find errors, a good testing strategy also assesses other quality characteristics such as portability, maintainability, and usability. These must be specified in a way that is measurable so that testing results are unambiguous. 2. State testing objectives explicitly. The specific objectives of testing should be stated in measurable terms. For example, test effectiveness, test coverage, meantime to failure, the cost to find and fix defects, remaining defect density or frequency of occurrence, and test work hours per regression test should all be stated within the test plan. 3. Understand the users of the software and develop a profile for each user category. The description of the interaction scenario for each class of user can reduce overall testing effort by focusing testing on actual use of the product. 4. Develop a testing plan that emphasizes “rapid cycle testing”: Tom Gilb recommends that a software engineering team “learn to test in rapid cycles (2% of project effort) of customer-useful, at least field ‘trialable’, increments of functionality and/or quality improvement.” The feedback generated from these rapid cycle tests can be u sed to control quality levels and the corresponding test strategies. 5. Build “robust” software that is designed to test itself. Software should be designed in a manner that uses antibugging techniques. That is, software should be capable of diagnosing certain classes of errors. In addition, the design should accommodate automated testing and regression testing. 6. Use effective formal control reviews as a filter prior to testing. Formal technical reviews can uncover inconsistencies, omissions, and outright errors in the testing approach. This saves time and also improves product quality. 7. Develop a continuous improvement approach for testing process. The test strategy should be measured. The metrics collected during testing should be used as part of a statistical process control approach for software testing. 4 GENERAL TESTING METHODS Software bugs are a fact of life. No matter how hard we try, the reality is that even the best programmers can't write error-free code all the time. On average, even well-written programs have one to three bugs for every 100 statements. It is estimated that testing to find those bugs consumes half the labor involved in producing a working program. Statistics like these explain why so much attention is focused on making testing more effective. Traditionally, there are two main approaches to testing software: black-box (or functional) testing and white-box (or structural) testing. Black-box and white-box testing should be performed together for every application so that the software will live up to users' expectations on every level. ISSN: 0975-5462 120 Dr. S.S.Riaz Ahamed / Internatinal Journal of Engineering Science and Technology Vol.1(3), 2009, 119-128 White-Box testing White-box testing strategies include designing tests such that every line of source code is executed at least once, or requiring every function to be individually tested. Very few white-box tests can be done without modifying the program, changing values to force different execution paths, or to generate a full range of inputs to test a particular function. Traditionally, this modification has been done using interactive debuggers, or by actually changing the source code. While this may be adequate for small programs, it does not scale well to larger applications. Traditional debuggers greatly affect the timing, sometimes enough so that a large application will not run without major modifications. Changing the source code is also unwieldy on a large program that runs in a test bed environment. The intention in white box testing is to ensure that all possible feasible flow of control paths through a subprogram are traversed whilst the software is under test. This is not the same as saying that all statements in the subprogram will be executed as it is possible for all statements to be executed but for not all of the possible paths to be traversed. However, the converse is true; if all possible paths through a subprogram are traversed then all statements in the subprogram will necessarily be executed. White-box testing requires visibility into the executable to determine what to test. It also requires a method to determine the outcome of the test. The ability to output values from within the application in the most noninvasive manner possible is a necessary capability in any white-box testing tool. White-box testing is quickly gaining acceptance as a method of testing code. One way to examine the merits of white-box testing is to look at it in terms of its more commonly practiced counterpart: black-box testing. White-box testing is a method of verifying that code has been constructed properly and has no hidden weaknesses. The goal of white-box testing is to execute every branch of code under different input conditions to make sure the code does not exhibit abnormal behavior.