LATEST: (2021 EDITION: | SPECTRUM | ALL-IN-ONE | Sewes SOFTWARE TESTING METHODOLOGIES B.Tech. CSE & IT, Ill-Il (R18) JNTU-HYD (Professional Elective-IIl) Including May-19(R15) | Dec.-18(R15) | April-18(R15) | May-17(R13) | May-16(R13) Exams’ QPs with Solutions. Pines DaasCro Ces SIA GROUP iran intel SOFTWARE TESTING METHODOLOGIES (Common to CSE and IT) B.Tech. Il-Year II-Sem (Professional Elective) ( JNTU-Hyderabad ) “CONTENTS. Introduction to the Subject Syllabus as per R18 Curriculum La. La M4 + M19 List of Important Definitions MID - I & II (Objective Type & Essay Questions with Key) University Exams Question Papers with Solutions (Latest to Previous) QP. ‘Model Question Papers with Solutions (As per the New External Exam Pattern) MP.1 UNIT-WISE SHORT & ESSAY QUESTIONS WITH SOLUTIONS Unit No. “Unit Name Question Nos. Page Nos. Topic Name - f INTRODUCTION, FLOW GRAPHS AND PATH — Qt - aez_1.1- 1.38 TESTING _ et Part-A Jawaharlal Nehru Technological University Hyderabad RI 5 B.Tech II! Year Il Semester Examinations, May - 2019 Emm 1 SOFTWARE TESTING METHODOLOGIES {Common to CSE, IT) Time: 3 Hours 7 Max. Marks 75 Note: This question paper contains two Parts A and B. (b) (co) (a) e) (0) (g) (h) @ ® (b) eS O) (b) 5. (a) (b) Discuss in detail data-flow testing strategies. Part A is compulsory which carries 25 marks. Answer all questions in Part A Part B consists of 5 Units. Answer any one full question from each unit Each question carries 10 marks and may have a, b as sub questions. PART- A (25 Marks) List the goals of software testing. ‘What is path sensitization? Explain various loops with an example What is meant by testing? Write about any two application of data flow testing. Define nice and ugly domains. Define domain testing with example. ‘What is regular expression? ‘What is logic based testing? What are testability tips? List the different types of tools required for test planning. PART - B (50 Marks) Discuss about Myths related software testing and its facts. Explain about life cycle of Bug.- OR ‘What is meant by integration testing and what are the goals of it? What are control and sequence bugs? How they can be caught? OR Compare data flow and path flow testing strategies Distinguish betwee” specTROM .n Control flow and Transaction flow. @ULAN-ONE JOURNAL POR ENGINEERING STUDENTS10. " SOFTWARE TESTING METHODOLOGIES [yNTU. HYDERABAD) :) Non linear domain boundaries ( (ii) Complete domain boundaries. oR State and explain vatious restrictions at domain testing processes. Explain Regular Expressions and Flow Anomaly detection. OR Explain path expression with examples. (a) Categorize various testing tools necessary for testing. (b) What are the using of win-runner? oR (a) What are the principles of state testing. Dis‘ (b) Explain about node reduction algorithm. . cuss advantages and disadvantages. (Unie) 4) (Unt 1051) (Unie 823 (Une 222) (Unie 019) (Unie / 219) (Unit-v 018) (Uni. /a29) (unity / 22)eee eeeny Feyeeraved Kl] 5 y B.Tech ill Year Il Semester Examinations, December - 2018 Em SOFTWARE TESTING METHODOLOGIES (Common to CSE, IT) Time: 3 Hours : == _— ime _ Max. Maa 75 Note: This question paper contains two Parts A and B. Part A is compulsory which carries 25 marks. Answer all questions in Part A. Part B consists of § Units. Answer any one full question from each unit. | Each question carries 10 marks and may have a, b as sub questions. jolt PART. A (25 Marks) (a) What are feature bugs? (b) () (a) (b) (b) (b) (b) (Unit og, Distinguish between builder and buyer. (Unit a9 What is Petri net? (Unit-t / a7 Explain about data-flow anomaly graph with example. (Unit-t | aa, What is domain ‘span? (Unit-t/ a1, Discuss about domain dimensionality (Unies jan Define silicon compilers. (Unit-tn | 05, Write eight steps in a reduction procedure, (Unit-i 108, What is possible state? (Unit-tv / 08 Distinguish between manual testing and automated testing. (Unit 08 PART - B (50 Marks) What are structural bugs? Explain. (Unit 037 Describe notational evolution of control flow graph with example. (Unit / 044 OR Explain heuristics procedures for sensitizing paths, (Unie4 18) Is testing is everything? Explain. omic Discuss about the data-flow model. (near c4t Explain transaction-flow graph implementation with example. (Unite 277 OR ‘ What are the structural test strategies based on the program's control unessoa at fi nt lain. flowgraph? Expl ite 028) Di about complication in transaction-flow testing, (un iscuss SPECTRUM @LLIN-ONE JOURNAL FOR ENGINEERING STUDENTS: feop.4 6 pprmrreeeai (2) Ex (v) Write about restrictions of domain testing about testing one-dimensional domains, oR Define domain testing. Explain about nice domains in detail, (a) Describe the mean processing time of a routine with example, (b) Write rules of Boolean algebra. OR (a) Briefly explain about regular expressions and flow-anomaly detection, (b) Write the procedure for specification validation. (a) What are some situations in which state testing may prove useful? Explain. (b) What are properties of relations? Explain. oR (a) Explain software implementation of state graphs. (b) Discuss about matrix representation software. SOFTWARE TESTING METHODOLOGIES (JNTU-HYDERABAD) (Unie sey (Unit / ang) ‘(Unit 1 082) (Uni cm) (Uni 42) (Unie | 0232) (Unie / 52) (unneay / am) (Unie 13) (UnitV / 012) (Univ 126)Question Papers.with Selutiogay. nie MITE) aVir 102 iritggn Jawaharlal Nehru Technological University Hiyderat B.Tech Ill Year li Semester Examination’ Apri - 2018 owt ae SOFTWARE TESTING METHODOLOGIES 1 noe (Common to C8E, IT) dite ‘Time: 3 Hours: S ~~ Mps Marks 78 Note: This question paper contains two Parts A and B. (a) (0) © @y e) o- (9) (h) w @ Part Ais compulsory which carries 25 marks. Answer all questions.in Part A. Part B consists of 5 Units. Answer any one full¥question from each unit. Each question carries 10 marks and may have a, b as sub question. PART- A (25 Marka). 1» What is meant by testing? Why we need it? ; Define a model for software testing * Explain various loops. Give example for éacH:*! Write the applications of data-low testing. In what a nice domain differs from ugly domains? Define domain testing with example Explain Regular Expressions. Explain sum of product form and product of sum form. Define good state and bad state graphs. How can the graph be represented in Matrix form? PART - B (50 Marks) State and explain various dichotomies in software testing. @) (b) (a) (b) (@) (b) OR ‘What is meant by program's control flow? How is it useful for path testing? Discuss various flow-graph elements with their notations. What is meant by transaction flow testing? Discuss its significance. Compare data flow and path flow testing strategies. OR Explain data-flow testing with an example. Explain its gent Explain the terms Dicing, Data-flow and Debugging. entacnci ate! 9 “Solutions agen (Unt a (Units 05) | conta | (Unie cm (Unie Omg (Unie! Ot) (Unit-ii / Qa) (Uniti | Qe) (Unit-tV 1 (Unit-V / Gi (Unit (Unit (Unitt! (Unie (Unies (Units (Unit SPECTRUM ALL-IN-ONE JOURNAL FOR ENGINEERING STUDENTS |... Zuliay!”™10, "1 . ‘téte and Explain (oy wage nest diagram, ues the domains and interface testing in deta piset write short notes on following, (e)_ Distributive laws (0) Absorption rule (o) Loops Identity elements. @ OR Reduce the following functions using K-Maps. F(A, B, C, D) = x(4, 5, 6, 7, 8, 12, 13) + d(1, 18). (a) Write testers comments about state graphs. (o) Explain about good state and bad state graphs. OR What are graph matrices and their applications? Explain in detail, (Unie 20) (Unie / a4ay (Uniev/ 13) (Unitv 1216) (Unit-v 19) Xerex/Photicopying ofthis book is a CRIMINAL act. Anyone found guity is LIABLE to face LEGAL proceedings.MID -1&1 f= me ai az, 93, as. Qs: a6. ay. as. oy performs program exeostion but ako detect bugs thot halt the execution of e program. The two MGI goals of software testing are bug discovery and bug prevention. Testing is applied to anything from teupie softeare consisting of only o few lines to that of o complex one. There are four different types of “Siting ther con be performed om o software system. They are unit testing, component testing, integration NSS cnet epsom senting. * comet Rlowgraph & ¢ form of 2 flowchart which does not deal withthe internal structure of the process “She 2 drow: the data flow ond the control flow between the processes. Path testing deals with the ecuion of paths. all the cvoilcble control lowpotts ore tested then it means that 100% path coverage * Cihiowed which is mostty imposible. |e Se) SPECTREM 61148-ONE JOURMAL FOR ENGINEERING STUDENTS rrr 4: : ; 1.2 SOFTWARE TESTING METHODOLOGIES [JNTU-HYDERABAD ' * | (PART-A SHORT QUESTIONS WITH SOLUTIONS | Q1. : Define testing and debugging. (Model Papers, 21a) | May-160R1>), ori OR ‘What is meant by testing? Why we need it? ApeABIRI), ors; (Refer Onty Topic: Testing) Answer : Testing ‘Testing is @ method of estimating the productivity and quality of a software. It is developed by providing the necessay details about the software such as efficiency, portability, usability, capability, ec. Testing not only performs program execution but also detect bugs that halts the execution of a program. Testing is done by comparing the static and dynamic behavior of te software with the specifications described during the process of test design. The aim of testing is more than just debugging and detecting bugs. Basically testing is performed for the following ma purposes. @) Quality assurance () Verification and validation (©) Reliability estimation, . Debugging . Debugging is the process of fixing the errors that were identified during the process of testing. Q2. List the goals of software testing. Answer : May-19915), an | Goals of Testing ‘The two major goals of testing are as follows, 1. Bug Prevention “Bug prevention” is considered as the primary goal for testing, When a bug is detected, appropriate method should be w=! to remove it. And if the bugs are not prevented, then certain symptoms are discovered that are the major causes for the occurs? of bugs. When a particular bug is prevented, there’s no need to perform testing again to confirm the accuracy of the program $ prevented bug won't affect the execution schedule of the program. 2. Bug Discovery “Bug discovery’ is considered as the secondary goal for testing. It is performed when the primary goal fails to preveat ® bugs. Since bugs are not static, they always change their states. Even ifall te information regarding the expectations, proceds® and output of test are maintained, there is a probability of errors to occur. A single bug can have many reasons for its occurres* ‘Therefore, just by determining that the program is incorrect doesn’t reveal the discovery of bugs. Each symptom can be reve only by performing many small detailed tests on each of the individual symptoms. Q3. Designer versus tester. Answer = Designer [gner deals with the structural specification of the nea “Tester deals with the functional specification of the syste cae een on the implementation details, . | He/she is independent of the implementation details. ee ‘fimplementation makes the designer | 3. | Due to the lack of implementation details, the developed) ‘The knowledae of ware software is inefficient. to design an efficient 50 : og oftie books # CRIMINAL ack. Anyone ound guilty i LIABLE Wo fce LEGAL proceeig® WARNING:a4. Distinguish between builder and buyer, answer! The objective of independent soft zrovide an improved software 4 Bec. -191815), 0145) ware developme aN enhanced ceunt and better testing, This objective has beeone Sram inca wie developing gape 4 ssa hata software to be purchased fom ee rte developed within the organization ily gy ene Scountablity clear. This identifies the relat ated sciware developed object Tware development class, o 1 with each other ship between le object. The lass must sign nd the payabl \d the functional ef OP SEN rancor nat ete ee mB conte con Bem ae Ya te motivation of developing a good quality software pret sarishes There ate many individuals involved in the software evelopment life cycle like programmers and testers that who cancollaboratively perform various test operations i) Builder is the one who is responsible for dev eloping and, designing the software. i). Buyer is the one who pays for the software for gaining profits (ii) User is the one who is the final recipient of the system. (i) Tester is the one who is responsible for any kind of builder's loss, (9) Operator is the one who takes into account the builder's mistakes, the user’s criticisms, the tester’s faults and the buyer's obscure decisions while developing any software application, 5. Define a model for software testing. Answer : ‘Apri-18(R15), 410) as i) Frequency Testing is applied to anything from a simple softw ee, Consisting of only a few lines to that of a complex one. (i) Cor * Atypical testing model can be divided into three models, aii) as : Application cos |. The Environment : 2 ifferent categories of bugs. 9 the The environment of @ program is the hardware oN | Qi = dures BP ‘ware under which the program runs. The avira and | Anewes 1 classified into the following categories ence. B*raly found because they ar tested thoroughly Bugs have bee vet hes bs ealed ‘tors found are fixed. 1. Requirenents, feature The Program structural bugs — ie consider simplified 2 «documentation bugs % ‘Amodel test for a program will only consi toy 3, Coding an “no® ofthe program but not in whole ee ‘model 4, Data bugs 1 Sted gives unexpected results then the P Interface bes “be modified to include more details 5. in j 6, Inegraton buss Migs Model ue 10 gs em. 2 reasons. Hay be die 7, System bus ong RBS cam arse due to many E9805. IO i ae nt alization, the wrong call Sequence: OF ora bug 8 ped «uk Peciication may’ also lead to the cone MEERING STUDENTS , “2h he behaviour of the program may DE journal. FOR ENG! specTRUM ALLAN-ONE 7 6. List the “ aiterent raw 1¥Pe8 of testing, Thee ae four peo fe tg ng Iware system, They are as fol ae L Unit Testing a The main Purpose of pron sce etenent aso tence eee structure designed?" 8 %tsrilar tothe expected | 2 | test design. 3. Integration Testing {Integration testing is performed when the individual ‘components undergo component testing succesfully 4. System Testing. System testing is performed to show the behavior of the system: Itis done either on the whole systerh that is integrated or only on the important parts ofa system, Q7. What is bug? On which factors does the importance of bugs depends? OR What is meant by a software bug? Explain. (Model Papers Ha) | May-7(R1), 1), Bugs are the errors that can stop the program execution and sometimes generate incorrect output. The imporance of ‘bugs depends on the following factors, Answer :SOFTWARE TESTING M |ETHODOLOGIES [JNTU-HYDER, Aaa), sorter HOBOS THN Q9. What are feature bugs? Concatenated Loops Answer : ec.-10(R18), 10) “The difficulties that arise in feature bugs are due (othe specification problems. A feature can either be an incorrect feature or a missing feature. A missing feature can De detected rear ected easily. An incorrect feature has a significant impact ‘on the detailed design description. “The unnecessary enhancements increases the sohware complexity. The features such as reliability, modularity, cerrmainabitity, robustness etc., when enhanced, must be suspected if, they fail to fulfill their objectives. ‘When the Tenures are climinated, the following consequences arise, Software becomes sophisticated * Additional resources are consumed 4 Additional bugs are stimulated. by static and dy! Q10. What do you m Answer Static Data ‘Static data is fixed and doesn’t change its structure oF content, Static data is analyzed based on the source code that is cond to determine whether the piece of code is reachable or not. weet mber, string of characters or abit pattem are the examples A ntatic data that are not declared clearly in the source code, Dynamic Data jc data are not fixed and change its content after ified period of time. The life span of dynamic datas Yo valent to the processing time of a single data is analyzed based on the behavior ‘whether the piece of code is aspeci short which is equi transaction. Dynamic code that is used to determine reachable of not, Q11. Explain ‘exampl ‘April16(R15), O46) joops. Gi OR ious loops with an exami Explain vari Answer: © May-19(R18), ANE) “There are three different kinds of100P3- They are, 1, Nested Loops . “The nested loops are quite ‘complicated as a loop within another loop is known as nested loop. Example a CConcatenated loops ae the loops which side one bsg | the other on the same path. In other words, when ‘cm {wo adjacent loops on the same path such that, an exit aa Mop serves as an entty point Fr the other loop, then the | are said to be concatenated oy Example Figure (2): Concatonated Loops Horrible Loops Horrible loops are the Joops and may involve nested loops, intersecting connected loops all in one structure. most complex among all het oops ances Example Answer ¢ ‘The elements of flowgraph are, 1. Process blocks 2. Decision and case statements 3, Jimetions. Process Blocks Process block is a block which ‘statements, which once initiated results of all the statements in that block. econo [oes] —* Figure (1): Process Block Decision Decision is flow can split. The flow gets options available. * oa consists of in the: 2 @ point in a program at which the of ‘diverted in one of 2 Decisions pisepo <=? ae ‘THEN D? Figure (2: Twoway Decisions“Ajunction is just a contradict to decision. All the control flows can merge at a point in a program which can be termed as junction toe Figure (4): Junctions 013. What is control flowgraphs? List the advantages of it. Answer : trol Flow Graph ‘ Model Paperst, (5) A control flowgraph is a form of a flowchart which does ‘0( deal with the internal structure of the process, rather it shows ‘te data flow and the control flow. Every control flowgraph has ‘ome mandatory elements. They are, 1. Process blocks 2. Decisions and case statements 3. Junctions. Adve tages of Control Flowgraph The advantages of control flowgraphs are as follows, Conttol flowgraph eliminates the occurrence of some Problems which results from expanding the visual Complenities, £2utolflowgraph eats all the steps inside a process aa 4 to ang oceSS entity and shows only data and control flow ots ioe that entity thereby reducing the complexity font0llowgraph can be referred as a modem approagh Presentation of flows. Cone the wo! flowgraph gives the precise and clear view of 1 Program structure, the directions of data flow etc. SPECTRUM ALL-I tuction, Flow Graphs and Path Testin wut Introd 9 Ls Tare Statements 14. How do you convert a flowchant Into a flow (©) ydevision can split the control flow into different way graph? am ec ismutivny banchescan hetommed reco | Anawer aarements. eps ved = involved in converting & flow char nto a fo ci graph'are as follows, 7 " Stept:Determine the decision points in the program Step2:Break the complicated decision points into. 4 ximple predicate ot Step3: Merge all the sequential statements into a single node $0 that all the statements get executed simultaneously ‘Step4:1f Sequential statements are after predicates. then mense the set of statements and predicates into a node. This Junctions : node is called asa predicated node from where out two edges emerge. ‘StepS: Verify that all the edges must end at some node ‘Step6: Add a node at the end of the program to specify the sets of sequential statements, Q15. What is the intent of path based testing? Answer : May-71R15), 100) Path testing deals with the execution of paths. [fall the available control flowpaths are tested then it means that 100% ath coverage is achieved. However, although path testing examines each transition in a graph it is quite impossible to guarantee complete testing. As per the statistical reports. path testing captures approximately 35% of bugs in the overall structure. The principles of path testing are much similar to the principles of state testing. Q16. Define path sensitization and path instrumentation. OR What is path sensitization? (Refer Only Topic: Path Sensitization) May 19(R15), 410) Answer : . Path Sensitization Path predicate expressions are the collection of expressions that must be fulfilled in order to achieve the desired path. If all the expressions are satisfied then the path is said to be achievable, else the path is not achievable, An attempt to find the éet of solutions to the path predicate expressions is called path sensitization. Path Instrumentation Path instrumentation is @ technique used for identitying whether the outcome of a test is achieved through the desired path or a wrong path. Path instrumentation technique is another form of interpretive trace program, which will run each and ‘every statement sequentially by storing all the labels and values of the statements covered so far. I-ONE JOURNAL FOR ENGINEERING STUDENTSSOFTWARE TESTING METHODOLOGIES [JNTU-HYDERA\ ESSAY QUESTIONS WITH SOLUTIONS 1.1 INTRODUCTION 1.1.1 Purpose of Testing Q17. What are the principles of test case design? Explain. Answer t Principles of Test Case Design ‘Test case design involves three important principles. They are, 1, Effective fragmentation of the available tests 2. Accurate testing technique for each test module 3. Specifying correct level of details for the test. 1. Effective Fragmentation of the Available Tests : Every testis fragmented (broken-down) into individual test modules that are easy 10 understand and manage. These modules are complete and even aggressive to detect bugs before system is fully designed. Designing of the test case is an impor, ra ae eae cones in teat automation, Each module has a welldefined scope that is different from the other modules. This sy determines how the test cases should actually look like, 2. Accurate Testing Technique for Each Test Module Each ofthe fragmented test module is called as ‘mini project’. The scope of these test modules determines Yaris techniques hat are used to develop an individual test module. Te testing strategies that are used to build the test casts vmalve: decision bles, ete, Decisions need to be made regarding who should be involved in creating and evalating be aasee: For example, consider atest module whose objective i o test the estimation of insurance premium. It requires ‘department to get involved in performing the test. 3. Specifying Correct Level of Details for the Test . “According to this principle, a correct “level” of abstraction should be determined. The high-level details that are for developing tex cases shouldbe specified and all the low-Ievel implementation details should be hidden, The low-level are static and do not undergo any sort of changes even if the system undergoes changes. The low-level details are store ifferent reusable automation routine or a procedure that is common to all test modules. Because of this abstraction, test snore concise and understandable. For example, in an employee database, tests are performed using high-level routines like" ‘mp status” and “check emp-salary”. But while testing a low-level dialog routine, an action called “click” is used 10 whether OK button is clicked or not on the appeared dialog box. Q18, Define testing and explain the goals for testing. 2 Answer : - Madl aoe Testing | “Testing is a method of estimating the productivity and quality of a software. It is developed by providis ; id providing the neces details about the software such as efficiency, portability, usability, capability, etc. Testing not only performs program exec™ ‘but also detects bugs that stop the execution of a program. Testing is done by i iynami of . y comparing the static and d vi ‘software with the specifications described during the process of test design, cee Goals of Testing ‘The 1wo major goals of testing are as follows, 1. Bug Prevention e ou reves considered as the primary goal for testing. When a bug is detected, appropriate method should te? if the bugs are not preverited, then certain symptoms are discovered that are the major causes for the oc of bugs. When a particular bug " ug is prevented, there's no need to it prevented bug won't affect the execution schedule aitemea {etingwgpin to confirm the accuracy of Se F Decne and prevent bag bef is considered as the bes bug preventer. Itmuns that if testis properly designed then itis eas 3 igs before coding phase. If testing is performed at'every stage of software devel nw designing coding followed by actual tenting (ghas} would be unneceasach oa ell ne base Kane en disconeng and ee during the design phase itself. ave been discovered and pre WARNING: {erox/Photocopying ofthis book is a CRIMINAL act. Anyone found guilty is LIABLE to face LEGAL proceedings.eae Bue 2 " is considered as the iscovery'i secondary goal for ene erformed when the Primary goal fails oponen sess Since BUBS are NOt static, they always change thei, tbe fall the information regarding the expectations, He gues and Output of test are maintained, there ing spy of efrs 10 occur. A single bug can have miky rors occurence. Therefore, just by determining ty mm is;ncorect doesn’ reveal the discovery bugs. sro canbe revealed only by performing many sve se ets on each of the individual symptoms. a9. Explain the different purposes of testing, answer! ec.-14{R09), ania) purpose of Testing, Software testings a proces of evaluating the potentiality {1a system and determining it in accordance with the pelicans. The am of testing is more than just and detecting bUgS. Basically testing is performed for the folowing main purposes. ()” Sofware quality assurance (b) Verification and validation (©) Reliability estimation, Software Quality Assurance (SQA) ‘Quality is used to determine if the software meets all ‘ryuitements that were specified during design phase. are quality assurance is used to monitor the software Products inangible and can never be finished. Testing Sully of a software is expensive because it includes cost of tg and comecting bugs, cost of developing and exeuting case, )eiheation and Validation (V and V) V 04 V is performed to the quality of a software. sit 8 et el, testers make deiscns oo whether etl work property or not The specications and dar diferent products are compared to know which emt Se quality: The quality i not tested directly yall aspects of quality are tested wo make software win Steaua hs oe aspects ame ie neering and adaptability. These aspects wr ESTE the Scope of efege quality, Each Nain aemEMIES into its coadponcnt elements and “SS made to specify the software quality yuit1_roducton Flow Graphs ahd Path Testing a It is an exterior quality factor which is determined by considering correctness, reliability, usability and integrity of a product. (ii) Engineering Its an interior quality factor which is determined by considering efficiency, testability, documentation and structure of a product. Adaptability . Itis a future quality. factor which is determined by Considering flexibility, reusability and maintainability of product. When a validation testis performed on a Product, itis referred as either a clean test or a positive test (ii) ‘The'disadvantage of validation is that the software works ‘only for some particular test cases. The finite number of test cases cannot ensure that the software works properly under all Circumstances. On the other hand, only one failed test shows thatthe software doesn’t work. Negative tests are performed to show that the software fails to meet the expected requirements of the user. Software should have enough exception handling capabilites to handle the negative test cases, (©) Reliability Estimation ‘Testing is an important factor to quantify software reliability which is related to the different aspects of software such as structure, documentation etc. It is a method used to estimate the functioning of a failure-free software for a Particular period of time in a specific environment. Its difficult (0 estimate software reliability only by considering its elated aspects, An estimation model is used for performing data ‘analysis for estimating the present and future reliability, Based ‘on this estimation, the developers decide whether to launch the software or not and the users decide ‘when to purchase and use the software. Software reliability reflects the design perfection and differs from hardware reliability because of the software manufacturing perfection. The risks of using software can be ‘estimated based on the reliability information, High complexity of Software isthe major source of problem in software reliability ‘The approaches used for improving the reliability of software we. consuming and expensi G20. Explain different phases of tester’s mental life. Answer: Nov.10, St2, Me) ‘tester considers five phases of thinking. These phases are classified as follows, Phase @: Thinking Criteria” In this phase, testing and debugging are considered as similar. Testing is useful in debugging i.e. it supports debugging. When testing came fnto existence, phase 0 thinking was the preferred criteria for the software development. This thinking was applicable to an area from which the following resources can be determined, SPECTROM @LL-N-ONE JOURNAL FOR ENGINEERING STUDENTSquality control to of phase 3 thinking, them. Even by testing 4 that software doesn’t change. How’ SOFTWARE TESTING METHODOLOGIES (JNTU. woens,, HYDERABAD) we 4: Thinker's Knowledge (i) High-cost and adequate computing resources i) Low-cost software resources (Gi) Single programmers ie) Small project resources (9) Irrelevant software resources. If this thinking governs an organization, then no quality, is assured and no efficient testing strategies exists for the software development. Phase 0 thinking is considered to be the biggest obstacle to test a good quality ‘software. This is because, testers and programmers lear software programming when this thinking (phase 0) was the criteria in early days. Phase 1: Thinking that the Software or Program Works ‘The sim of this testing is to display the working of program of software. Phase | thinking identifies the distinct relationship existing between testing and debugging. In this testing phase. the number of tests performed on a software ‘does not determine the execution of the software. Ifa single test among the infinite number of available tests fails, then the tester concludes that software will not be executed even if subsequent tests make its execution possible. The goal of phase 1 thinking (i.e. finding the errors in a program) is not achievable. Hence, this thinking results in a corrupted process because the possibility ‘of correct functioning of a software decreases with increase in software testing. ‘This phase uncovers the errors and therefore, itis a kind of reasoning to determine the working of a program without ‘testing it. Phase 2: Thinking that the Program doesn’t Work ‘The aim of this type of thinking is to demonstrate that the program doesn’t execute. The thinking of testers in phase 2 ‘opposes the thinking of designers. If test fails, then the goal of phase 2 thinking is accomplished. Inthe process of phase 2 thinking, bugs can be detected by testers, programmers: and designers in the following way, (i) The tester detects an error (bug) (ii) The programmer verifies and corrects the error (iii) The designer designs test (iv) The designer aims to perform different tests to identify different errors. The problem in phase 2 thinking is that it has a never ending process and produces bad test results. The phase 2 thinking results in a software which is both reliable and rigid in nature. Phase 3: Thinking that Test Reduces the Risk The aim of testing is to reduce the risks that are table. Phase 3 thinking accepts the rules of statistical improve the quality ofsoftware. Inthe process the tester detects bugs and eliminates 4 or software, the quality of ever, the software risks ease in the by testing. That is, if there it ane Phi “The aim of phase 4 thinking isto redu software with minimal testing effort Seen the ak seinmmum testing in order to attain goals of lower phase jt obtained by integrating the capability of testing wae 't Knowledge of knowing the conditions under which onan made testable. ware ‘Testing is done for the following reasons, (i) To decrease the manpower required for testing (ii), To ensure that a testable code has less number of tien compared 10 the code tha is dificult tog Debugging relies on testing because it corrects ony tiny ‘errors which are detected during the process of testing. The phase 2/thinking is not enough to show the complete win, of the software. When a software is fragmented, it become | ‘easier to process each individual software module. Some of the statistical control methods have ber | adopted to attain a good quality software. This is achieved means of fine tuning process where a huge software rest | few errors. The thinker's knowledge is not suficientio stan, 200d quality software but the tested software shouldbe pope | debugged before executing it. | G21. Why the testing is not everything? OR Is testing is everything? Explain. Answer + Dee. 1819.08 ‘Testing is an effective means of detecting ems) ‘Altematively, other methods are taken to detect and ‘ete. After processing these methods, the software is tested of the methods are described below in the ascending or their efficiency. 1. Walk Throughs, Inspection and Review Methods Inspections, walk throughs and review method £ performed to detect errors. ‘The drawback of ‘methods is that, they cannot detect all the errors B= in the software, they can identify only few ero 2. Program Design Method ‘The design model of a program determines whetbe! ‘quality of the program is good or not. An improper model degrades the quality of the software program design objectives such as openness, clarity: and est are chosen in order to prevent bugs. 3. Syntax Checking Method During the analysis of source code, the syns eh checked by the compilers. The static analysis siich as strong typing and type checking are © ‘These two methods detect all the errors inthe Pv and correct them, Static analysis is a part of fe and development to find erors in datasow 20 detection process. INAL act Anyone found gui Is LIABLE to face LEGAL proceedings.Nt Graphs and Path Testing se of Language 4 ‘The languages that are used in the Its free from serialization problems, ast Peet pe wo irre nee hopoprnaeat snakes the rate of bugs in tof th 3 used. Meu being software Development Methods software development method is ani which uses various methods for devel For example, a statistical control metho oY: contol method and automatic distribution of inten method are used to develop a software. These methen detect and remove most of the errors in the softens where the programmer is unaware of the changes ther take place after removing those errors. . Why is it impossible for a tester to find all the bugs ina system? Why itis not necessary for a program to be completely free of defects before it is delivered to its customers? wer : 5. internal process, Bugs are considered as the primary defects that occur the development process. Testing domain clearly depicts picture of bugs. The crucial goal of test team is to find and move all possible bugs which is practically impossible in this vorld of business critical software. {In general, it is very difficult to validate the entire code tocarryout repeatable tests, thereby consuming large amount time. If a program runs successfully, without any existence bugs, then itis considered as defect free. Even if there exists me possibility of internal bugs (which affects other routines), is type of occurrence may or may not be known to the tester. For instance, consider an IBM assembler programming in which the function is to feturn to its caller. rogram ASTUB CSECT BR10 (Branch return to the caller) END - Here “BR 10” is a branch to the address of register 10. s program doesn’t involve any type of real operation or fsction. Rather, it just contains single line of code. Upon ‘cution, if the program is debugged, then it runs in a smooth Snner as bugs are not encountered in this program as per the "ers observation, because of the following reasons. Code coverage tool specifies that code is exercised Properly and less time is required, becatise it is a single line of code. ‘Abnormal termination or any system crash doesn’t exist. No memory storage is required for this program, so the problem of memory-lack doesn't arise. | Dé ny locks or field updations Neate Multiple invocations on differ n on different processors can be exec etree Simultaneously, without causing any serious No data integrity problem exis ‘ Seat easy exist as program doesn’t read Despite of these, there isa possibility of bug which a i lt to detect. The bug may be considered as ©t Providing a set return code before returning to the ealler™ Following are the reasons that generate this type of bug. 1. Inconsistent program, 2 According to the rule of assembly language programming. register.11 consists of return code. When the above Program is existed, the content of register 11 goes unpredictable, Generally, the return statement identifies the success or failure of a program. So, a program with incorrect retum code leads to the failure of other programs like automation routines. Absence of this code, may also efféct the customer production environment and any other software which uses it Hence, defect identification plays a vital role in testing. ‘A bugis fixed by using the following return code, ASTUB CSECT SR 11,11 (Set return code) BR 10 (Branch retum to the caller) END Besides testing, testers must be well known with the concepts of testing for code coverage, abnormal termination or any system crash, as no test tool is supported. Hence, a tester will become a “good tester” if he/she possesses the characteristics such as right mind set, well-planned preparation and in-depth knowledge with respect tothe software, so that these type of bugs are eliminated completely. 23. Discuss the trade-off between quallty assurance costs and manufacturing costs. Answer + Software quality assurance costs and manufacturing costs are inversely proportional to each other. This means, if software {quality is not assured or checked properly, then rejection rate factor increases thereby affecting the net cost. Conversely, if software quality is assured or inspected in an efficient way to detect all the faults then rejection rate factor decreases and the inspection costs play a major role in affecting the net cost, *Q7as software quality assurance costs and'M as msienraasons then the inverse relation between them i acne bei SPECTRUM ALLIN-ONE JOURNAL FOR ENGINEERING STUDENTSa 1.10 SOFTWARE TESTING METHODOLOGIES [JNTU-HYDERARAy, 19 (0 We high then M4 ve hero nd ven vere ‘hv, the designers of manufacturing procees we makina, an effort to develog » balanced level between testing ad quality foesurance cote, se that et cot fi softornre quality We reduced Von manufactured goods, the relationship between prvctivty and quality of efvorare 1 entively diferent Testing, id werftovare quality wesurance corte fon thewe yrvds fluctuates In the following manner 1 These can be low percentile of (2%) in the comaumer producte 2 ‘These can be high percentile of (H%) in the techy science products like space-ships, aircrafts, nuclear temctons ee Generally, sofrware quality assurance corte play 8 vital ole in developmen process rather than the manufacturing com, hecause software quality assurance cants are computerized lance of checksums and error detection NovA0, $02, 0M) Anewers Pesticide Paradox (Virst Law) ‘very method used to avoid or find the bugs, a balance of delicnte bugs that are immune to these methods. “although the software testing methods satisfy the users to some extent as the software improves, hetter results are expected. ‘Suppose a farmer uses 2 pesticide for killing some kind ‘of insects every year, Also assume that, each year the pesticide kills 98% of the insects leaving 2% resistant, In the next year, farmer uses a combination of pesticides to slay them, which sigan reaidues 2% ofthe insects resistble, Eventually, the inseste sill become immune to pesticides. ‘This is known as pesticide paradox for both insects as well a¢ software texting. ‘Complexity Barrier (Second Law) “The complexity of the software grows to limits where tuman capability fails wo manage the complexity. Ir simple und easy bugs are tried 10 be eliminated by installing higher versions of software to retain the reliability, then this eventually leads to remainder of subtler bugs to tackle land increases the complexity. The complexity is not made to be Confined in ordbr to gain edge and interacting features but this pushes in a state of « complexity barrier, A complenity barrier is handled by weing the techniquen that can handle even more complex and fine ro ‘and its facts, - Anower 5 may 4410), 218) Myths related to software texting and its facts are as follows, 1, Myths Tooting in just a phase in SDLC. . nets Its s common myth in minds of academia that softw' ‘aang en openpacan of SDL aad it can be curried out only product is fully developed. However in practice, testing ena goon afer receiving the software specifications rough 0 De — even after the implementation of the 2 Mytie: Teeting can be deme on Feet: A hig mincomcertion, commer m the minds o vices abena wotorate testing 18 tat 1 820 <2¥y 1 whey vemcrnion af went case va COMpicx 20d tediras 1 deman cdoup umdersending sbi the project being developed, tet metus, bona Bevel AME PROCES 304 500. 0 teetng tone only serve to susonmate. the process The) doy ei toting atv ies, NET AE OWES Sallenging. and harder than woftware Sevclopment. 5 cn. faces many challenges like planning, and develorrng 1x a, understanding the project, developing the overall desvan cw: 3, Myth: Complete testing is possible Pact: This myth prevails at different levels of the developmn team. Many unexperienced person fee! that 10%* tesing possible all the inputs to the software are provided 0d ee Bt practically complete testing of the system i 3 fate poneiilty because al the possible imputs to test the wotrwe remot be provided and there might be possibility of few tin fatting unexecuted by the test team (as it may ake sean eEmplete). Hence the term complete testing can Pe fla wah" Effective Testing”. The objective of effective testing fo uncover severe bugs first by testing selected cases 4, Myth: Testing is done only when the program developed. onware is idenified. Testing is done in the form of veriion atthe end of every phase of SDLC. To perform testing the writes a detailed test case, executes them, and inform abo Test results etc. After the source code is developed tes simply a part of the whole software testing activity. 5, Myth: Software development is more worthy than Fact: This myth is commonly in the minds of both sof developers and freshers who are seeking jobs. It prevails cet were development is worth more than testing . The {hat testing does not offer career growih and is low: profi But testing is a complete process like development. Ther ater enjoy equal status and opportunities as that of devel Ithas become a path for job seekers. 6. Myth: Aim of testing is to check software function Fact: The Objective of testing is to ensure the quality software, As checking only the ‘functionalities of all modu hot ensure product quality. Hence other related things mi be executed to ensure that software meets the quality stan 7. Myth: Anyone can test a software Fact: This myth prevails that most of the people outs industry think that testing is an intuitive process and done without training, ‘However, testing is a rigorous ¢ demanding many skills. Tester must have a thorough kno of various phases of software testing life cycle, various ind how to operate them, recent techniques to des WARNING: xerox/Prctoconying of tia Book ie # CRIMINAL act. Anyone found guily e LIABLE to face LEGAL proceedingsduction, Flow Gi unites msphe and Path Testing bz Dichotomies 111 i List and explain various dichotomieg 26. related to », ‘oftware testing. Model Peco state and explain various dichotomies in somo “ Software testing, os pistinguish the following, OR me fo} Function Vs structure {iy The builder Vs buyer. (Refer Only Topics: Puetion Versus Structure, uidep Versus Buyer) lacncnced answer The various dichotomies related to software testing are as fol sting are as Testing versus debugging » follows, 1 2, Function versus structure 3. Designer versus tester Modularity versus efficiency ‘Small versus large 6. Builder versus buyer. |, Testing Versus Debugging For answer refer Unit-1, Q29. 1 Function Versus Structure For answer refer Unit-1, Q28. 3. Designer Versus Tester Designer Designer deals with the structural specification of the system. He/she depends on the implementation details. The knowledge of implementation makes the designer to design an efficient software. Tests executed by software designer are biased 10 structural specification because of which the tests must withstand the drawback of striictural testing. An increase in the knowledge of design increases the probability of generating a fault ‘Tester deals with the functional specification of the system, He/she is independent of the implementation details. Due to the lack of implementation details, the developed software is inefficient. ‘ests executed by tester is free from bias and therefore it is not possible to terminate the test. ‘An increase in the knowledge of test design, increases of eliminating the unneces ity Versus Efficiency 7 i of separate modules. Tests and systems both can be considered as the “modular” components since each of them are made uP em ue canbe defined nse dietinet, small component that has a well-defined purpose. Its very easy to undersiany te stem is v rent interacts with each other by means of interfaces. component used for constructing the system is small. Every component nicriel et O = _ ach : : ponent When 8 _ Smaller test cases are very easy to retxecut ¥ ane Process is carried out in the form ee al ent tests are executed. At the same time, if particular test : : “ed, only the small test cases, consisting Pagaderii rent test plan, Each test is designed to reduce the burden er ‘Hea only that test must be changed rath + test debugging and test execution. SPECTRUM ALL-IN-ONE yournat FOR ENGINEERING STUDENTS1.12 SOFTWARE TESTING METHODOLOGIES [JNTU-HYDERa| ‘Small Versus wrge Program: ‘Small Programs ‘Small programs have only few lines of code. ‘They consist of few components. These programs do not require any technique for testing. Large Programs Large programs have large number of lines of code They consist of large number of components, ‘These programs require Peon ee tm ‘They carry a data dictionary to store the data and thy perform the unit testing. Large programs are less efficient. Large programs are writen by different programmes, The quality of large program is low when compared small program. ‘They involve phases like designing, coding, testing, debugging, etc. ‘Small programs are more efficient. ‘Small programs are written by a single programmer. The quality of small program is high compared to that 6. Builder Versus Buyer ‘The objective of independent software development is to provide an improved software quality, an enhanced securyw better testing. This objective has become a core for many organizations while developing a software. It is not necessary ta, software to be purchased from a vendor. It can be developed within the organization itself to make the accountability clea Th identifies the relationship between the software developed object and the payable object. The software development clas the functional class must sign an agreement with each other in the same organization. Hence, the builder and the buyer shu separated, I they are not separated, then there can be no accountability due to which the motivation of developing a goed quis software product vanishes. ° ‘There are many individuals involved in the software development life eycle like programmers and testers tat wh collaboratively perform various test operations. (@ Builder is the one who is responsible for developing and designing the software, (i) Buyer is the one who pays for the software for gaining profits. (ii) User is the one who is the final recipient of the system. (iv) Tester is the one who is responsible for any kind of builder's loss. () Operator is the one who takes into account the builder's mistakes, the user's erticisms the tester’ Fults and oe obscure decisions While developing any software application. G27. What is the purpose of testing? Discuss about various testing dichotomies with examples. May 1 Answer Purpose of Testing For answer refer Unit-, Q19. Dichotomies For answer refer Unit-1, Q26. G28. Give differenc: Answer + Functional Testing 1. ] Functional testing is also known as black box or clot box or opaque box testing. : 2, | Functional tests are performed without the knowleds internal structure of the software. 3, | Testers and programmers are independent and * performs the tests individually. 4, | Tests are performed from a user’s perspective. ‘Structural Testing, Siractaral testing is also known as white box, lass-box, ‘open-box or clear-box testing: Structural tests are performed based on the knowledge of internal structure of the source code, ‘Testers and programmers are dependent on each other for test process. Tests are perform a finite time but cannot, detect all bugs. ‘ed either from a programmers oF 5, | The test cases take infinite time and detect all sO WARNING: seinen ck wa cay i amas ABE WN EGA PRES1. Introduction, Flow Graphs and Path Testing 1.13 by predefined paths in]'6.] inputs are represented by some peripheral devices or simulated systems pared to functional testing. | 7. | 1 x more effective than glass-box testing. «| Different methods for performing white box testing are, | &, Different methods for performing black box testing are, Tapa soft is less effective when © (a) Statement testing (0) Expected inputs m i) Decision testing (ii) Boundity vets ae (Gil Condition testing. ii) Megal values method, it helps in removing unneces in some bugs of errors. 29, Differentiate between testing and debugging, 9 | It helps in disclosing the problems and inconsistencies that may arise in functional specifications. Answer Debugging The goal of debugging is to detect errors and correct them. The goal of testing is to detect errors ina programy Testing is initiated with known conditions, 2. | Debugging is initiated with unknown conditions. 3. | The output can be anticipated. 7 3. | The output cannot be anticipated. 4+ | les necessary to have planned, designed and scheduled | 4. | 1t is not necessary to have any constraints constraints. 5, | Testing is a confirmation ot perceptible accuracy. 5. | Debugging is a reduction process. 6. | Testing'finds out the reason for program’s failure 6. | Debugging is the programmer's justification. 7 | Tre objectives that should be kept in mind while testing 7. |The objectives that should be kept in mind while is being executed are, performing debugging process are, (i) It should be easily predictable. (It should have experimentations, Gi). It should be fixed. (ii) It should have guesses. (iii) Tt should follow certain constraints or rules. Gii) It shoutd have initiative leaps. (iv) It should have independency. § |It is not necessary to have desigh knowledge while| 8. | It-is sufficient to have detailed design knowledge for performing testing, debugging. 9 | Testing is performed by a person who does not belong | 9. Debugging should be done by. person who bclongs ——— : to the company and has knowledge about outside environment. Designing and execution can’t be done automatically in debugging. "| The test design and execution are done automatically. ‘1.3 Model for Testing Describe the model for testing. Dee.-14¢R09), 2140) OR Explain a model for software testing. Now-43(R09), atta) OR Explain the Model of Testing. (Mode! Papert, Q2(b) | Nov.-10, Set-1, a5(a)) “41 for Testing : Testing is applied to anything froma simple software consisting of only a few lines to that of a complex one {Pica testing médel ean be divided into tree models The environment 3 The Program Bugs model SPECTRUM ALL-IN-ONE JOURNAL FOR ENGINEERING STUDENTS -“ee Expected Figure: A Model for Testing The Environment ‘The environment of a program is the hardware and software under which the program runs. The environmental enn rarely found because they are tested thoroughly over time and the errors found are fixed, 2 The Program A model test for a program will only consider simplified version of the program but not in whole. Ifthe simplified vese when tested gives unexpected results then the program model needs be modified to include more details. 3. Bugs Model Bugs can arise duc to many reasons. Itmay be due to wrong initialization, the wrong call sequence, or at times the wat specification may also lead to the conclusion of a bug though the behaviour of the program may be correct. There are some common believes that a tester should get rid off. They are, Benign Hypothesis: The belief that bugs are nice. Locality Hypothesis: The belief that the bug only effects the component in which it is found. Control Bug Dominanice: The belief that the errors in control structure of programs are more than bugs. ‘Sadism Suffice: The belief that complexity should be avoided to avoid bugs. Silver Bullet: Adherence to a particular language avoids bugs. Angelic Testers: The belief that testers are better than designers. Lingua Salvator: The belief that the syntax and semantics ofthe source language prevents most of the bugs 41. What are the different types of testing? Explain them briefly. : . OR What is meant by integration testing and what are the goals of it? ay 108185 (Refer Only Topic: Integration Testing) Amswer : “There are four different types of testing that can be performed on a software system. They are as follows, 1. Unit Testing . ‘A.unitis the smallest piece of source code that can be tested. I is also known as a module which consists of sever proces: i i is al that 2 pi sed by 2 single programmer. The main purpose of performing unit testing isto reve Of code tl the specie funcional requirements and alot phow thatthe suc implementaton so sil ructure designed. | FES nr be both static tests and dynamic tess. At fis, tatio test are performed followed by the dynam Unit tests cane bets and branches. Most ofthe unit tests are dynamic white box structural tests, These ee ae ibe orate as a whole or parts of sofware. Ifa bug s revealed whi performing the unittest either the exee glee eeeer to as a unit bug. WARNING: ‘Xerox/Photocopying of this book Is & CRIMINAL act. Anyone found gully is LIABLE to face LEGAL proceedingstroduction, Flow Graphs and Path Te yur resting Tomponent Testing x snent testing is nothing but black bo: mp fuer Canfening is used to testa single component ons gen aeons THES A component is created by integratin Toney ao forma single lage component Ajeet fs Ment and the function it calls, is also a compere nt can either bean individual module or w le reomcatemn. Component testing is performed whe ate doesn’t match with its functional specification co ve entation structure, defined during preliminary tec ea ach problems occur while performing the tests thes twas component bugs. These bugs are eliminated pe necessary debugging tools pene integration Testing iniegration isa process of combining smaller components epduce larger components. Integration testing is performed She individual components undergo component testing wtssfully: However, When components are integrated, 1 testing is either incorrect or inconsistent. The main ihe of integration testing is to detect the inconsistencies ‘eee these components. For example, 4 and B are components, rhe gone through component testing successfully, but fut when integrated. eal of Integration Testing, Italo ensures that each individual component behaves as ere specifications that are defined during test design. Some sf situations where inconsistency arises are as follows, (When there is an improper call or return statement. @ When there isan inconsistent standard for data validation. | When an inconsistent method is used for handling the data objects, Inegrated objects testing is a higher level compotent ‘Sthg compared to integration testing. The objective of ‘craton testing is to wipe out the difficulties that occur while “puting individual components. Following are the steps to perform integration testing. 4 and B components undergo component testing. 44 8 are integrated to perform integration testing. Thenewly integrated component (A, 8] finally undergo System: Testing 8m testing exposes bugs that are not resulted “nents or from the inconsistencies betweed "ete «, S3Stem testing is a black box functional teste “rope Software system. It is performed 10 show ve system. System testing is done eithet on Oe ‘ ene “ved (Pet the requirements specification. Testi onan the oe itvity, configuration, start-up and recover? Oe ences ans ieee refered ournat FoR Eval 1.15 232. Is complete testing possible? Explain. Answer : Possibility of Complete Testing May 189819), aXe) Wis practically and theoretically impossible to perform {esting if itis used for proving that a particular program 1s bue free, All the test that are used for demonstrating the correctness of a program provides the same result. These tests mclude. 1. Functional test 2. Structural test, 3. Correctness proof 1. Functional Test Practically functional tex subject the program to possible input streams. These streams can be managed in one of the following ways. (@ The stream is accepted and the correct outcome is produced. Gi) The stream issaccepted and mscorrest outcome is produced. (iii) “The stream is rejected The problem can only be solved with the correct out- ‘comes each input caries 280 outcomes which makes the testing impossible. A the length of the string to which the system is un known, itis impossible to perform functional test theo- retically. 2. Structural Testing Structural (or) path testing deals with every path to the routine which is impossible because soee paths might never terminate and some might cary infinite number of sub paths. 3. Correctness Proof Practically, the inductive proof for providing that correct ‘outcomes will be generated are very expensive and can be applied only to the routine with the formal ‘testers which make them Q33. Whatare the beliefs of unable to test effectively? Answer: Beliefs of testers which m: effectively are as follows, Benign Bug Hypothesis ‘bugs are nice, tame and logical, Now-10, Set-1, 05(0) jake them unable to test L ‘The testers belief that the a ogcal tStpat only weak Bugs possess 2 logic whic wen pi en ce be detect nite patern and they act as wild cards causing be any J ot ae amy es ae behavior EERING STUDENTS1.16 SOFTWARE TESTING METHODOLOGIES [JNTU-HYDERABAD) 2. Bug Locality Hypothesis The testers belief that the bug detected in an element affects the behavior of only that particular element. The aiotoms of bugs are localized to the components designed esis of structure, language, syntax and data sernivation. But this localization is confined only tothe weak fogs On the other hand, there are subtle bugs that can Be ‘liminated from the component at that specific time. 3. Control Bug Dominance The testers belief that most of the bugs are in the control structure of programs. This belief can work on easy bugs Present in the components Where they can be detected in control-flow, data flow and data structure errors. But, the subtle bugs that destroy the boundaries of data structure and data/eode separation Can not be detected by just viewing at control structure. 4. Code / Data Separation ‘The testers belief that the bugs differentiate the code and data, But practically, it is the indefinite variation that allows such bugs to exist. 5. Lingua Salvator Est The testers belief that the majority of bugs can be climinated by language syntax and Semantics. However, there is 4 possiblity of preventing the bugs (residing inthe component) by following true and good language features. But, there is no guarantee that these features even detect the subtle bugs in large systems. 6. Corrections Abide “The testers belief that a bug once corrected will always remain correct. This might be possible with local bugs, but in Tene of subtle bugs, itis quite difficult since there is a possibilty of the bug to occur recursively. 7, Silver Bullets ‘The testers belief that the components such as design method, language, environment, representation ¢tc., provide protection from the bugs. 8 Sadism Suffices ‘The testers belief that the bugs can be eradicated by jntrutions and low cunning tricks. But this is possible for only cosy bugs whereab, cough bugs can be eliminated only by using techniques and methodology. 9, Angetic Testers ‘The testers belief thatthe programmers are not 00 good ‘at code design. That is, they think shat they are better at test design than the programmers at code, design. 1.1.4 Consequences of Bugs Q34. What are the consequences of bugs? To what ‘extent can testing be used to validate that the ' program is fit for its purpose? Explain. Answer : (Mode! Paper, a3(e)| May-17(R13), 2) Bug “Abug isa fault or failure of software program. It produces an unintended or incorrect result. Generally, Bugs are caused {jue to mistakes done by programmers while coding. However Con: and of 1 2. 4 5 6. a pugs can also resuft due to incorreet coding in compilers WARNING: xeroPnatocoying of his book sa CRIMINAL act. Anyone found guilty LIABLE 10 fece LEGAL ysequences of Bugs The consequences of bugs can range from mild w catastrophic. The programmers write programs for humax, hence the bug consequences should be calculated in tem fumans rather than in terms of machine. The various by, consequences are as follows, Mild ‘This consequence results in an incorrect, misspelled wrongly aligned output, Moderate “This consequence effects the performance ofthe syiex land bence it results in a duplicate output. Annoying | Because of the presence of bugs in the system, performance of the system degrades. For example, (i The names are shortened or changed. (ii) Bills for even null amount are sent. Disturbing Because of this consequence, even the cor: transactions are not executed. For example, an teller machine’ refuses to process the " ‘transaction. | Serious - ‘The information about the transactions gets lost @ (i) Accountability (responsibility) of a transc™ (ii) Transaction occurrence. When such information is lost, the resulting bus a ‘serious bug’. ‘Tracking of transactions ‘Very Serious ‘This consequence results in reversing the ‘transaction such as, deposit transaction is withdrawal transaction. Hence, the system i perform incorrect transactions. | Extreme “This consequence occurs frequently and i to small number of users or transactions. Intolerable = When large amount of data is corrupted very difficult to perform the recovery proce situations, shutting down the system is o™ ‘best option. Catastrophe y Because ofthis consequence, the system taken proceednlt the right to shut down the system is4 introduction, Flow Graphs and Path Testing pot infections 0. that does not fail but corrupts th a 'e other systems Aa in the following consequences, a ) Destroys the physical conditions, @ «i. (ii). Kills the system, {v)_ Prevents the system from normal functioning, og for Validating Programs yor answer refer Unit-l, Q19, Topic: Verification and jaston (Vand V). what are the factors that determin O85. Tonce of bugs? Explain. aoswer ? bug fers toan error that stops the program execution ten produces an incorrect output. The importance of bugs - iven below, pens on the factors given below, (Frequency (ii) Correction cost (ii) Consequential cost Gv) Application cost. @ Frequency Frequency of a bug refers to the rate at which, it occurs. The more frequently it occurs, the more will be its frequency, : Correction Cost Once the bug has been detected, it needs to be corrected. Conection cost is nothing but the cost that occurs during theeror correction process. This cost depends upon the following two factors (i) The bug detection cost (i) The bug correction cost. ‘Te cost of these bugs increases suddenly at the later Stages in the development cycle, when the bug is discovered ne Size of the system also effects the correction cost pith increase in the size of a system, the correction ‘st also increases, Crequendal Cost I nie?®4s upon the consequences (affects) of bugs. System TARY Consequences of bugs which makes the 1 Sither 10 shut down or kill. ation Cost : ie Mcston cost depends upon the namber of installations eg ae relies on the different applications that are Mereases, po Stem- As the number of applications olcatigg AOE *8Sociated cost also increases. The Pees of gant C88 Control all the other costs. During the "ore. patallation, the probability of bugs occurrence “nes, the application cost is also high Liquefies the nuclear reactors, the impor. 5. Now, a list of potential bugs SPECTRUM ALL-IN-ONE JOURNAL FOR ENGINEERING STUDENTS 1.17 ‘A metric for the importance of bug i Importance of bug ~ Frequenty cost » [Correction cost + Application cost + Consequential cost} The frequency factor is independent of the surrounding but correction, application and consequential costs are dependent on the surrounding. SSpendenton the surrounding. 36. The importance of a bug type is calculated by ‘multiplying the expected cost of the nightmare by the probability of the bug and summing across all the nightmares. How? Mow-10, Set, 7(8) oR Explain the procedure used in quantifying the nightmare list to stop testing. Nov-10, Set3, as(a) OR How should you go about quantifying the night- mare? Explain. Answer : May-16(R13), 224) The procedure for quantifying the nightmare is given below, 1. Firstly, specify all the worst software nightmares faced by the user. Arrange these nightmares according to their symptoms generated and the reaction of the user to those nightmares. For most of the end users, the nightmares may be cither mild, moderate, annoying, disturbing, Serious, very serious, extreme, intolerable, catastrophic + or infectious. For programmers, the nightmares may be bad performance rating. 2." Compute the impact of each nightmare in terms of cost. ‘This cost is the summation of labour cost for the nightmare, cost of law suits, loss of business due to the nightmare ete 3. Arrange the nightmare list in descending order of their cost. Delete the low cost nightmares from this list (ie., the nightmares that can be neglected). 4. Consider the symptoms generated by each nightmare and * assume all the potential bugs that may be responsible for such symptoms. This assumption is based on the experience of the user, measured data and the statistics published. . generated for each nightmare. This bug-list is sorted in descending order of their,probabilities. In other words, the bug that is most likely responsible for those symptoms is kept at the top + and the bug that is least responsible will be kept at the last. It is also possible that, the same bug type may appear in different nightmares. ‘The bugs are then ranked in decreasing order of their importance. The importance of a bug type can be computed by ‘multiplying the expected nightmare cost with the bug probability and taking the summation of all the nightmares“SF SOFTWARE TESTING METHODOLOGIES [ynry, ‘ HYBERA 1.18 for 7. Design the test cases andthe inspection process to identify and eliminate the bugs, [atleast some bu test eases are onthe track, Otherwise, the new test eases ate required o be redesigned. Using theron tidy, estimated nightmare probabilities can be revised andthe nightmares ean be reordered, This testing ct ing test cases until the probability of all the nightmares become unimportant Peated Withee 8. Once the probability of all the nightmares becomes negligible, the testing process is stopped. The above procedure can be carried out before the initiation of software development. This is a general quantifying nightmares and may change with respect to the programmers and designers. Proced 1.1.5 Taxonomy of Bugs Q37. Classify the different kinds of bugs and explain. "oR Distinguish between data bugs and coding bugs. (Refer Only Topics: Data Bugs; Coeljg Bugs and Documentation Bugs) Now 9, oR Explain about structural bugs and coding bugs. (Refer Only: Topics: Sthictural Bugs, Coding Bugs and Documentation Bugs) No O02 OR Explain the 5 types of Structural bugs. ‘Now-10, Sets ap (Refer Only Tope: Structural Bug’) oR What are structural bugs? Explain. ‘Dec.-18(R18, 2 _ (Refer Ont Top! Structural Bugs) OR What are control and sequence bugs? How they can be caught? ys982 (BefesOnty Tope Con and Sequence Bugs) ‘Answer : The different kinds of bugs are as follows, = Requirements, Structural Feature and’ Bugs Functionality ‘Bugs Coding and Imerface System Documentation Bugs Bugs Bugs i {ture and Functionality Bugs z 1, Requirements, Fea es i ion about the requirements of the software. ‘Specifications. wed Spe Sd Gee Seer io the knowledge of specification, but the designer do not have ae ve! ae difficult to understand. TH SP acountered in the process of specification must be changed. as it, During the dee as es am of ulin the reauiremens of software i usally Po removed of modified. ; ja IMINAL act. Anyone found gui is LIABLE to face LEGAL proceed! oR 5 Xerox/Photocopying ofthis Books & WARNING:UNIT-1 Introduction, Flow Graphs and Path Testi ng specrRan ALLAN-OE J 1.19 Requirement B Requirements are expressed in the fo 2. Structural Bugs Fe ay hus that at expensive Structural hugs consist ofthe following bugs, ans antag of te requirements is that, mee The (ii) Logic bugs first-to enter into the system esa re i) Process on The requirement at last 10 leave the (iii) Processing bugs Seiievelopment and beta tot mnt Base through (iv) Initialization bugs Featere Begs (¥) Data flow bugs and anomalies The difficulties that arise in feature bugs are d (i) Control and Sequence Bugs the specification problems. A feature can either ey fo, ‘The software design gives importance to the contro! flow incorrect feature or a missing fe aig bugs which sees ing feature. A missing feature 1gs which are unusual in new software design. Control a ES A jectec a corrected easily. An incorrect flow bugs are important because of the following reasons, feature has a significant 1 - ae ignificant impact on the detailed design (a) The control flow problems are popular in the area ie of software design and testing literature because of 1¢ unnecessary enhancements increases the softivare ‘its adaptability. Therefore, they can be tested and complenity The features such as reliability, modularity, ‘detected easily in unit testing. ee ili, robusmess «when enhanced, must be (b) Researchers found that the inexperienced 7 pete i they fai zs fill their objectives. When programmers working on a software produce a iminated, the following consequences hore control flow bugs than the experienced e, programmers. Software becomes sophisticated (©) An assembly and COBOL language have Additional resources are consumed ambiguous code that are basically controlled by ‘ Additional bugs are stimulated. the control flow bugs. Functionality Bugs Every. phase of the software development life cycle The specification features that are accurate, transparent, is tested to detect the control and sequence bugs. The achievable and testable are not sufficient for detecting reasons for occurrence of control and sequence Puss functionality bugs. The features that are similar eee aes of loops, imeorrect criteria are combined to form groups. Thorough testing is Se replica processing, performed between the features of group and between redundant processing, missing process steps, ct the interaction of features. The difficulty arises when ‘Control and sequence bugs can be detected by performing there is an unexpected interaction between the features: structural testing, plan testing, merged with a bottom-line For example, the services provided by telephone are functional test specification. Different language options call holding and call forwarding. Call holding provides and styles with consumption of more memory space. can ‘an existing call to be on hold and receives the new call. bbe used to prevent these bugs to some extent Call forwarding redirects an incoming call to the other | (ii) Logic Bugs telephone. Based on this functionality, the following Logie bugs show the behavior of the statements and questions arise, operations. These bugs include incorrect design of test ‘What happens tothe third incoming call when there, cases, incorrect explanation and combination of cases, spper is an existing call on hold? complicated operators, etc. ‘What happens when a call is: forwarded by an For example, after execution of few statements in 3 already forwarded call? nested IF-THEN-ELSE statement, the truth valve of + ifacall is on hold. when a forwarded the logical expression is determined. This stops the a . necution of further statements. But the programmer rh , varded when a call is: ‘asumes that these statements will be executed. Though ° sl nape s if a call is Forme the boglean expression seems to be a single statement, ‘on hold? the prog mer cannot identify the sequet tial execution program que Every software has a set of uncommon eri ve 7 bf the program components sults inthe feature interaction FunePA i too dificult [logic bugs are not associated with the control then are simpler can be removed Ea ly. s. The high-level they are known as processing bugs. If they are associated eliminate the complex interaction DUB TT yg term tie the contol flow, they are known as contol Tow cation languages include short-term a6 0 ce 10 remove tugs. Logie bugs are similar to arithmetic bugs ‘where By using short-term there isa ete the programmers have more knowledge about arithmetic functionality bugs which is not possible ™! rather than logic. Support ‘ouRNAL FOR ENGINEERING STUDENTS1.20 The best way to eliminate these bugs is to perform structured flow testing such as logic-based testing. (Processing Bugs Processing bugs consists of algebraic, arithmetic, algorithm selection and mathematic functional bugs. These Bugs occur if wrong data conversion methods are used for converting data from one format to another. This wrong conversion is done usually in assembly language programming. The other problems associated ‘with processing bugs are: neglecting overflow of data, neglecting the difference between positive and negative ‘ero, wrong use of greater than, greater than or equal, tess than, less than or equal and expecting zero in floating [point operations. ‘These bugs are less frequent and they can be detected ‘casily by performing unit test or domain-test. Initialization Bugs Initialization bugs are detected by both experienced programmers and testers. Bugs are caused due to the. ‘mcorrect and unnecessary initializations. These bugs are frequent but are less harmful and affects the performance of the software. Following are the situations where an ‘mitialization bug can occur, @ When 2 programmer fails to remember that a variable has been initialized or expecting the initialized variable else where. (@)_ When the initial value of a loop control parameter Ihas an exror. (Gi) When an initialized value is accepted without performing any validation check. (iv) When initialization is done using an incorrect ‘structure. : ‘To reduce the initialization bugs, the variables must be ‘declared explicitly. Some of the bugs can be detected by ' preprocessor that is either built into the language ot exeouted separately as a different unit. Data Flow Bugs and Anomalies ~Data-flow anomalies arise when a data is attempted tw be used for unnecessary purpose such as using an ‘uninitialized variable, editing the data value but not using it, attempting to use a non-existing variable and initializing a variable fwice without using an intermediate value. &) © ‘The data-flow anomaly detection can be detected by a ‘compiler at both compile time and execution time, 3 Data Bugs ‘Data bugs occur because of the bugs in the specification of data objects, designs, number of data objects and initial values. Data bugs are treated as if they don’t exist in the software and are similar to code bugs. The low frequency of data bugs is, ‘usually due to poor bug accounting. WARNING: xerouPhotocopying ofthis book s a CRIMINAL act. Anyone found gui is IABLE to fece LEGAL. proceedings. a. SOFTWARE TESTING METHODOLOGIES [JNTU-HYDERABAp) Different types of data are, () Static Data For answer refer Unit-I, Q39, Topic: Static Data Dynamic Data For answer refer Unit-l, 039, Topic: Dynamic Data 4. Coding Bugs and Documentation Bugs Coding bugs create many other types of bugs. The syntax bugs are insignificant when the source language translator hay enough capability of performing syntax checking. But when translator fails in detecting a syntax error, a bug arises in the software. A detected error does not affect the test design sng ‘execution because the testing process begins only when such errors are corrected ‘The most common type of coding bugs are documentation bbugs. These bugs are caused due to small mistakes, wrong or incorrect comments in the statements. Therefore, these bugs re simple and less harmful. However, because of these bugs, other ‘bugs are also introduced in the system. The solution for these bugs lies in performing inspections, automated data dictionaries and specification systems. 5. Interface Bugs oy Interface bugs include the following, (i) External interfaces Gi) Terma interfaces Gi) Operating system, ) External Interfaces The external interface makes the communication possible with the outside world. An important princigle for interface design is that it should be robust. Aa extemal interface can either be a human or machine It uses a protocol that is complex and difficult w than external interfaces. Internal inaccurate protection against corrupted data, imprope! function call, protocol-design bugs, input and output design bugs and parameter call bugs. The internal interface bugs can be eliminated by propel) designing and following the standards of software.UNIT-1_ Introduction, Flow Graphs and Path Test sting System (ui) Operating S Operating system is associa i ciated with the bugs and interface bugs, Programmers eho eee ardware-related pro ers helieve that a ecg il therein oe mae system. As the operating system grows, the heen = detected and corected. Sometimes itis dimeut to jetec and correct the bugs from the symptoms ifthe bun are not present in the documentation, The masses should have the knowledge of locating the symptom The solution for operating system bugs are as follows, (a) Use specialists to write the interface program (b) Use declaration of macros explici ae plicitly for all system Integration Bugs Integration bugs occur when the interfaces are integrated between the assumed tested components. A smaller mponent makes use of many interfaces because of which there ‘more chances of integration bugs to occur. These bugs arise 'm the difficulties or inconsistencies between the components. ‘¢ communication methods 1ised for eomponents integration hold integration bugs. The various communication methods _ registers, semaphores, data structurgs, call sequences, tunication links, protocols etc. The integration bugs are frequent and cost effective because bugs are detected late the processing. ‘The solution for integration bugs include use of methods syntax testing and data flow testing, domain testing, Hardware Architecture Hardware architecture has both isolated and unreal nature during the processing of consecutive layers of operating system, compiler and other interspting Software. Software bugs associated with hardware drehitecturé arise when the performance of hardware jenot satisfactory. The misunderstanding is because of incorreet paging mechanism, incorrect input! output device operation, incorrect inpu/outPyt device veneration, incorrect format, location incorrect address ef ree eeee cata codes Cire ter aca improper way of interrupt handling, Cowen Tr Synchronization assumption, neglecting failures and neglecting operator faults. jugs are as The solution for hardware architecture bugs follows, gramming and testing © (a) Good knowledge of Pre’ specrRan ALLAN-ONE 1.21 (ii) Software Architecture Software architecture bugs are the types of bugs that coe interact with each other, Even if the procedures vee unit and integration testing, they don't ire bugs. These bugs occur ‘many components. ery difficult to be hhitecture bugs are successfully p expose the software architectu when the system is loaded with Software architecture bugs are v« detected. The causes for software arc as follows, Assuming that there are no interrupt signals. @ tered again (>) Assuming that the program code is ent (c) Overlooking that data interlocks Failure in closing and opening of interlocks. @ (c) “Incorrect assumption regarding registers or ‘memory initialization (Assuming that registers or memory locations are static. Software architecture bugs can be eliminated by properly designing the software architecture. 7. System Bugs fe revealed when system testing is System bugs ar ¢ is a complete performed. There bugs occur when ther: Interaction between different components such as program, hardware, data and the operating system. System testing must be performed before software is implemented. Because of this, ‘many bugs related to system are eliminated. But when a system bug occurs during the system testing, itis very expensive to fix the bug because of its complexity. ‘Transaction flow. testing is the only technique that is applied directly to the system testing for detecting and eliminating system bugs (i) Control and Sequence Bugs Control and sequence bugs are caused due to the following reasons. Expecting that events arise in an explicit order. @ (ii) Beginning a process before its requirements are satisfied (iii) Neglecting time: (iv) Neglecting when the requirements have been satisfied (v) Specifying incorrect priority level, program level. (vi). Incorrect, redundant or wrong processing steps. ‘The solution for control and sequence bugs is making use of highly structured-design such as employing or needed. re be wri (©) Centralized hardware program should specialized and well structuréd sequence control, ae a journal FOR ENGINEERING STUDENTS(ii) Resource Management Bugs Memory is fragmented into small resources which can be allocated dynamically such as queue blocks, buffer blocks, task control blocks. External mass storage such as discs is also fragmented into resource storage pools. ‘The bugs related with the resource management are due to the following reasons, (i) Required resources are frequent. (ii) Incorrect resource used when different resources have the same design. (iii) Resources already under usage used resource is not sent back to the resource pool. {iv) Resource assigned to the incorrect quetie. (v) Fragmented resources not properly merged ignoring to sent back a resource. ‘The solution for the resource management bugs are, (a) Use simpler resource structure. (b) Use limited types of resources and resource pool. 8. Test Bugs Testers are not resistant to any sort of bugs. For performing system tests, complex conditions and databases are required. Due to this complexity, there are chances for the occurrences of bugs while a code is being executed. Independent functional testing results in wrong understanding of specification. It is very difficult to distinguish between test bugs and software bugs. Though the specifications are correctly defined and implemented, the principle by which the behavior of software is ‘examined and assessed is incorrect. Due to which the behavior of | software becomes complicated and the performance of software will be effected. In short, the more complicated the test principle js, the more chances of bugs to emerge. Test bugs can be eliminated by designing a proper test. Q38. What are the remedies for test bugs? ‘Answer Model Papers, aa) ‘The different remedies (solutions) for test bugs are as follows, 1 Test debugging 2. Test quality assurance 3. Test execution automation 4. Test design automation. 1 Test Debugging Z bugs. Test ‘Debugging is the foremost step for’testing debugging and program debugging are differen fromeach other because of the following reasons, (i) Test debugging is simple and designed. It does not degrade the efficiency. WARNING: XeroxPhotocor casy if tests are properly 0) SOFTWARE TESTING METHODOLOGIES [JNTU.Hypg ying of nis book is @ CRIMINAL ac i a Test debugging has les effect when com RABAD) tests, Due to this, the frequency of complex inter ® y different tests performed by various software ot ey reduced. ‘signers Bex 2. ‘Test Quality Assurance This remedy tests the quality of the softwa whether it satisfies the given specifications ornot Teves thatall the test actions are executed accurately. There we tools that are used to test the quality ofthe software among software testing is the most widely used (prominent) i 3, Test Execution Automation The bug removal and prevention are identical iy other automation techniques. To reduce the manual co in the system, assemblers, loaders and computers ne developed. Test execution can either be done automata ‘or manually. The main purpose of automation tool is, remove the bugs during the process of execution. ‘automation is the most important requirement to perform design automation And regression testing, because itis alnoy impossible to execute large number of tests, manually. 4, Test Design Automation The test design can be automated since all the pats of software development cycle are automated. Because of tis automation, bugs rate decreases in both software as well asa test. However, itis difficult to perform data flow testing a domain testing manually. Therefore, test design is automat to.liminate this difficulty. Researchers use automation estas standard for building and supporting different automation oo. (39. What are the differences between static dat and dynamic data? | Answer: Static Data | Static data are fixed which doesn’t change its suet or content. It is analyzed based on the source code used determine whether the piece of code is reachable or not ‘number, string of characters ora bit pattern are the examples static data that are not explicitly declared inthe sourcecode example, a huge communication neiwork has several diflee# parameéters associated with it. These parameters specify l= of code, structure, network topology, features of lines choices for those lines etc. A site-adapter is used to POs these parameters. This process not cn initiates the values but also defines routines for declaring data, ii the size ofthe arrays and constants. 1a bug is detected in ® site-adapter program, then bugs als aris in the static dt is used by the entity application for that data. Any code executed during or before compile ti assembly time, load time or installation time results static data, When a site-adapter preprocessor is used by he, parameterized system, then a complex software applica developed with sophisticated object code. Once the va vert process is completed, the software used to produce best is said to be bug free. It is mandatory to perform validate recursively on each and every part ofthe software, eve! not the part of application. ‘Anyone found guity is LIABLE to face LEGAL proceedings