Introduction (Unit - 1] RM Testinc Ql) Define Testing? (or) How do you define Testing? Answer : Testinc Testing is the process of verifying whether application works as OF not. The quality and productivity that have to be achieved while te Per requirements 'Y of a software is measured by Testing. The factors sting are, > Correctness. > Reliability. > Usability. > — Maintainability, Once the source code has been generated Many errors as possible before deliver is to design a series of test cases th |, software must be tested to uncover as ty to the customer. The goal of software testing ‘at have a high likelihood of finding errors. Neep For Testinc There is a need that every software product have to be tested because, (2) The development process cannot prepare a error free Product. (2) Without testing, We cannot judge given product is error free or not. (3) Testing not only identifi ies defects but also quality of the product is measured which helps in deciding whet! her a product should be released or not. Testing techniques provide systematic guidance for designing tests that, (1) Exercise internal logic of software components, (2) Exercise the: jnput and output domains of the program to uncover errors in program function, behaviour and performance. Testinc as a Process imbedded in the softw Process. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanneriqrotwaton Tn 13 The testing Is again related to two pre (1) Verification (2) Validation, Requitene Analy Software Development Process Product Specification Testing Exampte oF TESTING Suppose if we consider the testing of a website or a web page. The few things that have to be tested are, (2) Links ‘.e., internal, external, mail and broken links have to be tested (2) In forms, the field validation, error message for wrong input, optional and mandatory fields have to be tested. (3) The database testing will be done on database integrity. (4) Testing on cookies should be done on the client side on the temprary Internet files. and many other cases to be tested. ‘As explained, testing would be done on all possible cases of a given product or any software application. [E23 purpose OF TESTING Q2) Explain the purpose of testing? [May - 11, Set - 3, Q3(b), M(6)] (or) To what extent can testing be used to validate that the program: is fit for its purpose? Discuss. [April - 11, Set - 1, 2, Q, 7(b), M(6)], [April - 11, Set = 3, Q6(b), M(6)] [April - 11, Set - 4, Q5(b), M(6)}, [April/May - 09, Set - 2, Q1(b), M(6)] [Aug./Sep. - 08, Set - 1, 2, 3, Q1(b), M(7)], [April/May - 08, Set - 2, 3, Q1(b), M(6)] SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanner athAnswer! Software testing Is nothing but a process of verifying and validating that the program plication or a software product which satisfies the business and technical or a software ap| jd be to get the s, The most general purpose of software testing woul requirement: it any errors. confidence that the software product would ,work correctly withou' The major objectives of testing can be explained under five factors. They are, (1) Verification + The process of verification Is done to check whether the software meets its specification or not. A specification is nothing but the description of function when an input is.given and output is expected to be measured. There ate two types of verifications. They are, () Static Verification. (i) Dynamic Verification. — ystém to discover its problems is static verification. The verification df static s g is performed by observing the pynamic Verification is the one where testin product behaviour. Levels of Verification : There are four levels of verification. They are, > Component Testing : The testing is conducted to verify the implementation of one or more software components. ; sting + Here the software and hardware elements are integrated > Integration Te: s been integrated. ted till the entire system ha tegrated entire system is verified to meet its requirements. and test > System Testing : The in! > Acceptance Testing : This testing is done to determine whether the user needs to accept the system or not. (2) Validation : The process of validation is done to check whether the software meets its business requirements or not. Validation-involves execu-tion of code whereas verification does not. It can catch errors which cannot be caught by verification. The disadvantage of validation is that the software works only for few particular cases. A finite number of test cases cannot validate that the software works for all situations. "5 r [SGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerJntreduction (Unit - 1] 15 e) 4 SOFTWARE TESGING METHODOLOGIES Defect Prevention : When a software is put to operation, the variation between the expected result and actual result is known as defect. As the defects increase the cost of-software develop-ment, it is better to find the defects as early as possible in the development cycle, So testing should be done at every stage in order to prevent the defects. Quality Improvement : One of the most important thing that has to be considered is Quality. Quality is defined as a factor which is used to determine whether a software meets all the requirements that are specified in the design phase. There are few differences between a Software product and manufactured product. -= | Process > Raw Material Finished Product [BEBE 4 Product or Process Problem _. - Software Definition -- Product [ERE Software Product or Software Process 5 the one which can be seen physically where as A manufactured product i: software product cannot be seen. Testing the quality of Software is very expensive becduse it Includes the cost of detecting and correcting the bugs,, cost of developing and executing test cases. The quality of software cannot be tested directly. It should be tested based on the testing related factors. JA. Mccall have developed few factors to test Quality. They are, > Product Operation. > Product Transition. > Product Revision. _ PROFESSIONAL PUBLICATIONS Scanned with CamScannerIntreduction (Unit = 1] All these factors in turn are considered concerned with other aspects like, Product Production deals with the quality factors such as, > Correctness, > Reliability. > Efficiency. Product transition deals with, > Portability > Interpretability. Product Revision deals with > Maintainability. > Testability. > Program mo: | (8) Reliability Estimation : It is a method used to estimate the functioning of a failure free software for a particular period of time in a specific environment. It is difficult to estimate software reliability by considering its related aspects. An estimation model is used for performing data analysis for estimating the present and future reliability. ication. Note : Software is developed by buman beings, and to err is buman, In standard commercial % errors are present, which are expensive. It is not possible to prevent these errors being entirely, but can be located early. The ultimate goal of software testing must be customers their satisfaction, which can be achieved by finding out the maximum number of bugs ing the software. TESGING METHODOLOGIES y PROFESSIONAL PUBLICATIONS Scanned with CamScannerintroduction [Unit - 1] 3) Differentiat, r ie Q3) iffe € the terms Verification and Validation? Answer : ean ifferences between Verification and Validation 5.No Verification Validation ay [it Ee eas Process of verifying docu- | It is a dynamic process of validating ments, design and code. /testing the actual product. 2)_| Itdoes not involve executing the code. | It involves executing the code. @) | It is human based checking of docu- | It is computer based execution of pro- ments/files. gram. (4) | Target is requirements specification, | Target is actual product a unit, a module, application architecture, high level and | aset of integrated modules, final product detailed design, database design. (5) | It uses methods like inspections, walk | It uses methods like black box, gray box, L throughs, Desk checking etc. white box testing ete. (6) | It generally, comes first done before | It generally follows verification. validation. (7) | Itanswers to question “Are we building | It answers to question “Are we building the product right?” the right product?” (6)_| Itcan catch errors that validation cannot | It can catch errors that verification cannot catch, catch, INFERENCE + Both of these are essential and complementary. Each provides its own sets of Error Filters, Each has its own way of finding out the errors in the software, Q4) Define testing and explain purpose of testing. 4 Answer : Testing ce Note: Refer Q.No. 1. Purpose of testing Note: Refer Q.No.2. [March - 06, Set - 4, Q1] [Nov. - 05, Set - 4, QI] SOFTWARE TESGING METHODOLOGIES CATIONS. PROFESSIONAL Scanned with CamScannerIntroduction [Unit - of a developed software, software testing will ensure Q5) Discuss how iapihay = 09, St = 8 1), (10 [April/May - 08, Set - 4, Q1(a), M(10} Answer [Note : Refer Q.No. 2, Topic : Verification and Validation jote : Refe [EME Productivity and Quality in Software Explain Productivity and Quality in Software? Q6) Answer: production of a product, there are several phases startin: vm feauremen isis to the phase of final testing before the delivery of product. In al Ali a product is subjected to the quality control and testing. If any defects are ny stage, that component will be sent back for correction. 9 from requirement Measure for Productivity ¢ Productivity is measured by the sum of the costs of resources, rework and failed components and cost of quality assurance and testing Productivity = Cost (resources + rework + failed components + quality assurance ( + testing) There is 4 trade-off between quality assurance costs.and manufacturing costs. If effort spent in quality assurance is not sufficient, the reject rate will be high and the next cost will also increase. If inspection is so good, the reject rate will decrease but ction cost will dominate, and again net cost will suffer. The manufacturing process 5 attempt to establish a level of testing and quality assurance that minimizes cost for a given quality objective. The costs of testing and quality assurance for manufactured items can be as low as 2% in consumer products or as high as 80% in Products such as space ships, nuclear reactors and aircrafts etc. nsp The relation between productivity and quality for software is different from that for manufactured goods. Software maintenance is different from hardware maintenance. Software costs are dominated by development. The manufacturing cost of software is Not important. The cost of bugs is a part of software cost that includes the cost of detecting bugs, the cost of correcting bugs, the cost of designing tests that discover them and the cost of running those tests. The main difference between productivity of widget and whereas for software, quality and Productivity are almost not distinguishable. ease reeemebaseeeeette Anemia SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanner—aadedion (Unit =] aa 19 gromples i The tele communication ope 1) operating companies such as Bell Sout! ecific & the other hand have seianieaied tended to be quite sophisticated with productivity measurements and were early adopters of function points, perhaps b: thousands of software staff members, productivity is a pre ause, with ssing cor Some years ago, energy and oil production companies, also in the wake of reduced earnings, started to move quickly into the domain of productivity measurement. Even now profits at record levels, the oil industry still measures the quality and user satisfaction as well. Companies such as Exxon and Amoco were early students of software productivity measurement and they have been moving into quality and user satisfaction as well. fa Goals of Testing Q7) Explain two goals of testing? [May - 11, Set - 4, Q3(a), M(4)] ‘Answer: The two main goals of testing are, (1) Bug Prevention. (2) Bug Detection/Bug Discovery. (1) Bug Prevention : Bug prevention is considered as testing’s first “goal. If 2 bug is present in the software, it is needed to be detected and corrected. If such a bug is prevented, there is no need to correct it or detect it and the cost of testing will be decreased. Hence we say Bug Preventicn is better than Bug Detection and Bug Correction. When a particular bug is prevented, there is no need to perform testing again to confirm the accuracy of the program. To achieve this goal, testing should be performed at every stage of software development so that all the bugs could be discovered and prevented during the design phase itself. For that the test should be designed properly so that before coding phase, bugs can be prevented. So “Designing Tests” is considered as the Best Bug Preventer. Example : Suppose you are writing a calculator class that performs simple operations on pair of integers. Before you even write the class, take a moment to write a few tests for it as shown below. By writing tests early, you start thinking about which cases might cause problems. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanneroO Introduction (Unit - umport junit.tramework. Te Calculator Test extends TestC: public { public void testAddition( } { Calculator calc = new calculator( ); U34=7 int expected = 7; int actual = calc.add (3, 4); assert Equals (‘adding 3 & 4,” expected, actual); } Public void test Divisior( ) ' n Calculator calc = new Calculator( ); 11 Divide by zero shouldn't work try { : cale.divide(2, 0); fail ("Should have thrown an exception!*); } catch(Arithmetic Exception e) if } } } (2) Bug Detection : How much ever we try, the first goal cannot be achieved ideally because “to err is human’. If we fail to achieve the first goal, atleast the second goal shouldebe achieved mandatorily i.e., Bug discovery Just knowing that the program is incorrect is not enough because it cannot identify the bug. Each bug can be found by performing individual tests on each and évery module. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerjreduction [Unit =) VT Bal Phases in a Tester’s Mental Life 8) Hxplain different phases of Test 8 Mental Life? (May - 11, Sot - 2, O5(c), MIB), INov. - 10, Set - 2, Q4(¢), MA(2)] (Nov/Dec. - 09, Set - 4, @6(c), M(2)] (or) What are the phases in a Tester’s Attitudinal progression? [Dec. - 11, Set - 1, Q2(a), MA(10)] [Dec. - 11, Set - 2, Q8(a), M(10)] [Dec. - 11, Set - 3, Q5(a), M(10)} [Dec. - 11, Set - 4, Q1(a), M(10)] (or) What are the phases in a tester’s mental life? [Feb. - 07, Set - 3, Q1(a), M(10)] Answer + A tester can have five phases of thinking. They are, Phase 0 Phase 1 Tester pases in sster’s Mental Life (1) Phase 0 Thinking-Testing Testing = Debugging : In this phase of thinking, testing ne debugging are considered to be same. Infact Testing supports Debugging In the, initial stages of testing, this phase 0 thinking was the criteria for software development. —_—_——- = ‘AL PUBLICATIONS SOFTWARE TESGING METHODOLOGIES PROFESSION. Scanned with CamScannerapplied to an area from which the following resources his type of thinking can Pe determined. The resourc es include, can be Low cost software: Lone programmers. Small projects: Throwaway software ¢ the only criteria for development but now a days, In the initial days, this wa @ barrier for good testing and qual lity software. rks : The main aim of this phase is to show that testing and debugging this phase considers n of software many number of tests it is considered as thi Phase 1 Thinking-The Software Wo! Ke Phase 0, (@) to check the executior the software works. Unli are different. In this phase, are performed. failed software but to prove ove that one test fails in case of any number of tests are not sufficient. It’s enough to pr this thinking is kind that software is executing, ‘As software is tested, errors are also detected. Therefore, of reasoning to determine the working of a program without testing It. Phase 2 Thinking-The Program Doesn't Work : The aim of the Phase2 thinking is to show that the program or software does not work. The goal of phase 1 is difficult 6) to achieve but the goal of this phase of thinking can be achieved just by proving any one of the test cases as incorrect. Bugs can be detected by testers, progra-mmers and. designers in this phase. The process in this phase can be like. Tester will Detect a Bug Programmer Verifies it and] Corrects it Rwy Flowchart to Show the Process of Phase 2 Thinking The disadvantage i 9¢ in phase 2 thinking is that it is a never ending process. PROFESSIONAL PUBLICATIONS \FIWARE TESGING METHODOLOGIES Scanned with CamScannerphase 3 Thinking-Test for Reducing the Risk : The aim of this phase is to reduce the risk! them. “ that can be predicted, In this phase the tester will detect the bugs and eliminate just by testing, the quality of product will not change but the risks can be reduced which in turn increases the performance. nking-State of Mind : This is similar to that of phase 3 but-here, the aim ks with minimum testing effort. This could be possible if and only uld (o) Phase 47 js to reduce the tis! iif the tester has knowledge of all the conditions under which the software sho be tested. [Ma Principles of Test Case De: vs of Test Case Design? Explain a9) What are the principl [Nov. - 06, Set - 2, QI, M(16)], [Now. - 06, Set - 3, Q1, M(16)] [Nov. - 05, Set - 1, QI] Answer t principles. Test case design involves three Important principles. They are as follows, Every test is fragmented (broken-down) ation of the Available Tests : ge. These test modules that are easy to understand and mana nd even aggressive to detect bugs before the sy: he test case is an important factor for succes: 5 a well-defined scope that is different from that ermines what the test cases should actually lo (1) Effective Fragment into individual test modules are complete ai designed. Designing of t automation. Each module ha: other modules. This scope det stem is fully s in test of the ok a like. Each of the fragmented test module 1e for each Test Module is testing (2) Accurate Testing Techniqu' he scope of a test module determines variou is called as ‘mini project’. TI techniques that are used to dev that are used to build the test ca: Decisions need to be made regardin evaluating the test cases. For example, to test the estimation of insurance premiu elop an individual test module. The testing strategies decision tables etc. ses are boundary analysis, g and g who should be involved in creatin consider a test module whose object ent to ive is m, It requires ‘actuarizI’ departm get involved in performing the test. . PROFESSIONAL PUBLICATIONS SOFTWARE TESGING METHODOLOGIES Scanned with CamScanner= | Via Introd (nit ©) Specttying Correct Leval of Detalls for the Test 1 Accord: 1) *his principle, @ correct level” of abstraction should be determined. The hight ot K tails that are cequireg for developing test cases should be specified and all the lovs-tevel im 7 details should be hidden . The low-level details are static and doesn’t Undergo any sort of « Beeemeeeg oraaasec ogee) changes: The low-level deteligfate stares Feusable automation routine or procedure that is common to sil t Because of this abstraction, test is more concise and understandable. Example : In an employee database, tests are performed using high like “check emp-status” and “check emp-salary”, but while testing a lov | dialog routine, an action called “click” is used to determine whether an OK button is cle or not on the appeared dialog box. [E2G Testing isn’t Everything Q10) What are the methods which prevent bugs, other than testing? [May - 11, Set - 4, @3(b), may] (or) Why the testing isn’t everything? IFeb. - 07, Set - 3, Q1(b), M(6)] Answer : * The most effective method for detecting the rrors is Testing. Apart from testing, there are other methods which can detect errors. The process of testing alone cannot make the software error free. Some other methods should be followed consequently to reduce the errors. That is the reason we say, “Testing is not Everything” . The other methods include, (1) Walkthroughs, Inspections. (2) Program Design method. (3) Syntax checking method. (4) Languages. (5) Design methodologies and Development Environment. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL. PUBLICATIONS Scanned with CamScannerjavadvation (Unit - 1) toh Efficiency Decreases SY WRRED Efficiency orderof omer Methods of Testing ~t1) Walkthroughs, inspections : Some of the other methods to detect errors include, (i) Walkthroughs. (ii)_ Inspections, (ili) Reviews, All these methods can detect only some errors and not all. This is the major \ drawback of these methods. () Walkthrough : Walkthroughs are similar to peer review processes that involve the author of the program, the tester, a secretary and a moderator. The Participants of a walkthrough create a small number of manual tracing test cases by simulating a computer. Its objective is to question the logic and basic assumptions behind the source code. Walkthrough is an informal review in which the work product's author.describes it to some colleagues and solicits comments. Checkpoints Objectives 1) The Entire Software Product has Been Examined, 2) Recommendations and Required Actions have Been Recorded. Software Product 3) The Walk Through Output has Been Completed. zacomz4xr>s Standards and Procedures Fi EY Walkthrough Process SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanneree ee Sener tee ae Introduction (Unit -j) Software inspection is one of the most important manual techniques am without running and comparing code or design inspection rules. A software inspection and correct defects ip (i) Inspection ¢ which allow testing the progr of work product to set of pre-established is a expert group review process that is used to detect a software work product. Acceptance Criteria/Checklist 1 " Prodict to be Inspected | 3). Noor ttinor Rework P LJ 2). Rework Verification E Inspection Procedure c | 3) Re inspection T ‘Anomalies or 1sves 1 ° ] N Product to be Inspected BEEBE) spection Process (iii) Review : Formal reviews are conducted at the end of each phase of software development life cycle. They may also be conducted when a serious problem or concern arises. Two types of formal reviews are available management reviews and technical reviews. (2). Program Design Method : The design model of a program determines whether the quality of the program is good or not. An improper design model degrades the quality of the software program. The design objectives such as openness, clarity, testability are chosen in order to prevent bugs. Syntax Checking Method : During the analysis of source code, the syntax errors are 3) checked by the compilers. The static analysis methods such as strong typing and type checking are considered. These two methods detect all the errors in the program and correct them. Static analysis is a part of research and development to find errors in data-flow anomaly detection process. (4) Use of Languages : The languages that are used in the programs results in preventing some errors. A new type of error is detected in a new programming language b/ the programmer, which makes the rate of bugs independent of the language bein? used. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerjnrodvetion (0 Software Development Mothods s PMent Method of A software developme oe process, Which uses various Pepedy eed eae : Methods for developing a software. For example, 4 of information method a, cMatatton control method and automatic distribution ive used to develop a software, These methods detect and remove most of the errors in the s changes that take place ‘oftware and the programmer is unaware of the after removing those errors, fea Pesticide Paradox and the Complexity Barrier QI1) Define Pesticide Paradox and Complexity Barrier? (Nov./Dec, - 09, Set - 4, Q6(b), M(6)}, [Nov. - 10, Set - 2, @4(b), (61) [May -.11, Set - 2, Q5(b), M(6)] (or) What is pesticide paradox and explain complexity barrier? [April/May - 09, Set - 4, Q1(b), M(8)] Answer: Pesticide Paradox : P <+ “Every method used to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual”. This paradox states that running the same tests over and over again could not show any new defects because all defects found using the initial test cases could eventually be fixed. However there are other reasons for the diminishing returns as well. One explanation is, except for the simplest of software applications it is simply not possible to identify and test every possible scenario, so running the same tests repeatedly could result in a large overlap of previously identified scenarios. Another reason is that a software program’s functionality may change over time, which again could"invalidate previously executed text cases. To avoid the pesticide paradox and other causes of diminishing returns, all tests should be regularly reviewed to ensure that all expected areas of functionality are covered. This could involve adding new scenarios as well as discontinuing ones that are no longer valid. Additionally, new tests can be written to exercise the code in new.or different ways to highlight potential defects. Complexity Barrier : “Software complexity grows to the limits of our ability to manage that complexity”. This statement means that the complexity of the software grows to the limits till @ human have the ability to manage it. There are no limits for the Software Complexity. SOFTWARE TESGING METHODOLOGIES Scanned with CamScanner PROFESSIONAL PUBLICATIONSWvetion (Un ae H The success of any software is dependant on many factors, As the complexity gf the software tne the process of testing would become difficult, In the present wort, the complexity te being Increased day by day and understanding the product and Complexity has become more difficult for the tester Necause of many such reasons, the effective testing Is bound to have complexity barrier The challenges that are faced by the effective testing in present days because of compleity. bi (1) Getting people with right skills and developing an overall understanding of the sortware (2) Establishing the test scope Q12) Why is it impossible for a tester to find all the bugs in a system? Why might it not be nece: ry for a program to be completely free of defects before it is delivered to its customer: [April - 11, Set - 1, Q7(a), M(10)], [April - 09, Set - 2, Q1(a), M(10)} [Aug./Sep. - 09, Set - 1, 2, 3, Q1(a) M(10)] [April/May - 08, Set - 2, 3, Q1(a) M(10)) . (or) Why complete testing is impossible. [May - 11, Set - 4, @3(c), 1(4)] Auswer + It is impossible for a tester to find all the bugs in a software or system. Though many number of testing methods are used, it can't be guaranteed that the software is free form bugs. “Testing can only.show the presence of bugs but not their absence”. So, how much ever we test our program using all our skill and intuition, we can neve be sure of eradicating all the errors. Complete Testing is impossible for several reasons, (1) All the inputs to be program cannot be tested. (2) All the combinations of inputs to the program cannot be tested. (3) All the programs paths through the program cannot be tested. (4) Failures caused by user interface design errors cannot be tested. (5) Incomplete Requirement analysis cannot be tested. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATION Scanned with CamScanner_ qorodeation (Uni = TT ts Cannot be Test inp e Tested : It is impos a st all the possible inputs al Ja given program. All the ble for anyone to t . © inputs of many types cannot b a valid inputs, be tested such as, (2) Invalid inputs. 3) Edited inputs. (4) Input timing variations. il Input Combinations Cannot be Tested : nput variables. fested : It is impossible to test all the combinations of ample : If there is a ea 100 and ee to add two numbers. The first number should be between 1 number should be between 1 and 25. So the total number of possible inputs could be 100 x 25 = 2500, h ‘ If there are n such variables. It would be impossible to test such a huge number. All the ret cone be tested + If there are some 100 trillion paths through the program to test and if the time is one test per second, it would take more than 3,00,000 years to run all these tests. So it is highly impossible to test all these paths. Even before the delivery of the product, we cant-guarantee a defect free product but it is seen that the product maintains its minimum specifications. These are few reasons why complete testing is not possible. [3B DICHOTOMIES [Ei Testing Versus. Debugging Q13) Compare and Contrast testing versus (or) Debugging. [May -11, Set - 3, Q3(a), M(10)} Differentiate between testing and debugging. [March - 06, Set - 2, @1(b)] (or) Distinguish between testing and debugging. [April/May - 12, Set - 1, Q7(b), M(6)} [April/May - 12, Set - 2, Q2(b), M(6)], [April/May - 12, Set - 3, Q3(b), M(6)] [April/May - 12, Set - 4, Q6(b), #(6)) PROFESSIONAL PUBLICATIONS SOFTWARE TESGING METHODOLOGIES Scanned with CamScannerIntroduction (Unit - 1] Answ ‘| s.No. Testing Debugging 2) | Testing is the process of executing sott- | Debugging refers to undertaking, meas- vawe with the intent of detecting the | ures t0 make programs free bugs. presence of faults. L (2) | Error Detection is the goal of testing. Error detection and error correction are the goals of debugging. 3) | Testing always starts with known condi- | Debugging starts from unknown condi- tions. tions. The outputis unpredictable, (4) | The outputis predictable Itis necessary to have planned, designed | It is not necessery to have these con- 6) and scheduled constraints straints. (6) | Testing is the process which demon- Debugging is the process of reducing the strates errors. errors. @) | Testing proves the programmer's failure. Debugging is programmer's indication. The objectives of debugging are intuitive leaps, conjectures, experimentation and freedom. ; (8) | The objectives of testing are predictable, dull constrained, rigid and in human. Debugging should have design knowl- (9) | Testing can be done without design kno- : edge wledge! Debugging should be performed only by (10) | Testing can be performed by an outsider. : the insider. (11) | Test Design and execution are auto- | Debugging can’t be automated, mated, NFERENCE : Testing and debugging both are necessary for a software product. Testing can be utomated where automation of debugging process produces united results. PROFESSIONAL PUBLICATIONS DFTWARE TESGING METHODOLOGIES Scanned with CamScanner=. C—O Cis : at ea Function Versus Structure Testing esting Qld) Differentiate functional vers Structural Testing? [ec. 11, S01 + Set = 1, Q2(b), M(6)], [Dec. - 11, Set = 2, @8(b), (6) [Dec. - 11, Set - 3, Q5(b), M(6)}, [Dec. = 11, Set - 4, 1b), MUI] (or) Explain the difference between functional testing and Structural Testing? [une - 10, Set - 4, @3(a), M(@)] (or) Give dif i ifferences between functional testing and structural testing. o INov. - 06, Set - 4, Q1(a), M(4)], [Nov. - 05, Set - 3, Q1(a)] % a (or) Vio Differentiate between function and structure. [March - 06, Set - 1, Q1(b)] Answer A EEG Fnctional Vs Structural s Structural Testing Functional Testing In functional testing tests are designed from functional point of view. (a) | In structural testing, tests are designed from structural point of view. It is also known as black box or closed. 2) | Itis also known as white box, glass box, box or opaque.box testing. open box or clear box testing. This testing does not require any kniowledge of internal structure of the software, @) | Structural testing looks at the implemen tation details such as programming style, control method, source code, database design and coding details. Infinite time is taken by test cases and (4)_| Finite time is taken by the test cases but it all bugs are detected. cannot detectall bugs SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerThere is dependency between a tester and programmer for test process: Tests are performed either from pro gner's perspective pammer’s or de Inputs are represented by fined paths in software, certain prede Itis less effective than functional testing, Various methods that perform structu testing are, (i) Statement T (ii) Decisis n Testing. i) Condition Testing. Fests ane pertormed by the tester ana Programmer individually and they, independent sare done only from user perspec tiv Inpu sented by some periph eral simulated systems, Functional tes uctural t ing, is more effective than ting, Various methods that perform fune tional testing are, (i) Expected Input (ii) Boundary Values (ii) Megal Values. Unnecessary code which removes bugs i eliminated. i‘ and incon: ations. It reveals proble encies in functional spec INFERENCE : In practise, testers often initiate the testing process with functional testing and then move on to structural testing to cover those parts of the source code that have not yet been covered. (ESE The Designer Versus Tester Q15) Explain the dichotomy Designer Versus Tester? Answer : FEES Designer Vs Tester S.No. Designer Tester (1) | Designer is based on the structural specification of the system. Tester is based on the functional specifica- tion of the system. (2) | Designer depends on implementation details. Tester does not require any details of im- plementation. @) | Designer can design an efficient soft. ware when he have the knowledge of implementation. As there are no details of implementation, the software developed is inefficient. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerjreduction = _ 1.23 | Designing and executing teams ere ANY tests is job o software designs job of Iso responsible for designing and — ng, the 5) | Probability of fautt doo @) | Prob ae ult design increase | Propapi eine aa | Probability of climinating, unnecessary knowledge of design. tests increased with the inerease in knowledge of test design. (©) | Tests executed by designer ar to structural specification, Wages | Tests executed by tester ie free from bias Suse of | and therefore it is not possible to terminate he| the Po There is a need to b ‘lance strengibs of designer and tester. By having a collaborative which the tests must withstand drawback of structural testing, INFERENCE : approach and by building st app , - ig strengths of designer on efficiency because of this knowledge on structural 5 an properties, and strengibs of tester that comes from coverage and focus on functionalities, we arrive at testing, approach that balances knowledge by overcoming biases of designer avid tester. Q16) Differentiate Modularity and Efficiency? Answer : Modularity Vs Efficiency : A module can be defined as a distinct, small component that has a well defined purpose. While constructing the system, it could be ‘easy to understand if each component used in the system is small. 2 As it is known that every component interact with other components by means of interface. If the system is made, up of many smaller components, it could be affected with interface bugs. Then its efficiency could fall down. These bugs in the system are reduced by considering larger components but large components have internal logic which is difficult to understand. The process of testing will be done in the form of modular components. The smaller test cases are easy to execute and re execute. Each test case in the process is designed to reduce the burden to designing, debugging and execution of the test. InFERENce : Every software component is designed to minimize the complexity by keeping in view the size of the component and its boundaries so that it can balance their internal difficulties against interface difficulties. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanner__ 1.24 [ERED small Versus Large Differentiate small versus large? ai7) Answer: S.No. Small Large Te program which contain large number pro The programs which contain only few lines of code are known as small pro- grams of lines of code are known as Ia grams, They contain only few components ‘They contain large number of componen ts No technique is required to test small programs. Different types of techniques are used to test large programs. @ These are more efficient. These are less efficient. ifferent 6) These programs can be written by a single programmer. Large programmers are written by d programmers. programs, Comparing Small and Large pro- grams, small programs are of high quality. Comparing Small and Large Large programs are low quality. ” Small programs undergoes different Large programs have data dictionary to store the data and then they perform unit phases like designing, coding, testing, debugging etc. : testing, oo ae revention and bug discovery. Inrerence : Thus, in large systems, testing shall include‘bug pt {E@Gi Builder Versus Buyer Q18) Explain the dichotomy Builder Versus Buyer? Answer : Builder Vs Buyer : Most of the software in the present day is built and used by the same better testing. organization. Its objective is to provide improved software quality, enhanced security, It is not needed to purchase a software from a vendor. It can be developed with in an organization itself. iOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScannerGoaion [nit = jaro vee software development class and functional class must sig anor in the same organization. For this reason, it is better t ae soreemert a each * It is 1 to separate builder and buyer if the builder and buyer are not separated, there will be few problems auch as “19 accountability” ew problems such as "No cycle like programmer’ there are Many persons in the software development lif fers that can be merged to perform various test o} tions: and test ys) Te fe softwa’ builder is a person who is responsible for developing and designing th ig) The buyer Is 2 person who pays for the software for gaining profits. fg). The wser is @ person who is the final recipient of the system. {a The tester is @ person who fs responsible for any kind of builder's 105s. (5) The operator is person who takes into account the builder's mistakes, th criticisms, the tester’s faults and the buyer’s obscure de user's ions while developing 2ny software application. Builder and Buyer should be isolated. INFERENCE = Q19) List out various dichotomies and explain. Answer + The various dichotomies. are, [Feb. - 07, Set - 1, Q1 MI16] (1) Testing Versus Debugging Note : Refer Q.No. 13. ral Testing 2) Functional Versus Struct Note : Refer Q.No. 14. (3) Designer Versus Tester Note : Refer Q.No.15. (4) Modularity Versus Efficiency Note : Refer Q.No. 16. (5) Small Versus Large —— Note : Refer Q.No.17. (6) Builder Versus Buyer a Note : Refer Q.No. 18. hee PROFESSIONAL PUBLICATIONS SOFTWARE TESGING METHODOLOGIES Scanned with CamScanner+136 _ = . ttre OR TEST! ~ 4 MODEL F (a Project - fitions to be considered in the real world projec! an) nw conditions ’ Ez Q20) Mention few con om oe anything from subroutines to systems which on ennai ert product toes produced @ perfect unde f testing can be ents. For any Syste’ The process ©! is necessary ts of millions of statem mentation real world model, ther ng and characteristics to consis janning and imple! , fe are few conditio ication. The specifications So to consider 2 t the timely responses to ed. Some of them are, thing to be considered is the output of the app! duct is nt bul be follow’ (1) The first ae or requirements of the pro ot that import the user requests is main goal. ld only be upto 20 or 30 programmers. If it is too big, The programming staff sho it would be hard to manage. e more than 24 mont (2) hs from start of the project till e followed by cut over period of Any project should not tak: QB) y the customer. The acceptance will be acceptance Db} 6 months. This should be the schedule of a ideal project. The requirement specification should be good. aintained (4) (5) The personnel or staff consists of many kinds and their ratio should be m: correctly. Half of staff - already programmers. 1/3rd - Junior programmers: (6) The standards of the programming and test exists and they should be followed (7) In any kind of systems, the source code one third - new code. one third - extracted from previous one third - from other languages. Tf all the ab i ove mentioned are followed correctly, a system will be running perfect! y IFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATION Scanned with CamScannerinte poms Model Project for Testing Process go") Explain the overview of a project with an exainple? answer considering the example model project for testing, the process of testing can Pe” spaerstood completely. World Model World Environment! Model ERY Model of Testing overview of Model’: The Fig. 1.10 is the model for process of testing. The process in the above model started with a program embedded in a environment such as @ computer, an operating system etc. ‘And we know, it is common to make errors. To discuss clearly, our médel can be divided into three parts, (1) Model of environment. 2) Model of Program. (3) Model of Bugs. Environment : The environment for any model or any program could be the hardware and software that are required to make the program run and execute. Example : The environment for online systems may be communication lines, operators etc. SOFTWARE TESGING METHODOLOGIES PROFESSIONAL PUBLICATIONS Scanned with CamScanner