Software Testing10CS842 Model Question Bank Solution UNIT 1 A Perspective on Testing, Examples 1. Define the following : a) Error b) Fault c) Failure d) Incident e) Test f) Test case Soln. Error People make errors. A good synonym is “mistake”. When people make mistakes while coding, we call these mistakes “bugs”. Errors tend to propagate; a requirements error may be magnified during design, and amplified still more during coding. Fault A fault is the result of an error. It is more precise to say that a fault is the representation of an error, where representation is the mode of expression, such as narrative text, dataflow diagrams, hierarchy charts, source code, and so on. “Defect” is a good synonym for fault; so is “bug”. Faults can be elusive. FailureA failure occurs when a fault executes. Two subtleties arise here: one is that failures only occur in an executable representation, which is usually taken to be source code, or more precisely, loaded object code. The second subtlety is that this definition relates failures only to faults of commission. Incident When a failure occurs, it may or may not be readily apparent to the user (or customer or tester). An incident is the symptom(s) associated with a failure that alerts the user to the occurrence of a failure. Test Testing is obviously concerned with errors, faults, failures, and incidents. A test is the act of exercising software with test cases. There are two distinct goals of a test: either to find failures, or to demonstrate correct execution. Dept. of CSE, SJBIT 1 Software Testing 10CS842 Test Case A test case has an identity, and is associated with a program behavior. A test case also has a set of inputs, a list of expected outputs. 2. Difference between functional testing and structural testing Soln. Functional Testing: With the functional approach to test case identification, the only information that is used is the specification of the software. There are two distinct advantages to functional test cases: they are independent of how the software is implemented, so if the implementation changes, the test cases are still useful, and test case development can occur in parallel with the implementation, thereby reducing overall project development interval. On the negative side, functional test cases frequently suffer from two problems: there can be significant redundancies among test cases, and this is compounded by the possibility of gaps of untested software. Structural Testing: Structural testing is the other fundamental approach to test case identification. To contrast it with Functional Testing, it is sometimes called White Box (or even Clear Box) Testing. The clear box metaphor is probably more appropriate, because the essential difference is that the implementation (of the Black Box) is known and used to identify test cases. Being able to “see inside” the black box allows the tester to identify test cases based on how the function is actually implemented. 3. What is software testing? Why it is so important in SDLC? Soln. There are two main reasons: to make a judgment about quality or acceptability, and to discover problems. We test because we know that we are fallible — this is especially true in the domain of software and software controlled systems. The goal of this chapter is to create a perspective (or context) on software testing.It is so important in SDLC development phases, there are three opportunities for errors to be made, resulting in faults that propagate through the remainder of the development. One prominent tester summarizes this life cycle as follows: the first three phases are “Putting Bugs IN”, the testing phase is Finding Bugs, and the last three phases are “Getting Bugs OUT” . The Fault Resolution step is another opportunity for errors (and new faults). When a “fix” causes formerly correct software to misbehave, the fix is deficient Dept. of CSE, SJBIT 2 Software Testing 10CS842 4. Explain the triangle problem statement along with flow chart for traditional implementation. Soln. The Triangle Program accepts three integers as input; these are taken to be sides of a triangle. The output of the program is the type of triangle determined by the three sides: Equilateral, Isosceles, Scalene, or NotATriangle. Triangle Program Specification Keyboard Triangle Sides Triangle Program Screen Prompts & Triangle Types Data Dictionary Triangle Sides : a + b + c triangle sides 1. Get Input a, b, c 3. Triangle Type a, b, c a, b, c are non-negative integers 2. Is_A_ Triangle type code : equilateral | isosceles | scalene | not a triangle True prompts : 'Enter three integers which are sides of a triangle' False 4. Output Controller type code triangle type : 'Equilateral' | 'Isosceles' | 'Scalene' | 'Not a Triangle' prompts triangle type Figure 2.1 Flowchart for the Traditional Triangle Program Implementation 5. Explain the IEEE error and fault taxonomy and IEEE standard anomaly process in software testing. Soln. definitions of error and fault hinge on the distinction between process and product: process refers to how we do something, and product is the end result of a process. The point at which testing and Software Quality Assurance meet is that SQA typically tries to improve the product Dept. of CSE, SJBIT 3 of CSE. risk of no resolution IEEE Standard Classification for Software Anomalies. difficulty to resolve.Software Testing 10CS842 by improving the process. Table 1 Logic Faults missing case(s) duplicate case(s) extreme condition neglected misinterpretation missing condition extraneous condition(s) test of wrong variable incorrect loop iteration 6. SQA is more concerned with reducing errors endemic in the development process. Faults can be classified in several ways: the development phase where the Dept. investigation. Explain error and fault taxonomies. Both disciplines benefit from a clearer definition of types of faults. The point at which testing and Software Quality Assurance meet is that SQA typically tries to improve the product by improving the process. while testing is more concerned with discovering faults in a product. and disposition. Definitions of error and fault hinge on the distinction between process and product: process refers to how we do something. (A software anomaly is defined in that document as “a departure fro the expected”. Some of the more useful anomalies are given. testing is clearly more product oriented. Both disciplines benefit from a clearer definition of types of faults. Soln. action. and product is the end result of a process. testing is clearly more product oriented. the consequences of corresponding failures. SQA is more concerned with reducing errors endemic in the development process. In that sense. In that sense.) The IEEE standard defines a detailed anomaly resolution process built around four phases (another life cycle): recognition. which is pretty close to our definition. Faults can be classified in several ways: the development phase where the corresponding error occurred. SJBIT 4 . while testing is more concerned with discovering faults in a product. we need an example with larger scope. otherwise. The bank customer accesses the SATM system with a plastic card encoded with a Personal Account Number (PAN). among other things. Explain in detail various levels of software testing with embedded device like STAM as an example. the consequences of corresponding failures. and balance inquiries. the customer’s name and account information. withdrawals.Software Testing 10CS842 corresponding error occurred. then the system immediately displays screen 6. At screen 2. risk of no resolution 7. the system presents screen 2 to the customer. checking and savings. which is a key to an internal customer account file. Soln. where the customer chooses the account to which the selected transaction will be applied. When a bank customer arrives at an SATM station. of CSE. On entry to screen 5. matches the information in the customer account file). screen 3 is displayed. and the card is kept. after three failures. the system displays screen 5. Using a terminal with features SATM customers can select any of three transaction types: deposits. screen 4 is displayed. SJBIT 5 . containing. the customer is prompted to enter his/her Personal Identification Number (PIN). The customer selects the desired transaction from the options shown on screen 5.. Dept. If the PIN is correct (i. To better discuss the issues of integration and sytem testing. If the customer’s PAN is not found. The customer has three chances to get the PIN correct. the system adds two pieces of information to the customer’s account file: the current date. difficulty to resolve. and these can be done on two types of accounts. and the card is kept.e. screen 1 is displayed. If the customer’s PAN matches the information in the customer account file. The SATM system communicates with bank customers via the fifteen screens. screen 4 is displayed. and an increment to the number of ATM sessions. The real problem here is that there are interesting dependencies among the month. As with so many things. you get what you pay for.<x1nom. x2nom >. Justify the usage of boundary value analysis with function of two variables and highlight the limitations of boundary value analysis. A quick look at the boundary value analysis test cases for NextDate. x2min+ >. <x1nom. it’s known as the “single fault” assumption in reliability theory. for example. just above the minimum.<x1nom. and at their maximum. Boundary value analysis presumes the variables to be truly independent. The basic idea of boundary value analysis is to use input variable values at their minimum. x2min>. We see boundary value analysis test cases to be rudimentary. The boundary value analysis test cases for our function F of two variables are: {<x1nom. independent variables that refer to physical quantities. x2max>. Thus the boundary value analysis test cases are obtained by holding the values of all but one variable at their nominal values. x2nom>. <x1nom. just below their maximum. of CSE. day. <x1min+. Decision TableBased Testing: 1. This says that failures are only rarely the result of the simultaneous occurrence of two (or more) faults. and year variables.Software Testing 10CS842 UNIT 2 Boundary Value Testing. 2. x2max. What are the limitations of BVA Soln. x2nom >. x2nom >. in the sense that they are obtained with very little insight and imagination. SJBIT 6 . Soln. with no consideration of the nature of the function. nor of the semantic meaning of the variables. Equivalence Class Testing. Even so. The next part of boundary value analysis is based on a critical assumption. <x1nom. a nominal value. Boundary value analysis test cases are derived from the extrema of bounded. <x1min. There is very little stress on February and on leap years. Dept.>. and letting that variable assume its extreme values. boundary value analysis happens to catch end-of-month and end-of- year faults. Boundary value analysis works well when the program to be tested is a function of several independent variables that represent bounded physical quantities. we might postulate the following equivalence classes: By choosing separate classes for 30 and 31 day months. x2nom >. the special case of the year 1900. SJBIT 7 . As before. the next day is 1 and the month is incremented. <x1max. we have three classes of years.Software Testing 10CS842 <x1max-. By taking February as a separate class. At the end of a year. while days in D4 only have meaning for months in M2. 3. we can give more attention to leap year questions. and the year is incremented. Soln. Finally. and common years Weak normal Equivalence Class Test Cases These classes yield the following weak equivalence class test cases. the problem of leap year makes determining the last day of a month interesting. The key words here are independent and physical quantities. With all this in mind. We also give special attention to day values: days in D 1 are (nearly) always incremented. both the day and the month are reset to 1. Explain weak normal and strong robust equivalence class testing with next date problem an example. leap years. of CSE. If it is not the last day of a month. At the end of a month. x2nom > } Limitations of Boundary Value Analysis Boundary value analysis works well when the program to be tested is a function of several independent variables that represent bounded physical quantities. the NextDate function will simply increment the day value. we simplify the last day of the month question. Finally. the inputs are mechanically selected from the approximate middle of the corresponding class: Case ID Month Day Year Expected Output WE1 6 14 1900 6/15/1900 WE2 7 29 1912 7/30/1912 WE3 2 30 1913 invalid input WE4 6 31 1900 invalid input Dept. Technique : To identify test cases with decision tables. and actions refer to major functional processing portions of the item being tested. We still don’t have a “perfect” set of test cases. of CSE. Because the decision table can mechanically be forced to be complete. we know we have a comprehensive set of test cases. The same value selection criterion is used. conditions end up referring to equivalence classes of inputs. and actions as outputs. SJBIT X X X X X X X 8 . but I think any tester would be a lot happier with the 36 strong equivalence class test cases. The rules are then interpreted as test cases. They are ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions. 4. Conditions c1: a<b+c? F T T T T T T T T T T c2: b<a+c? - F T T T T T T T T T c3: c<a+b? - - F T T T T T T T T c4: a = b? - - - T T T T F F F F c5: a = c? - - - T T F F T T F F c6: b = c? - - - T F T F T F T F Rule Count 32 16 8 1 1 1 1 1 1 1 1 a1: not a triangle X X X a2: Scalene X a3: Isosceles a4: Equilateral a5: Impossible Dept.Software Testing 10CS842 Strong robust Equivalence Class Test Cases Using the same equivalence classes. Discuss the usage of decision table method to device test cases with example of commission problem and triangle problem. Sometimes. Soln. we interpret conditions as inputs. we find the strong equivalence class test cases shown in the table below. Decision tables have been used to represent and analyze complex logical relationships since the early 1960s. When the function F is implemented as a program. just below their maximum. The rationale behind boundary value testing is that errors tend to occur near the extreme values of an input variable. The basic idea of boundary value analysis is to use input variable values at their minimum.Software Testing 10CS842 5. Because the subsets are determined by an equivalence relation. and letting that variable assume its extreme values 2) Equivalence class testing The important aspect of equivalence classes is that they form a partition of a set. SJBIT 9 . Explain 1)boundary value testing 2)Equivalence class testing 3) decision table based testing Soln. This says that failures are only rarely the result of the simultaneous occurrence of two (or more) faults. Dept. 1) Boundary value testing For the sake of comprehensible drawings. it’s known as the “single fault” assumption in reliability theory. of CSE. where partition refers to a collection of mutually disjoint subsets whose union is the entire set. and at their maximum. a nominal value. The idea of equivalence class testing is to identify test cases by using one element from each equivalence class. of two variables x1 and x2 . the elements of a subset have something in common. F. If the equivalence classes are chosen wisely. just above the minimum. Thus the boundary value analysis test cases are obtained by holding the values of all but one variable at their nominal values. this greatly reduces the potential redundancy among test cases. They are ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions. the input variables x1 and x2 will have some (possibly unstated) boundaries: Boundary value analysis focuses on the boundary of the input space to identify test cases. This has two important implications for testing: the fact that the entire set is represented provides a form of completeness. the discussion relates to a function. and the disjointness assures a form of non-redundancy. The next part of boundary value analysis is based on a critical assumption. 3) Decision table based testing Decision tables have been used to represent and analyze complex logical relationships since the early 1960s. as we said earlier. conditions end up referring to equivalence classes of inputs.Software Testing 10CS842 Technique : To identify test cases with decision tables. SJBIT 10 . we know we have a comprehensive set of test cases. we use that idea here to generate worst case test cases. 6. Worst case testing follows the generalization pattern we saw for boundary value analysis. we could go to robust worst case testing. Rejecting this assumption means that we are interested in what happens when more than one variable has an extreme value. Worst case testing is clearly more thorough in the sense that boundary value analysis test cases are a proper subset of worst case test cases. Explain in detail worst case testing Soln. Boundary value analysis. Because the decision table can mechanically be forced to be complete. Sometimes. of CSE. and where failure of the function is extremely costly. max. nom. In electronic circuit analysis. we start with the five element set that contains the min. We then take the Cartesian product of these sets to generate test cases. This involves the Cartesian product of the seven element sets we used in robustness testing. and actions refer to major functional processing portions of the item being tested. Probably the best application for worst case testing is where physical variables have numerous interactions. as opposed to 4n+1 test cases for boundary value analysis. min+. particularly those related to independence. and actions as outputs. For really paranoid testing. It also represents much more effort: worst case testing for a function of n variables generates 5n test cases. makes the single fault assumption of reliability theory. we interpret conditions as inputs.and max values. For each variable. The rules are then interpreted as test cases. this is called “worst case analysis”. Dept. It also has the same limitations. DD-Path Testing When every DD-Path is traversed (the C1 metric). especially those for boundary and special values. when executed. 9. of CSE. Dept. For IF-THEN and IF-THEN-ELSE statements. there is an edge from node i to node j iff the statement (fragment) corresponding to node j can be executed immediately after the statement (fragment) corresponding to node i. its program graph is a directed graph in which nodes are either entire statements or fragments of a statement. If i and j are nodes in the program graph. Statement and Predicate Testing Because our formulation allows statement fragments to be individual nodes. we know that each predicate outcome has been executed. every node of the program graph is traversed at least once.Software Testing 10CS842 UNIT 3 Path Testing. Draw DD-graph for triangle problem. In our triangle example (see Figure 9. we could execute just one of the decision alternatives and satisfy the statement coverage criterion. Define DD-path. 2. Longer DDPaths generally represent complex computations. Explain different structural test coverage metrics Soln. Because we allow statement fragments. If we required nodes to correspond to full statements. it is “natural” to divide such a statement into three nodes. as opposed to just every node. each clause is covered.1). these coverage metrics require that we find a set of test cases such that. the statement and predicate levels (C0 and C1) to collapse into one consideration. this amounts to traversing every edge in the DD-Path graph (or program graph). it is useful to ask what else we might do to test a DD-Path. this means that both the true and the false branches are covered (C1p coverage). it may be appropriate to apply a number of functional tests. and edges represent flow of control. For such DD-Paths. and 10 are a complete Pascal IF-THEN-ELSE statement. Data Flow Testing: 1. Soln Given a program written in an imperative programming language. Beyond this. which we can rightly consider as individual functions. Whether or not our convention is followed. For CASE statements. SJBIT 11 . Doing so results in predicate outcome coverage. nodes 8. so far our simplifications have been based on removing either strong components or DD-Paths. Cyclomatic complexity does more to improve programming than testing. 16. IF (a < b + c) AND (b < a + c) AND (c < a + b) 10. b. THEN Writeln ('Triangle is Scalene'). of CSE.output). VAR a. Here.Software Testing 10CS842 Triangle Program Graph 1. readln(a. THEN Writeln ('Triangle is Equilateral'). 5 6 9 10 11 12 21 7 8 13 14 15 16 17 18 19 20 22 We will define DD-Paths in terms of paths of nodes in a directed graph. ELSE IsATriangle := FALSE . IF IsATriangle THEN 13. 12. Recall that condensation graphs are a way of simplifying an existing graph. Soln. SJBIT 12 .c). and the implications these have for testing. c : integer. we condense around the structured programming constructs. structured programming. where a chain is a path in which the initial and terminal nodes are distinct.b. Justify strongly connected graph is the number of linearly independent circuits in the graph using cyclomatic complexity metric.'Side C is '. 3. Dept. begin 5. THEN Writeln ('Triangle is Isosceles'). This whole package centers on the notion of essential complexity. IF (a = b) and (b = c) 17. writeln('Enter three integers which'). 9. IF (a <> b) AND (a <> c) AND (b <> c) 19.c).a. 18. 20. IsATriangle : boolean. 8. writeln('Side A is '.b. program triangle (input. THEN IsATriangle := TRUE 11. END 21. and every interior node has indegree = 1 and outdegree = 1. end. 4. In this section we take a quick look at this elegant blend of graph theory. 3. ELSE WRITELN('Not a Triangle'). We might call these paths chains. 22. 6.'Side B is '. writeln('are sides of a triangle '). 2. IF (a = b) XOR (a = c) XOR (b = c) AND NOT((a=b) AND (a=c)) 15. BEGIN 14. 7. which is just the cyclomatic complexity of yet another form of condensation graph. . and D is condensed into node a. of CSE. m) and USE(v. du-paths and dc-paths.Software Testing 10CS842 The basic idea is to look for the graph of one of the structured programming constructs. Give du-paths for stocks. This process which starts with the DD-Path graph of the Pascal triangle program. it can always be reduced to a graph with one path. B. sales and commission for commission sale problem. locks. 4. there are define and usage nodes DEF(v. and d. otherwise USE(v. n) is a predicate use (denoted as P-use) iff the statement n is a predicate statement. A usage node USE(v. A definition-use (sub)path with respect to a variable v (denoted du-path) is a (sub)path in PATHS(P) such that. The IFTHEN-ELSE construct involving nodes A. (denoted C-use). total locks. The nodes corresponding to predicate uses always have an outdegree ≥ 2. C. for some v ∈ V. A definition-clear (sub)path with respect to a variable v (denoted dc-path) is a definition-use (sub)path in PATHS(P) with initial and final nodes DEF (v. when a program is well structured (i. SJBIT 13 . n) such that no other node in the (sub)path is a defining node of v. collapse it into a single node. m) and USE (v. and repeat until no more structured programming constructs can be found. and then the three IF-THEN constructs are condensed onto nodes b. Define predicate node. Dept. is composed solely of the structured programming constructs). n) such that m and n are the initial and final nodes of the (sub)path. resulting in a condensed graph with cyclomatic complexity V(G) = 1. The remaining IF-THEN-ELSE (which corresponds to the IF Is A Triangle statement) is condensed into node e. c. In general. Soln. n) is a computation use . and nodes corresponding to computation uses always have outdegree ≤ 1.e. There are several widely accepted test coverage metrics. Most quality organizations now expect the C 1 metric (DD-Path coverage) as the minimum acceptable level of test coverage. Explain test coverage metrics and basis path testing with example Soln. 15 23 24 31 40 45 46 50 51 53 2 14 22 4 30 39 44 3 5 49 52 6 7 8 9 10 11 5.Software Testing 10CS842 DD-Path Graph for Lock. Stock and Barrel 1 DD-Path 1 2 3 4 5 6 7 8 9 10 11 Statements 3-5. The statement coverage metric (C0) is still widely accepted: Metric C0 C1 C1p C2 Cd Dept. Test coverage metrics are a device to measure the extent to which a set of test cases covers (or exercises) a program. of CSE. most of those in Table. Having an organized view of the extent to which a program is tested makes it possible to sensibly manage the testing process. SJBIT Description of Coverage Every statement Every DD-Path (predicate outcome) Every predicate to each outcome C1 coverage + loop coverage C1 coverage + every dependent pair of DD-Paths 14 . the set V consists of a single variable. As a guideline. then n is included in the slice. Eventually. and a set V of variables in P.Software Testing 10CS842 CMCC Cik Multiple condition coverage Every program path that contains up to k repetitions of a loop (usually k = 2) Cstat “Statistically significant” fraction of paths Table 2 Structural Test Coverage Metrics 6. we will develop a lattice (a directed. and edges correspond to the subset relationship. the slice on the variable set V at statement fragment n. P-uses and Cuses of other variables (not the v in the slice set V) are included to the extent that their execution affects the value of the variable v. that is. of CSE. if the value of v is the same whether a statement fragment is included or excluded. Presume that the slice S(V. is the set node numbers of all statement fragments in P prior to n that contribute to the values of variables in V at statement fragment n. Given a program P. then n is not included in the slice. If statement fragment n is a defining node for v. so a slice captures the execution time behavior of a program with respect to the variable(s) in the slice. L-use and I-use variables are typically invisible outside their modules.. in which nodes are slices. exclude the statement fragment. Thus O-use. If statement fragment n is a usage node for v. Explain slice based testing guide lines and observation in detail Soln. v. we need to explain two parts of the definition. Dept. The idea of slices is to separate a program into components that have some useful meaning. SJBIT 15 . Another judgment call: here (with some peril) we choose to exclude these from the intent of “contribute”. L-use. but this hardly precludes the problems such variables often create. Here we mean “prior to” in the dynamic sense. and I-use nodes are excluded from slices. acyclic graph) of slices. written S(V. n) is a slice on one variable. and a program graph G(P) in which statements and statement fragments are numbered. First.n). Generally. (ii) Upper level finite state machine. with the difference that stubs are replaced by driver modules that emulate units at the next level up in the tree. where stubs are pieces of throw-away code that emulate a called unit. There is probably less throw-away code in drivers than there is in stubs. we start with the leaves of the decomposition tree (units like ControlDoor and DispenseCash). so in the bottomup integration order. As a supplement. the functional and data Dept. 2. Validate Card. Explain the simple ATM application with the help of. Level 1 data flow diagram:. we won’t have as many drivers. Any lower level unit that is called by the main program appears as a “stub”. SJBIT 16 . This is problematic for testers. Validate PIN. and New Transaction Request. Control Card Roller. testers have to develop the stubs. Bottom-up Integration Bottom-up integration is a “mirror image” to the top-down order.The dataflow diagrams and the entity/relationship model contain information that is primarily structural. the first step would be to develop stubs for all the units called by the main program: WatchCardSlot. of CSE. and test them with specially coded drivers. Recall we had one stub for each child node in the decomposition tree. Soln. Top-Down Integration Top-down integration begins with the main program (the root of the tree). Most systems have a fairly high fan-out near at the leaves. Explain the decomposition based integration with an example Soln. Integration Testing: 1. (i) Level 1 data flow diagram. In bottom-up integration. This is partially offset by the fact that the driver modules will be more complicated. and some imagination is required. If we performed top-down integration testing for the SATM system. because test cases are concerned with behavior. Here are two examples of stubs. not with structure.Software Testing 10CS842 UNIT 4 Levels of Testing. Manage Transaction. Screen Driver. Soln. Any lower level unit that is called by the main program appears as a “stub”.Software Testing 10CS842 information are linked by a control model. this choice will prove to be very handy when we develop system level test cases. (i) Upper level finite state machine. here we use a finite state machine. we might choose states to be screens being displayed (this turns out to be a poor choice). we start with the leaves of the decomposition tree (units like ControlDoor and DispenseCash). Recall we had one stub for each child node in the decomposition tree. The decomposition of the Await PIN state. state transitions are caused either by events at the ATM terminal (such as a keystroke) or by data conditions (such as the recognition that a PIN is correct). they are of special utility to testers. There is probably less throw-away code in drivers than there is in stubs.The upper level finite state machine divides the system into states that correspond to stages of customer usage. and test them with specially coded drivers. Generally. and some imagination is required. Control models represent the point at which structure and behavior intersect. Control Card Roller. 3. of CSE. Manage Transaction. Distinguish between top-down integration and bottom-up integration. and New Transaction Request. Other choices are possible. where stubs are pieces of throw-away code that emulate a called unit. Screen Driver. If we performed top-down integration testing for the SATM system. Here are two examples of stubs. Validate PIN. a corresponding action may also occur. the first step would be to develop stubs for all the units called by the main program: WatchCardSlot. Validate Card. Finite state machines can be hierarchically decomposed in much the same way as dataflow diagrams. with the difference that stubs are replaced by driver modules that emulate units at the next level up in the tree. We choose to use screen displays as such actions. Bottom-up Integration Bottom-up integration is a “mirror image” to the top-down order.:. In bottom-up integration. Most systems have a fairly high fan-out near at the leaves. When a transition occurs. Top-Down Integration Top-down integration begins with the main program (the root of the tree). so in the Dept. testers have to develop the stubs. for instance. as such. In both of these figures. SJBIT 17 . but it is a drastic reduction in stub/driver development. 4.) We (informally) define the neighborhood of a node in a graph to be the set of nodes that are one edge away from the given node. but we restrict a session to just a pair of units in the call graph. Explain call graph-based integration with the help of. Neighborhood integration yields a drastic reduction in the number of integration test sessions (down to 11 from 40). (This isn’t too much of a stretch — graph theory is a branch of topology. this sounds like big bang integration. not the decomposition tree. This is not much of a reduction in sessions from either top-down or bottomup (42 sessions). (There is a slight difference. (i) Pair-wise integration (ii) (ii) Neighborhood integration. because the base information for neighborhoods is the call graph. The end result is that neighborhoods are essentially the sandwiches that we slipped past in the previous section. we won’t have as many drivers.Software Testing 10CS842 bottom-up integration order. Dept. Soln. This is partially offset by the fact that the driver modules will be more complicated. The end result is that we have one integration test session for each edge in the call graph (40 for the SATM call graph). SJBIT 18 . why not use the actual code? At first. (ii)Neighborhood Integration We can let the mathematics carry us still further by borrowing the notion of a “neighborhood” from topology. this means all the immediate predecessor nodes and all the immediate successor nodes (notice that these correspond to the set of stubs and drivers of the node). and it avoids stub and driver development. Rather than develop stubs and/or drivers. of CSE.) What they share with sandwich integration is more significant: neighborhood integration testing has the fault isolation difficulties of “medium bang” integration. In a directed graph. (i)Pair-wise Integration The idea behind pair-wise integration is to eliminate the stub/driver development effort. The traditional model of software development is the Waterfall model. Functional decomposition can only be well done when the system is completely understood. and during this interval. on the other hand. Alternative Life Cycle Models Common to all of these alternatives is the shift away from the functional decomposition to an emphasis on composition. The result is a very long separation between requirements specification and a completed system. information produced in one of the development phases constitutes the basis for test case identification at that level. and that unit test cases are derived from the detailed design of the unit. Decomposition is a perfect fit both to the top-down progression of the waterfall model and to the bottom-up testing order. Two observations: there is a clear presumption of functional testing here. and there is an implied “bottom-up” testing order. of CSE. One of the major weaknesses of waterfall development is the over-reliance on this whole paradigm. Explain traditional view of testing levels alternative life cycle models Soln. Nothing controversial here: we certainly would hope that system test cases are somehow correlated with the requirements specification. (i) Waterfall Spin-offs (ii) Specification Based Models (iii) Rapid Prototyping Life Cycle (iv) Executable Specification (v) An Object-Oriented Life Cycle Model Dept. and maybe remove undesired portions. Composition. there is no opportunity for feedback from the customer.Software Testing 10CS842 5. which is drawn as a V to emphasize the basic levels of testing. then add to it gradually. and it promotes analysis to the near exclusion of synthesis. is closer the way people work: start with something known and understood. In this view. SJBIT 19 . Call Graph Based Integration One of the drawbacks of decomposition based integration is that the basis is the functional decomposition tree. We also know that we want to express system testing in terms of behavioral threads. We are in a position to enjoy the investment we made in the discussion of graph theory. it would be nice to have a similar capability for integration testing. Dept. If we use the call graph instead. of CSE. control is passed from the calling unit to the called unit. path based. When a unit executes. where some other path of source statements is traversed. Since the call graph is a directed graph. call graph based and path based interpretation with an example Soln. Lastly. Explain in detail. we focus on interactions among these units. We already know that the combination of structural and functional testing is highly desirable at the unit level. we also move in the direction of behavioral testing. Suppose that there is a call to another unit along such a path: at that point. why not use it the way we used program graphs? This leads us to two new approaches to integration testing: we’ll refer to them as pair-wise integration and neighborhood integration. we mitigate this deficiency. and then define the concepts that take you there. but first we need to motivate the definitions. some path of source statements is traversed. We do this here for path based integration testing.Software Testing 10CS842 6. SJBIT 20 . we revise our goal for integration testing: rather than test interfaces among separately developed and tested units. Path Based Integration Much of the progress in the development of mathematics comes from an elegant pattern: have a clear idea of where you want to go. If the customer’s PAN is not found. The bank customer accesses the SATM system with a plastic card encoded with a Personal Account Number (PAN). laying out functional and non-functional requirements. If the customer’s PAN matches the information in the customer account file. these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. 2. the customer’s name and account information. which is a key to an internal customer account file.e..Software Testing 10CS842 UNIT-5 System Testing. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. risks. the customer is prompted to enter his/her Personal Identification Number (PIN). of CSE. A software requirements specification (SRS) is a description of a software system to be developed. Interaction Testing: 1. When a bank customer arrives at an SATM station. screen 1 is displayed. Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects. containing. This is achieved and refined with detailed and continuous communications with the project team and customer till the completion of the software. If the PIN is correct (i. At screen 2. and the card is kept. With a neat diagram explain the transition probabilities for the SATM system Soln. Explain the basic concept for requirement specification Soln. the system presents screen 2 to the customer. matches the information in the customer account file). It should also provide a realistic basis for estimating product costs.To derive the requirements we need to have clear and thorough understanding of the products to be developed or being developed. the system Dept. SJBIT 21 . screen 4 is displayed. The software requirements specification document enlists enough and necessary requirements that are required for the project development. and may include a set of use cases that describe interactions the users will have with the software. among other things. and schedules. The use of "reverse" originates in its counterpart "forward proxy" since the reverse proxy sits closer to the web server and serves only a restricted set of websites. the system adds two pieces of information to the customer’s account file: the current date. the system displays screen 12. the system displays screen 13. and processes the deposit. All traffic coming from the Internet and with a destination of one of the neighborhood's web servers goes through the proxy server. Requests are forwarded to one or more proxy servers which handle the request. screen 4 is displayed. accepts the deposit envelope. If there is a problem with the deposit envelope slot.Software Testing 10CS842 displays screen 5. The response from the proxy server is returned as if it came directly from the origin server. the status of the Deposit Envelope slot is determined from a field in the Terminal Control File. and reconciles these with the beginning balance for that day from the customer account file. If no problem is known. and an increment to the number of ATM sessions. The system then displays screen 14. leaving the client no knowledge of the origin servers. Both of these (and other information) are processed by the Master ATM (centralized) system once per day. The customer selects the desired transaction from the options shown on screen 5. screen 3 is displayed. where the customer chooses the account to which the selected transaction will be applied. the system checks the local ATM file for any unposted transactions. There are several reasons for installing reverse proxy servers. and the count of deposits per month is incremented. If balance is requested. SJBIT 22 . Client Server Testing is a proxy server that appears to clients to be an ordinary server. Once the deposit amount has been entered. The customer has three chances to get the PIN correct. Write a short note on client server testing Soln. If deposit is requested. On entry to screen 5. The deposit amount is entered as an unposted amount in the local ATM file. 3. the system displays screen 7 to get the transaction amount. and the card is kept. Dept. Screen 14 is then displayed. then the system immediately displays screen 6. otherwise. of CSE.[3] Reverse proxies are installed in the neighborhood of one or more web servers. after three failures. only two have no duration — ports and data. Define the below terms: (i) Threads (ii) MM-path (iii) Data (iv) Actions (v) Ports Soln. (i) Threads: A unit thread is a path in the program graph of a unit (ii) MM-path : An MM-Path is a path in the MM-Path graph of a set of units. The slight distinction between ports and port devices is sometimes helpful to testers. Static Interactions in a Single Processor Of the five basis constructs. SJBIT 23 . Entity/relationship models are the most common choice at the highest level. the focus is on the information used and created by the system. We sometimes get a little more precise. and these can be either data or port events. and thereby simplify our discussion. We describe data in terms of variables. data stores. Technically. or even inconsistent data. of CSE. and some form of a regular expression (iv) Actions : Action-centered modeling is by far the most common requirements specification form. We can be very specific if we borrow Dept. and these are important to testers. Port devices interact in physical ways. such as space and power consumption. a port is the point at which an I/O device is attached to a system. (v) Ports: Every system has ports (and port devices). fields. and files. Since ports are physical devices. and of maintaining the integrity of a database. records. Given a system defined in terms of atomic system functions. Data items interact in logical ways (as opposed to physical). and speak of incompatible. (iii) Data: When a system is described in terms of its data. data structures. In an informal way. Soln. Explain single-processor static interaction and single-processor dynamic interaction in system testing. the ASF Graph of the system is the directed graph in which nodes are atomic system functions and edges represent sequential flow. This is a historical outgrowth of the action-centered nature of imperative programming languages. Actions have inputs and outputs.Software Testing 10CS842 4. we often speak of corrupt data. network ports. as in serial and parallel ports. these are the sources and destinations of system level inputs and outputs (port events). 5. and telephone ports. we can view them as separate processors. but this is usually not important to testers. misleading. contradictories. We also must shift from the strictly declarative relationships in the Square of Opposition to a more imperative view. SJBIT 24 . q. In the following definitions. contraries. It’s possible to simply treat threads as a primitive concept which needs no formal definition Finding Threads Dept. which is shown in . testing threads are important in software testing Soln. we might take p and q to be: p: AccountBalance = $10. Dynamic Interactions in a Single Processor Moving to the dynamic quadrants means we consider the implications of time for interactions. because each of these is a bidirectional relationship. r.00 Propositions p and q are • contraries if they cannot both be true • sub-contraries if they cannot both be false • contradictories if they exactly one is true • q is a sub-altern of p if the truth of p guarantees the truth of q These relationships are known to logicians as the Square of Opposition.00 q: Sales < $1800. all pertain to 3-connected data. The other three relationships. Explain and discuss Thread and finding thread. Even the data-data interactions exhibit forms of n-connectedness. and s are all propositions. let p and q be propositions about data items. where p. and sub-contraries. this means we must expand from the data only interactions to interactions among data. The notion of nconnectedness in a directed graph serves perfectly. of CSE.Software Testing 10CS842 some terms from Aristotle. Data that are logically independent are 0-connected. in fact some published definitions are counter-productive. and threads. events. Threads are hard to define. Among other things. As examples. 6. and sub-alternates are 2-connected. and/or wrong. and at any point. form the starting point of a useful taxonomy of interaction. or resort to the system level analogs of functional testing. We describe functional threads here in terms of coverage metrics that are derived from three of the basis concepts (events. Recall that when functional test cases are identified. time and position. We skipped the eject card event because it isn’t really part of the PIN Entry component. we first list the port events shown on the state transitions. There are also time dependent interactions. We can’t actually enter an entire PIN. SJBIT 25 . 7. interaction. but what if no behavioral model exists for a system to be tested? The testing craftsperson has two choices: develop a behavioral model. we enter digits. We will Dept. for example. we might hit the cancel key. There are interactions that are completely independent of time. of CSE. ports. they appear in Table 1.Software Testing 10CS842 To start the thread identification process. as when something is a prerequisite for something else. A Taxonomy of Interactions The two aspects of location. composition and determinism in software testing. Port Input Events Port Output Events Legitimate Card Display screen 1 Wrong Card Display screen 2 Correct PIN Display screen 3 Incorrect PIN Display screen 4 Table 1 Events in the PIN Entry Finite State Machine Notice that Correct PIN and Incorrect PIN are really compound port input events. two data items that interact exhibit their interaction regardless of time. and data). Soln. we use information from the input and output spaces as well as the function itself. Functional Strategies for Thread Testing The finite state machine based approaches to thread identification are clearly useful. Explain taxonomy of interactions. We can refine the static/dynamic dichotomy with the distinction between single and multiple processors. of CSE. it may not detect all violations).Software Testing 10CS842 refer to time-independent interactions as static. These two considerations yield a two dimensional plane with four basic types of interactions: • static interactions in a Single processor • static interactions in multiple processors • dynamic interactions in a single processor • dynamic interactions in multiple processors UNIT-6 Process Framework: 1. optimistic inaccuracy: we may accept some programs that do not possess the property (i..e. and time dependent interactions as dynamic. Soln. – testing pessimistic inaccuracy: it is not guaranteed to accept a program even if the program does possess the property being analyzed – automated program analysis techniques simplified properties: reduce the degree of freedom for simplifying the property to check Dept. SJBIT 26 . Explain verification trade-off dimensions. Software Testing 10CS842 2. Briefly discuss the dependability properties in process framework. of CSE. SJBIT 27 . Soln. validation and verification and their difference Soln. Different teams for development and quality? – separate development and quality teams is common in large organizations – indistinguishable roles is postulated by some methodologies (extreme programming) Different roles for development and quality? – test designer is a specific role in many organizations – mobility of people and roles by rotating engineers over development and testing tasks among different projects is a possible option 4. Explain in detail. Why organizational factors are needed in process framework. Validation: does the software system meets the user's real needs? are we building the right software? Dept. Soln. Correctness: A program is correct if it is consistent with its specification • seldom practical for non-trivial systems Reliability: likelihood of correct function for some ``unit'' of behavior • relative to a specification and usage profile • statistical approximation to correctness (100% reliable = correct) Safety: preventing hazards Robustness: acceptable (degraded) behavior under extreme conditions 3. Partition and explain in detail any of them. if a user presses a request button at floor i. of CSE. producing faults in software. Redundancy d. Sensitivity c. an available elevator must arrive at floor i soon Verifiable spec: . Degrees of freedom b. The sensitivity principle states that it is better to fail every time than sometimes. Dept. if a user presses a request button at floor i. Degrees of freedom optimistic inaccuracy: we may accept some programs that do not possess the property (i. Restriction e. Soln. c. SJBIT 28 . Redundancy: making intentions explicit.. Faults may lead to failures. 5..e.Software Testing 10CS842 Verification: does the software system meets the requirements specifications? are we building the software right? Verification or validation depends on the specification Unverifiable (but validatable) spec: . it may not detect all violations). Explain a. a. but faulty software may not fail on every execution... pessimistic inaccuracy: it is not guaranteed to accept a program even if the program does possess the property being analyzed simplified properties: reduce the degree of freedom for simplifying the property to check b.. Sensitivity: better to fail every time than sometimes. an available elevator must arrive at floor i within 30 seconds. Human developers make errors. Dividing a complex problem into subproblems to be attacked and solved independently is probably the most common human problem-solving strategy. e. and it is possible to check them for consistency. Partition : divide and conquer Partition. Test Execution: 1. SJBIT 29 . Define below terms with respect to fault based-testing: i) Original program ii) Program location. more restrictive class of programs.Software Testing 10CS842 Redundancy is the opposite of independence.. etc. i) Original program: The program unit (e." is a general engineering principle. Restriction: making the problem easier When there are no acceptably cheap and effective ways to check a property. often also known as "divide and conquer. Software engineering in particular applies this principle in many different forms and at almost all development levels. Soln. sometimes one can change the problem by checking a different. If one part of a software artifact (program. Dept.g. C function or Java class) to be tested. design document.) constrains the content of another. from early requirements specifications to code and maintenance. more restrictive property or by limiting the check to a smaller. Analysis and testing are no exception: the partition principle is widely used and exploited UNIT-7 Fault-Based Testing. d. iii) Alternate expression iv) Alternate program. of CSE. then they are not entirely independent. . iv) Alternate program: Source code text that can be legally substituted for the text at a program location. A substitution is legal if the resulting program is syntactically correct (i.. and each variant program is called a mutant.g. Mutant A program that differs from the original program for one syntactic element (e. Soln. of CSE. Mutation analysis is the most common form of software fault-based testing. iii) Alternate expression: Source code text that can be legally substituted for the text at a program location.e.. Mutation operator A rule for producing a mutant program by syntactically modifying the original program. by making a small change to the program under test following a pattern in the fault model. Distinguished mutant A mutant that can be distinguished for the original program by executing at least one test case. Mutation Analysis: Terminology Original program under test The program or procedure (function) to be tested. it compiles without errors).e.Software Testing 10CS842 ii) Program location: A region in the source code. The precise definition is defined relative to the syntax of a particular programming language. a condition. that is. A substitution is legal if the resulting program is syntactically correct (i. a statement. SJBIT 30 . Explain mutation analysis software fault based testing. a label). Equivalent mutant A mutant that cannot be distinguished from the original program. Variants are created by "seeding" faults. Dept. a variable. A fault model is used to produce hypothetical faulty programs by creating variants of the program under test. The patterns for changing program text are called mutation operators. 2. Typical locations are statements. and procedure calls. it compiles without errors). arithmetic and Boolean expressions. List the Fault-based adequacy criterias. Explain hardware fault-based testing. like replacing one variable reference by another in an expression. the seeded faults are small syntactic changes. Explain overview of assumption in fault based testing Soln. of CSE. In practice. mutation analysis consists of the following steps: Select mutation operators If we are interested in specific classes of faults. Soln. or to estimate the number of faults in a program. The basic concept of hardware fault-based testing is to select test cases that would distinguish the program under test from alternative programs that contain hypothetical faults. This is usually approached by modifying the program under test to actually produce the hypothetical faulty programs. Generate mutants Mutants are generated mechanically by applying mutation operators to the original program. Fault-Based Adequacy Criteria Given a program and a test suite T. or for selecting test cases to augment a test suite. A mutant is killed when it can be distinguished from the original program. we may select a set of mutation operators relevant to those faults. Soln. 4. or changing a comparison Dept. 5. Assumptions in Fault-Based Testing The effectiveness of fault-based testing depends on the quality of the fault model and on some basic assumptions about the relation of the seeded faults to faults that might actually be present. Distinguish mutants Execute the original program and each generated mutant with the test cases in T. as an element of a test adequacy criterion). SJBIT 31 . Fault seeding can be used to evaluate the thoroughness of a test suite (that is.Software Testing 10CS842 3. though. A fault model is used to produce hypothetical faulty programs by creating variants of the program under test.Software Testing 10CS842 from < to <=. This is known as the coupling effect. Variants are created by "seeding" faults. a variable. This is known as the competent programmer hypothesis. SJBIT 32 . by making a small change to the program under test following a pattern in the fault model.g. 6. corrected program by only a small textual change. Mutant A program that differs from the original program for one syntactic element (e. Explain in detail mutation analysis and variations on mutation testing Soln. This may not invalidate fault-based testing with a simpler fault model. a condition. then we need merely distinguish the program from all such small variants (by selecting test cases for which either the original or the variant program fails) to ensure detection of all such faults. and each variant program is called a mutant. We may hypothesize that these are representative of faults actually present in the program. If so. Equivalent mutant A mutant that cannot be distinguished from the original program. Sometimes. Put another way. Mutation analysis is the most common form of software fault-based testing. a statement. and others that involve deeper errors of logic may nonetheless be manifest in simple textual differences. Distinguished mutant A mutant that can be distinguished for the original program by executing at least one test case. Dept. The patterns for changing program text are called mutation operators. an assumption that the program under test is "close to" (in the sense of textual difference) a correct program. Original program under test The program or procedure (function) to be tested. that is. if the program under test has an actual fault. provided test cases sufficient for detecting the simpler faults are sufficient also for detecting the more complex fault. a label). Some program faults are indeed simple typographical errors.. of CSE. an error of logic will result in much more complex differences in program text. we may hypothesize that it differs from another. JUnit: Specific oracle (“assert”) coded by hand in each test case – Typical approach: “comparison-based” oracle with predicted output value – Not the only approach! Scaffolding: Code produced to support development activities (especially testing) – Not part of the “product” as seen by the end user – May be temporary (like scaffolding in construction of buildings Includes – Test harnesses. or fail? – No use running 10.g. scaffolding.. automatically generated test suites.000 test cases automatically if the results must be checked by hand! Range of specific to general. selfchecks on oracles. SJBIT 33 .Software Testing 10CS842 Mutation operator A rule for producing a mutant program by syntactically modifying the original program. again – ex. Explain the terms oracle . structural invariants of data structures Dept. 7. Soln. drivers. Oracle : Did this test case succeed. but often only a partial check – e. and stubs Self checks on oracles: An oracle can also be written as self-checks – Often possible to judge correctness without predicting results Advantages and limits: Usable with large. of CSE. Walkthrough: It is not a formal process/review. etc. Write a short note on: a) Quality and process. A framework for selecting and arranging activities considering interactions and trade-offs Follows the overall software process in which it is embedded Example: waterfall software process ––> “V model”: unit testing starts with implementation and finishes before integration. of CSE.Software Testing 10CS842 UNIT-8 Planning and Monitoring the Process. To examine and discuss the validity of the proposed solutions 2. Quality process: Set of activities and responsibilities focused primarily on ensuring adequate dependability concerned with project schedule or with product usability. b) Test planning. It is led by the authors. e) Test design specification document Soln. who are not used to or cannot easily understand software development process. Quality and process. To explain or do the knowledge transfer and evaluate the contents of the document. Author guide the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback. Write short note on walk through and inspection Soln. a. d) Organizing documents. Inspection: To present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation. SJBIT 34 . Documenting Analysis and Test: 1. c) Risk planning. Example: XP and agile Dept. To achieve a common understanding and to gather feedback. Is especially useful for higher level documents like requirement specification. Useful for the people if they are not from the software discipline. SJBIT 35 . but they can be assessed. checklists. and monitored • • Generic management risk – personnel – technology – schedule Quality risk – development – execution – requirements d. What quality activities will be carried out? What are the dependencies among the quality activities and between quality and other development activities? What resources are needed and how will they be allocated? How will both the process and the product be monitored? c. • • Planning documents – describe the organization of the quality process – include organization strategies and project plans Specification documents – – describe test suites and test cases test design specifications. controlled. test case specification.Software Testing 10CS842 methods ––> emphasis on unit testing and rapid iteration for acceptance testing by customers b. analysis procedure specifications • Reporting documents Dept. Risks cannot be eliminated. Organizing documents. Risk planning. of CSE. Test planning. and anticipated changes. Test and analysis • Lessons of past experience Dept. guiding further development and preparing for maintenance. a. Specification of individual test cases includes purpose. Quality Quality process: Set of activities and responsibilities focused primarily on ensuring adequate dependability concerned with project schedule or with product usability b. Test suite design must include all the information needed for initial selection of test cases and maintenance of the test suite over time. and to make objective judgments of progress Counter wishful thinking and denial c. usage. including rationale and anticipated evolution. 3. Test design specification document Design documentation for test suites and test cases serve essentially the same purpose as other software design documentation.Software Testing 10CS842 – Details and summary of analysis and test results e. Process A good process must have visibility: Ability to monitor each step. Write short on. SJBIT 36 . of CSE. a) Quality b) Process c) Test and analysis d) Risk planning e) Monitoring the process f) improving the process Soln. and monitored • Generic management risk • – personnel – technology – schedule Quality risk – development – execution – requirements e.Software Testing 10CS842 – • • an organizational asset built and refined over time Body of explicit knowledge – more valuable than islands of individual competence – amenable to improvement – reduces vulnerability to organizational change Essential for – avoiding recurring errors – maintaining consistency of the process – increasing development efficiency d. SJBIT 37 . of CSE. Risk planning • Risks cannot be eliminated. but they can be assessed. controlled. unambiguous milestones and criteria A process is visible to the extent that it can be effectively monitored Dept. Monitoring the process • Identify deviations from the quality plan as early as possible and take corrective action • • Depends on a plan that is – realistic – well organized – sufficiently detailed with clear. Explain the features of test design specification documents. What are processed quality and analysis strategies in a brief note? Soln. system. improving the process Monitoring and improvement within a project or across multiple projects: Orthogonal Defect Classification (ODC) &Root Cause Analysis (RCA) 4. Soln.Software Testing 10CS842 f. performance suites (organized by objectives) include all the information needed for • initial selection of test cases • maintenance of the test suite over time identify features to be verified (cross-reference to specification or design document – include description of testing procedure and pass/fail criteria (references to scaffolding and oracles) – includes (logically) a list of test cases 5. • • Same purpose as other software design documentation: – Guiding further development – Preparing for maintenance Test design specification documents: – describe complete test suites – may be divided into – – • unit. structural. acceptance suites (organize by granularity) • functional. • • Quality process: Set of activities and responsibilities – focused primarily on ensuring adequate dependability – concerned with project schedule or with product usability A framework for Dept. of CSE. SJBIT 38 . integration. . SJBIT 39 . loss of key individuals) Essential for – avoiding recurring errors – maintaining consistency of the process – increasing development efficiency Dept.Software Testing • – selecting and arranging activities – considering interactions and trade-offs 10CS842 Follows the overall software process in which it is embedded – Example: waterfall software process ––> “V model”: unit testing starts with implementation and finishes before integration – Example: XP and agile methods ––> emphasis on unit testing and rapid iteration for acceptance testing by customers Test and Analysis Strategy • Lessons of past experience – • • an organizational asset built and refined over time Body of explicit knowledge – more valuable than islands of individual competence – amenable to improvement – reduces vulnerability to organizational change (e. of CSE.g.
Report "Cse Viii Software Testing [10cs842] Solution"