MLM-III

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Typographical defects. Initialization defects. Dataflow defects. Data defects. Module interface defects. Code document defects. External hardware and software interface defects. Figure : a code example with defects. Algorithmic and processing defects. Control ,logic, and sequence defects. The tester’s role in a Software Development Organization.Cooperating with code developers.Need the support of management.TMM levels.8.Developer / Tester support for developing a defect repository.Figure: The defect repository , and support for TMM maturity level. PART-A1. Define Test case. What are the information it contains? (NOV/DEC 2012) A test case in a practical sense is attest related item which contains the followinginformation. A set of test inputs. These are data items received from an external source by thecode under test. The external source can be hardware, software, or human. Execution conditions. These are conditions required for running the test, forexample, a certain state of a database, or a configuration of a hardware device. Expected outputs. These are the specified results to be produced by the codeunder test.2. List the sources of Defects or Origins of defects Or list the classification ofdefect.(MAY/JUNE 2009) Education Communication Oversight Transcription Process3. Differentiate between verification and validation?( NOV/DEC 2009)Verification Validation1. Verification is the process of 1.Verification is the process of evaluatingevaluating software system or component software system or component during 201

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERINGto determine whether the products of a or at the end of the , the developmentgiven development phase satisfy the phase satisfy the conditions imposed atconditions imposed at the start of that the start of that phase.phase.2. Verification is usually associated with 2. Verification is usually associated withactivities such as inspections and reviews Traditional execution _based testing, i.e.,of the s/w deliverables. Exercising the code with testcases.4. Define Software process.(MAY/JUNE 2012)Process, in the software engineering domain, is the set of methods, practices,standards, documents, activities, policies, and procedures that software engineers use todevelop and maintain a software system and its associated artifacts, such as project andtest plans, design documents, code and manuals.5. List the members of the critical groups in a testing process (NOV/DEC 2008) Manager Developer/Tester User/Client6. Differentiate between testing and debugging. (NOV/DEC 2008)Testing Debugging1. Testing as a dual purpose 1. Debugging or fault localizationprocess quality is the process of Reveal defects  Locating the fault or defect And to evaluate  Repairing the code, andattributes  Retesting the code.7. Define process in the context of software quality. (NOV/DEC 2009) Process, in the software engineering domain, is a set of methods, practices,Standards, documents, activities, polices, and procedures that software engineers use todevelop and maintain a software system and its associated artifacts, such as project andtest plans, design documents, code, and manuals 202

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING8. Distinguish between fault and failure. (MAY/JUNE 2009)Fault FailureA fault is introduced into the software as A failure is the inability of a software orthe result of an error. It is an anomaly in component to perform its requiredthe software that may cause nit to behave functions within specified performanceincorrectly, and not according to its requirements.specification.9. Define software Testing.Testing can be described as a process used for revealing defects in software, and forestablishing that the software has attained a specified degree of quality with respect toselected attributes.10. List the levels of TMM. The testing maturity model or TMM contains five levels. They are Level1: Initial Level2: Phase definition Level3: Integration Level4: Management and Measurement Level5: Optimization /Defect prevention and Quality Control11. Define Error. An error is mistake or misconception or misunderstanding on the part of asoftware developer.12. Define Faults. A fault (defect) is introduced into the software as the result of an error. It is ananomaly in the software that may cause it to behave incorrectly, and not according to itsspecification.13. List the Quality Attributes. Correctness Reliability Usability Integrity Portability Maintainability Interoperability14. Define Software Quality. Quality relates to the degree to which a system, system component, or processmeetsCustomer or user needs, or expectations.15. Explain the work of SQA group. Testers to develop quality related policies and quality assurance plans foreach project. The group is also involved in measurement collection and analysis, record 203

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERINGkeeping, and Reporting. The SQA team members participate in reviews and audits,record and track Problems, and verify that corrections have been made.16.Define Failures. A failure is the inability of a software or component to perform its requiredfunctions within specified performance requirements.17. Define Debugging. Debugging, or fault localization is the process of Locating the fault or defect. Repairing the codes. Retesting the code18. Define Quality. Two concise definitions for quality. Quality relates to the degree to which a system, system component, or processmeets specified requirements. Quality relates to the degree to which a system, system component, or processmeets customer or user needs, or expectations.19. Define Test Bed. A test bed is an environment that contains all the hardware and software needed totest a software component or a software system.20. Define Precondition. A precondition is a condition that must be true in order for a software componentto operate properly. Eg; number_of_coins > =0 PART- B1.Explain the Eleven Software testing principles in detail. (NOV/DEC 2012) A principle can be defined as: 1. a general or fundamental, law, doctrine, or assumption; 2. a rule or code of conduct; 3. the laws or facts of nature underlying the working of an artificial device. Principle 1. Testing is the process of exercising a software component using aselected set of test cases, with the intent of (i) revealing defects, and (ii) evaluatingquality. Principle 2. When the test objective is to detect defects, then a good test case isone that has a high probability of revealing a yet undetected defect(s). Principle 3. Test results should be inspected meticulously. Principle 4. A test case must contain the expected output or result. Principle 5. Test cases should be developed for both valid and invalid inputconditions. 204

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Principle 6. The probability of the existence of additional defects in a software component is proportional to the number of defects already detected in thatcomponent. Principle 7. Testing should be carried out by a group that is independent of the development group. Principle 8. Tests must be repeatable and reusable. Principle 9. Testing should be planned. Principle 10. Testing activities should be integrated into the software life cycle. Principle 11. Testing is a creative and challenging task2.Explain the origin of defects in detail. (NOV/DEC 2012) Defects have detrimental effects on software users, and software engineers workvery hard to produce high-quality software with a low number of defects. But even underthe best of development circumstances errors are made, resulting in defects being injectedin the software during the phases of the software life cycle.Origin of Defects 1. Education 2.Communication 3.Oversight 4. Transcription 5. Process They use the hypotheses to: design test cases; design test procedures; assemble test sets; select the testing levels (unit, integration, etc.)appropriate for the tests; evaluate the results of the tests.A successful testing experiment will prove the hypothesis is true—that is, thehypothesized defect was present. Then the software can be repaired (treated).A veryuseful concept related to this discussion of defects, testing, and diagnosis is that of a faultmodel.A fault (defect) model can be described as a link between the error made (e.g., a missingrequirement, a misunderstood design element, a typographical error), and the fault/defectin the software. 205

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING3.Explain the Developer/Tester support for Developing a Defect Repository.(NOV/DEC 2009) It is important if you are a member of a test organization to illustrate tomanagement and your colleagues the benefits of developing a defect repository to storedefect information. As software engineers and test specialists we should follow the examples ofengineers in other disciplines who have realized the usefulness of defect data. Arequirement for repository development should be a part of testing and/or debuggingpolicy statements. You begin with development of a defect classification scheme and then initiatethe collection defect data from organizational projects. 206

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING4. Explain the concepts of defects with the coin problem. (NOV/DEC 2012) A more formally stated set of preconditions and post conditions would be helpfulhere, and would address some of the problems with the specification. These are alsouseful for designing black box tests. A precondition is a condition that must be true in order for a software componentto operate properly. In this case a useful precondition would be one that states forexample:number_of_coins __0 A post condition is a condition that must be true when a software componentcompletes its operation properly. A useful post condition would be: number_of_dollars, number_of_cents __ 0. Control, logic, and sequencing defects Algorithmic, and processing defects. Data Flow defects. Data Defects. External Hardware, Software Interface Defects. Code Documentation Defects. 207

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING5.Explain the tester's role in Software development Organization. (NOV/DEC 2009) Tester‗s job is to reveal defects, find weak points, inconsistent behavior, andcircumstances where the software does not work as expected. Tester requires extensive programming experience in order to understand howcode is constructed, and where, and what kind of, defects are likely to occur. Tester is to work with the developers to produce high-quality software that meetsthe customers‗ requirements For example, an embedded real-time system needs to have a lowerdeveloper/tester ratio (for example, 2/1) than a simple data base application (4/1 may besuitable). Testers also need to work with designers to plan for integration and unit test. In addition, test managers will need to cooperate with project managers in order todevelop reasonable test plans, and with upper management to provide input for thedevelopment and maintenance of organizational testing standards, polices, and goals. Testers need to cooperate with software quality assurance staff and softwareengineering process group members. Low-defect software also has the benefit of reducing costs such as support calls,repairs to operational software, and ill will which may escalate into legal action due tocustomer dissatisfaction. Management must support them in their efforts and recognize their contributionsto the organization. 208

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING UNIT II TEST CASE DESIGNTest case Design Strategies – Using Black Bod Approach to Test Case Design – RandomTesting –Requirements based testing – Boundary Value Analysis – Equivalence ClassPartitioning – Statebased testing – Cause-effect graphing – Compatibility testing – userdocumentation testing– domain testing – Using White Box Approach to Test design –Test Adequacy Criteria – static testing vs. structural testing – code functional testing –Coverage and Control Flow Graphs – Covering Code Logic – Paths – code complexitytesting – Evaluating Test Adequacy Criteria. KEY NOTES1.Smart Tester. Reveal defects Evaluate quality Finite no .of test case2.Test case design strategies. Positive consequences Two strategies White box (clear or glass box) Black box(Functional or specification) Figure: The two basic testing strategies.3.Types of black box testing Random testing Randomly select the input. Three conditions. Equivalence class partitioning Adv. of Equivalence class partitioning List of conditions. Figure: A specification of a square root function Example of equivalence class reporting table Boundary value analysis List the conditions Figure: Boundaries of on Equivalence partition Example of Boundary value analysis.4.Other Black box test design Approaches Cause and Effect graphing Steps of test cases with a Cause and Effect graph Figure: Samples of Cause and Effect graph notations. The input conditions The output conditions 209

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING The rules or relationships. Figure : Cause and Effect graph for the character search example. Table: Decision table for character search example.5.State Transition testing State Finite state machine Figure: Simple state transition graph Table: A state table for the machine Error Guessing Past experience6.Black Box Testing and COTS (Commercial Off-the-shelf) components. Usage Profiles COTS Certification7.Types of white box testing Coverage and control flow graph Three basic primes Sequential Condition Iteration Coverage code logic Figure: Code sample with branch and loop. Figure: A control flow graph representation for the code. Table: A test case for the code ,that satisfies the decision coverage criterion. Table: Test cases for simple decision coverage Table: Test cases for condition coverage Table: Test cases for decision condition coverage. Path Testing Path cyclomatic complexity formula.8.Additional white box test design approaches. Dataflow and white box test design Variable. Figure: sample code with data flow information Loop Testing Mutation Testing The component programmer hypothesis The copying effect9.Evaluating Test adequacy Criteria 210

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Axioms –Set of assumptions Applicability Property Non exhaustive applicability property Monotonicity Property Inadequate Empty set Antientensionality Property General multiple change Property Anti decomposition Property Renaming Property Complexity Property Statement Coverage Property PART-A1. Define Smart Tester. (NOV/DEC 2009) Software must be tested before it is delivered to users. It is responsibility of thetesters toDesign tests that(i) reveal defects (ii) can be used to evaluate software performance,usability and reliability. To achieve these goals, tester must select a finite no. of testcases (i/p, o/p, & conditions).2. Define Random testing.(MAY/JUNE 2008) Each software system or module has an input domain from which test input datais selected. If a tester randomly selects input from the domain, this is called Randomtesting.3. Define Error Guessing.(MAY/JUNE 2009) The tester/developer is sometimes able to make an educated ―guess‘ as to whichtype of defects may be present and design test cases to reveal them. Error Guessing is anad-hoc approach to test design in most cases.4. List the methods of White box testing.(NOV/DEC 2009)  Statement testing  Branch testing  Path testing  Data flow testing  Mutation testing  Loop testing5. Define State (NOV/DEC 2012) A state is an internal configuration of a system or component. It is defined interms of values assumed at a particular time for the variables that characterize the systemor component. 211

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING6. What are the knowledge sources for Black box testing?(MAY/JUNE 2009)  Requirements  Document specification  Domain knowledge  Defect analysis data7. Define Finite-State machine. (NOV/DEC 2011) A finite-state machine is an abstract machine that can be represented by a stategraph having a finite number of states and a finite number of transitions between states.8. Compare black box and white box testing. (MAY/JUNE 2010)Black box testing White box TestingBlack box testing , the tester is no The White box approach focuses on theKnowledge of its inner structure(i.e. how inner structure of the software to beit works)The tester only has knowledge of tested.what it does(Focus only input & output)Black box approach is usually applied White box approach is usually appliedlarge size piece of software. small size piece of software.Black box testing sometimes called White box sometimes called clear or glassfunctional or specification testing. box testing.9. Define path. (NOV/DEC 2012)A path is a sequence of control flow nodes usually beginning from the entry nodeof a graph through to the exit node.10. Define test set. (MAY/JUNE 2010)A test set T is said to be mutation adequate for program p provided that for every inequivalent mutant pi of p there is an element t in T such that pi[t] is not equal to p[t].11. What is the goal of smart tester?The goal of the smart tester is to understand the functionality, input/outputdomain, and the environment of use for the code being tested.12. What are the knowledge sources for White box testing? High level design Detailed design Control flow graphs Cyclomatic complexity13. What is Test data set?A test data set is statement, or branch, adequate if a test set T for program Pcauses all the statements, or branches, to be executed respectively.14. What are the errors uncovered by black box testing? Incorrect or missing functions Interface errors Errors in data structures 212

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING  Performance errors  Initialization or termination error15. What are the basic primes for all structured program.  Sequential ( e.g., Assignment statements)  Condition (e.g., if/then/else statements)  Iteration (e.g., while, for loops)16. Write the application scope of adequacy criteria?  Helping testers to select properties of a program to focus on during test.  Helping testers to select a test data set for a program based on the selected properties.  Supporting testers with the development of quantitative objectives for testing  Indicating to testers whether or not testing can be stopped for that program.17. Define usage profiles and Certification. Usage profiles are characterizations of the population of intended uses of thesoftware in its intended environment. Certification refers to third party assurance that aproduct, process, or service meets a specific set of requirements.18. Define Equivalence class partitioning. If a tester is viewing the software-under-test as a black box with well definedinputs and outputs, a good approach to selecting test inputs is to use a method calledEquivalence class partitioning.19. List the Knowledge Sources & Methods of black box and white box testing.Test Strategy Knowledge Sources MethodsBlack box 1. Requirements 1. Equivalence class partitioning (ECP) document 2. Boundary value analysis (BVA) 2. Specifications 3. State Transition testing.(STT) 3. Domain Knowledge 4. Cause and Effect Graphing. 4. Defect analysis data 5. Error guessingWhite box 1. High level design 1. Statement testing 2. Detailed design 2. Branch testing 3. Control flow graphs 3. Path testing 4. Cyclomatic complexity 4. Data flow testing 5. Mutation testing 6. Loop testing 213

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING 20. Define COTS Components. The reusable component may come from a code reuse library within their org or, as is most likely, from an outside vendor who specializes in the development of specific types of software components. Components produced by vendor org are known as commercial off-the shelf, or COTS, components. PART-B 1.Explain the test factors that must be followed to design a customized test strategy. (NOV/DEC 2009) A smart tester who wants to maximize use of time and resources knows that she needs to develop what we will call effective test cases for execution-based testing. For example, if test cases are effective there is greater probability of detecting defects more efficient use of organizational resources a higher probability for test reuse closer adherence to testing and project schedules and budgets the possibility for delivery of a higher-quality software product Two types of testing are used: 1.Black box 2.White box Using the black box approach, a tester considers the software-under test to be an opaque box. The size of the software-under-test using this approach can vary from a simple module, member function, or object cluster to a subsystem or a complete Software system. The tester provides the specified inputs to the software-under-test, runs the test and then determines if the outputs produced are equivalent to those in the specification. This approach is especially useful for revealing requirements and specification defects. The white box approach focuses on the inner structure of the software to be tested. The code, or a suitable pseudo code like representation must be available. The tester selects test cases to exercise specific internal structural elements to determine if they are working properly. The smart tester knows that to achieve the goal of providing users with low-defect, high- quality software, both of these strategies should be used to design test cases. The tester will also have an effective set of reusable test cases for regression testing (re- test after changes), and for testing new releases of the software. There is a great deal of material to introduce to the reader relating to both of these strategies. 214

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING2.Explain Equivalence Class Partitioning in detail ( APRIL/MAY 2013) If a tester is viewing the software-under-test as a black box with well- definedinputs and outputs, a good approach to selecting test inputs is to use a method calledequivalence class partitioning. Based on this discussion of equivalence class partitioning we can say that thepartitioning of the input domain for the software-under-test using this technique has thefollowing advantages:1. It eliminates the need for exhaustive testing, which is not feasible.2. It guides a tester in selecting a subset of test inputs with a high probability of detectinga defect.3. It allows a tester to cover a larger domain of inputs/outputs with a smaller subsetselected from an equivalence class. There are several important points related to equivalence class partitioning thatshould be made to complete this discussion.1. The tester must consider both valid and invalid equivalence classes. Invalid classesrepresent erroneous or unexpected inputs.2. Equivalence classes may also be selected for output conditions.3. The derivation of input or outputs equivalence classes is a heuristic process. Theconditions that are described in the following paragraphs only give the tester guidelinesfor identifying the partitions. There are no hard and fast rules. Given the same set ofconditions, individual testers may make different choices of equivalence classes. As atester gains experience he is more able to select equivalence classes with confidence.4. In some cases it is difficult for the tester to identify equivalence classes. Theconditions/boundaries that help to define classes may be absent, or obscure, or there mayseem to be a very large or very small number of equivalence classes for the problemdomain. The specification describes for the tester conditions relevant to the Function square_root message (x:real) when x >_0.0 reply (y:real) where y >_0.0 & approximately (y*y,x) otherwise reply exception imaginary_square_root end functionFor example, input equivalence classes for this module are the following:EC1. The input variable x is real, valid.EC2. The input variable x is not real, invalid.EC3. The value of x is greater than 0.0, valid. EC4. The value of x is less than 0.0, invalid. 215

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING3.Explain the Boundary Value Analysis (NOV/DEC 2012) Equivalence class partitioning gives the tester a useful tool with which to developblack box based-test cases for the software-under-test. The method requires that a tester has access to a specification of input/outputbehavior for the target software. 1. If an input condition for the software-under-test is specified as a range ofvalues, develop valid test cases for the ends of the range, and invalid test cases forpossibilities just above and below the ends of the range. 2. If an input condition for the software-under-test is specified as a number ofvalues, develop valid test cases for the minimum and maximum numbers as well asinvalid test cases that include one lesser and one greater than the maximum andminimum. 3. If the input or output of the software-under-test is an ordered set, such as a tableor a linear list, develop tests that focus on the first and last elements of the set. It isimportant for the tester to keep in mind that equivalence class partitioning and boundaryvalue analysis apply to testing both inputs and outputs of the software-under-test, and,most importantly, conditions are not combined for equivalence class partitioning orboundary value analysis.First we consider condition 1, the requirement for alphanumeric characters. This is a―must be‖ condition. We derive two equivalence classes. EC1. Part name is alphanumeric, valid. EC2. Part name is not alphanumeric, invalid.Then we treat condition 2, the range of allowed characters 3-15. EC3. The widget identifier has between 3 and 15 characters, valid. EC4. The widget identifier has less than 3 characters, invalid. EC5. The widget identifier has greater than 15 characters, invalid.Finally we treat the ―must be‖ case for the first two characters. EC6. The first 2characters are letters, valid. EC7. The first 2 characters are not letters, invalid.For our example module the values for the bounds groups are: BLB—2 BUB—14 LB—3 UB—15 ALB—4 AUB—16 216

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING 4.Explain the Black box testing and Commercial off-the-Shelf(COTS) Components in detail (APRIL/MAY 2009) As software development evolves into an engineering discipline, the reuse of software components will play an increasingly important role. The reusable component may come from a code reuse library within their organization or, as is most likely, from an outside vendor who specializes in the development of specific types of software components Using COTS components can save time and money. However, the COTS component must be evaluated before becoming a part of a developing system. In addition, its suitability for the application must be determined, and any unwanted functionality must be identified and addressed by the developers. If the COTS component is small in size, and a specification of its inputs/outputs and functionality is available, then equivalence class partitioning and boundary value analysis may be useful for detecting defects and establishing component behavior. Usage profiles are characterizations of the population of intended uses of the software in its intended environment . These are not strictly black box in nature. As in the testing of newly developing software, the testing of COTS components requires the development of test cases, test oracles, and auxiliary code called a test harness In the case of COTS components, additional code, called glue software, must be developed to bind the COTS component to other modules for smooth system functioning. All of these activities add to the costs of reuse and must be considered when project plans are developed. Researchers are continually working on issues related to testing and certification of COTS components. Certification refers to third-party assurance that a product (in our case a software product), process, or service meets a specific set of requirements. 5. Evaluating Test Adequacy Criteria (NOV/DEC 2008) Testers are often faced with the decision of which criterion to apply to a given item under test given the nature of the item and the constraints of the test environment (time, costs, resources) One source of information the tester can use to select an appropriate criterion is the test adequacy criterion hierarchy 217

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Testers can use the axioms to: Recognize both strong and weak adequacy criteria; a tester may decide to use a weak criterion, but should be aware of its weakness with respect to the properties described by the axioms. stimulate thought for the development of new criteria; the axioms are the framework with which to evaluate these new criteria. The axioms are based on the following set of assumptions : (i) programs are written in a structured programming language; (ii) programs are SESE (single entry/single exit); (iii) all input statements appear at the beginning of the program; (iv) all output statements appear at the end of the program. The axioms/properties described by Weyuker are the following : Applicability Property Non exhaustive Applicability Property Monotonicity Property Inadequate Empty Set Antidecomposition Property Anticomposition Property Renaming Property Complexity Property Statement Coverage Property 218

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING UNIT III LEVELS OF TESTINGThe need for Levers of Testing – Unit Test – Unit Test Planning – Designing the UnitTests – The Test Harness – Running the Unit tests and Recording results – Integrationtests – Designing Integration Tests – Integration Test Planning – Scenario testing –Defect bash elimination System Testing – Acceptance testing – Performance testing –Regression Testing –Internationalization testing – Ad-hoc testing – Alpha, Beta Tests –Testing OO systems – Usability and Accessibility testing – Configuration testing –Compatibility testing – Testing the documentation –Website testing. KEY NOTES1.Need for levels testing. Unit Test Integration Test System Test Acceptance Test Fig: Levels of Testing Alpha And Beta Test2.Levels of testing and software development paradigm Fig: Levels of testing Two Approaches Bottom Up Top Down Two types of Language Procedure Oriented Object Oriented3.Unit Test Functions, procedures, classes and methods as units Fig: Some components suitable for unit test Unit Test: Need for preparation Planning Both black box and White box Reviewer Several Tasks4.Unit Test Planning Phase I: Describe unit test approach and Risks Phase II: Identify unit features to be tested Phase III: Add levels of detail to the planning5.The class as testable unit Issue1: Adequately Testing classes 219

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Issue2: Observation of object states and state changes. Issue3: The retesting of classes-I Issue4: The retesting of classes-II Fig: Sample stack class with multiple methods Fig: Sample Shape class6.Test harness• The auxiliary code developed into support testing of units and components iscalled a test harness. The harness consists of drivers that call the target code and stubsthat represent modules it calls. Fig: The test Harness Diver Stub7.Integration Test Goals Integration strategies for procedures and functions Top down Bottom up Fig: Simple Structure chart for integration test example Integration strategies for classes Fig: An generic class cluster8.System test: Different Types Functional testing Performance testing Stress testing Configuration testing Security testing Recovery testing The other types of system Testing are, Reliability & Usability testing. Fig: Types of System Tests Fig: Example of special resources needed for a performance test PART-A1.What is Test harness? (NOV/DEC 2012) The auxiliary code developed to support to testing of units and components iscalled a test harness. The harness consists of drivers that call the target code and stubsthat represent modules it calls.2. Define Unit Test and characterize the unit test. (NOV/DEC 2012) At a unit test a single component is tested. A unit is the smallest possible testablesoftware component. 220

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERINGIt can be characterized in several ways  A unit in a typical procedure oriented software systems.  It performs a single cohensive function.  It can be compiled separately.  It contains code that can fit on a single page or a screen.3. Define Alpha and Beta Test. (APR/MAY 2012) Alpha test developer‘s to use the software and note the problems. Beta test whouse it under real world conditions and report the defect to the Developing organization.4.List the levels of Testing or Phases of testing.(NOV/DEC 2009)  Unit testing  Integration test  System test  Acceptance test5. List the phases of unit test planning. (APRIL/MAY 2010) Unit test planning having set of development phases. Phase1: Describe unit test approach and risks. Phase 2: Identify unit features to be tested. Phase 3: Add levels of detail to the plan.6.Define System test. (NOV/DEC 2011) When integration test are completed a software system has been assembled and itsmajor subsystems have been tested. At this point the developers /testers begin to test it asa whole. System test planning should begin at the requirements phase.7. Define Test incident report. (APRIL/MAY 2012) The tester must determine from the test whether the unit has passed or failed thetest. If the test is failed, the nature of the problem should be recorded in what issometimes called a testincident report.8. List the issues in the unit test.(NOV/DEC 2011) Issue 1: Adequately testing classes. Issue 2: Observation of objects states and state changes. Issue 3: The retesting of classes-I Issue 4: The retesting of classes-II9. What is meant by Stress testing? (APRIL/MAY 2009) When a system is tested with a load that causes it to allocate its resources inmaximum amounts, this is called stress testing.10.What are the Integration strategies?(NOV/DEC 2010) Top_ Down: In this strategy integration of the module begins with testing theupper level modules. Bottom_ Up: In this strategy integration of the module begins with testing thelowest level modules. 221

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING11.Define Breaking the System. The goal of stress test is to try to break the system; Find the circumstances underwhich it will crash. This is sometimes called ―breaking the system‖12. Give the examples of security testing.  Password checking  Legal and illegal entry with password  Password Expiration  Encryption  Browsing  Trap doors  Viruses.13. What is Cluster? A cluster consists of classes that are related and they may work together tosupport a required functionality for the complete system.14. List the two major requirements of Performance testing.  Functional requirements  Quality requirements.15. List the components suitable for unit test.  Procedures and functions  Classes/objects and methods  Procedure-sized reusable components.16. Define Summary report. The causes of the failure should be recorded in the test summary report, which isthe summary of testing activities for all the units covered by the unit test plan.17. Define load generator and Load. An important tool for implementing system tests is a load generator. A loadgenerator is essential for testing quality requirements such as performance and stressA load is a series of inputs that simulates a group of transactions. A transaction is a unitof work seen from the system user‘s view. A transaction consist of a set of operation thatmay be perform by a person , s/w system or device that is outside the system.18. What is the advantage of Bottom up integration? Bottom-up integration has the advantage that the lower-level modules are usuallywell tested early in the integration process. This is important if these modules arecandidates for reuse.19. List the effect of security breaches.  Loss of information  Corruption of information  Misinformation  Privacy violations  Denial of service. 222

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING20. List the areas covered during recovery testing.  Restart  Switchover. PART-B1.Explain the Unit test Planning in detail (NOV/DEC 2012) General unit test plan should be prepared. It may be prepared as a component ofthe master test plan or as a stand-alone plan. It should be developed in conjunction with the master test plan and the projectplan for each project. Also note that a unit test plan is developed to cover all the units within a softwareproject; however, each unit will have its own associated set of tests. Phase 1: Describe Unit Test Approach and RisksIn this phase of unit testing planning the general approach to unit testing is outlined. Thetest planner: (i) identifies test risks (ii) describes techniques to be used for designing the test cases for the units; (iii) describes techniques to be used for data validation and recording of testresults; (iv) describes the requirements for test harnesses and other software thatinterfaces with the units to be tested, for example, any special objects needed for testingobject-oriented units. Phase 2: Identify Unit Features to be Tested Phase 3: Add Levels of Detail to the Plan Designing the unit tests Part of the preparation work for unit test involves unit test design. It is importantto specify (i) the test cases (including input data, and expected outputs for each test case),and, (ii) the test procedures (steps required run the tests). The class as a testable unit Issue 1: Adequately Testing Classes Issue 2: Observation of Object States and State Changes Issue 3: The Retesting of Classes—I Issue 4: The Retesting of Classes—II The test harness The auxiliary code developed to support testing of units and components is calleda test harness. The harness consists of drivers that call the target code and stubs thatrepresent modules it calls. Running the unit tests and recording results Unit tests can begin when 223

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING(i) the units becomes available from the developers (an estimation of availability is partof the test plan),(ii) the test cases have been designed and reviewed, and(iii) the test harness, and any other supplemental supporting tools, are available.2.Explain the Integration tests in detail. (APRIL/MAY 2009) Integration test for procedural code has two major goals: (i) to detect defects that occur on the interfaces of units; (ii) to assemble the individual units into working subsystems and finally acomplete system that is ready for system test. In unit test the testers attempt to detect defects that are related to the functionalityand structure of the unit With a few minor exceptions, integration test should only be performed on unitsthat have been reviewed and have successfully passed unit testing. Integration testing works best as an iterative process in procedural orientedsystem. One unit at a time is integrated into a set of previously integrated modules whichhave passed a set of integration tests. Designing integration tests: Integration tests for procedural software can be designed using a black or whitebox approach. Both are recommended. The author has had the personal experience of spending many hours trying tolocate a fault that was due to an incorrect ordering of parameters in the calling routine. Integration test planning For object-oriented systems a working definition of a cluster or similar constructmust be described, and relevant test cases must be specified. In addition, testing resourcesand schedules for integration should be included in the test plan. The plan includes thefollowing items: (i) clusters this cluster is dependent on; (ii) a natural language description of the functionality of the cluster to betested; (iii) list of classes in the cluster; (iv) a set of cluster test cases. When planning for integration test the planner selects subsystems to build basedupon the requirements and user needs. Very often subsystems selected for integration areprioritized. Those that represent key features, critical features, and/or user-orientedfunctions may be given the highest priority. Developers may want to show clients thatcertain key subsystems have been assembled and are minimally functional.3.State different levels of testing and explain types of System tests. (NOV/DEC 2009) When integration tests are completed, a software system has been assembled andits major subsystems have been tested. At this point the developers/ testers begin to test itas a whole. 224

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING System test planning should begin at the requirements phase with thedevelopment of a master test plan and requirements-based (black box) tests. There are many components of the plan that need to be prepared such as testapproaches, costs, schedules, test cases, and test procedures. There are several types of system tests Functional testing Performance testing Stress testing Configuration testing Security testing Recovery testing Functional testing All possible classes of system output must exercised and examined. All effective system states and state transitions must be exercised and examined. All functions must be exercised.Performance Testing 1. Functional requirements. 2. Quality requirements.Stress Testing When a system is tested with a load that causes it to allocate its resourcesin maximum amounts, this is called stress testing. For example, if an operating system isrequired to handle 10 interrupts/second and the load causes 20 interrupts/second, thesystem is being stressed.Configuration Testing According to Beizer configuration testing has the following objectives: Show that all the configuration changing commands and menus work properly. Show that all interchangeable devices are really interchangeable, and that theyeach enter the proper states for the specified conditions. Show that the systems‗ performance level is maintained when devices areinterchanged, or when they fail.Security Testing Attacks can be random or systematic. Damage can be done throughvarious means such as: (i) viruses; (ii) Trojan horses; (iii) trap doors; (iv) illicit channels.Recovery Testing Beizer advises that testers focus on the following areas during recoverytesting : 225

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING 1. Restart. 2. Switchover.4.Explain Regression Testing ( NOV/DEC 2013) Regression testing is not a level of testing, but it is the retesting of software thatoccurs when changes are made to ensure that the new version of the software has retainedthe capabilities of the old version and that no new defects have been introduced due to thechanges. The unit is repaired and then retested with all the old test cases to ensure that thechanges have not affected its functionality. Regression tests are especially importantwhen multiple software releases are developed. Users want new capabilities in the latest releases, but still expect the oldercapabilities to remain in place. This is where regression testing plays a role. Test cases, test procedures, and other test- related items from previous releasesshould be available so that these tests can be run with the new versions of the software.Automated testing tools support testers with this very time- consuming task.5. Explain Alpha, beta and acceptance tests. (APRIL/MAY 2014) Users/clients may also have participated in prototype evaluation, usage profiledevelopment, and in the various stages of usability testing. Developers/testers must keep in mind that the software is being developed tosatisfy the users requirements, and no matter how elegant its design it will not beaccepted by the users unless it helps them to achieve their goals as specified in therequirements. Alpha, beta, and acceptance tests allow users to evaluate the software in terms oftheir expectations and goals. When software is being developed for a specific client, acceptance tests arecarried out after system testing. Typical inputs and illegal inputs should be used and all major functions should beexercised. If the entire suite of tests cannot be run for any reason, then the full set of testsneeds to be rerun from the start. Acceptance tests are a very important milestone for the developers. At this timethe clients will determine if the software meets their requirements. Development organizations will often receive their final payment whenacceptance tests have been passed. If the software has been developed for the mass market (shrink-wrappedsoftware), then testing it for individual clients/users is not practical or even possible inmost cases. Beta test sends the software to a cross-section of users who install it and use itunder real world working conditions. The users send records of problems with thesoftware to the development organization where the defects are repaired sometimes intime for the current release. 226

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING UNIT IV TEST MANAGEMENT People and organizational issues in testing – Organization structures for testing teams – testing services – Test Planning – Test Plan Components – Test Plan Attachments – Locating Test Items –test management – test process – Reporting Test Results – The role of three groups in Test Planning and Policy Development – Introducing the test specialist – Skills needed by a test specialist – Building a Testing Group. KEY NOTES People and Organizational Issues in Testing Organization Structures for Testing Teams Testing Services Test Planning Test Plan Components o Test plan identifier o Introduction o Item to be tested o Feature to be tested o Approach o Item pass/fail criteria o Suspension and resumption criteria o Test deliverables o Testing tasks o The testing environment o Responsibilities o Staffing and training needs o Scheduling o Risks and contingencies o Testing costs Test Plan Attachments o Test design specifications Test design specification identifier Function to be tested Approach refinements Test case identification Pass/fail criteria o Test case specification Test case specification identifier Test items 227

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Input specification Output specification Special environmental needs Special procedure requirements Intercase dependencies o Test procedure specification Test procedure specification identification Purpose Specific requirements Procedure steps Locating Test Items Test Management Test Process Reporting Test Results o Test log o Test incident report o Test summary report The Role of Three Groups in Test Planning and Policy Development Introducing the Test Specialist Skills Needed by a Test Specialist Building a Testing Group. PART-A 1. What are the various approaches to test cost estimation (NOV/DEC 2013)  COCOMO Model  Use of test cost drivers  Test Tasks  Testers / Developers ratio  Expert judgment 2. List the Test plan components. (NOV/DEC 2013)  Test plan identifier  Introduction  Items to be tested  Features to be tested  Approach  Pass/fail criteria  Suspension and resumption criteria  Test deliverables  Testing Tasks 228

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING3. What are the three types of goals in testing (APRIL/MAY 2013)  Business Goal  Technical Goal  Political Goal4. Write short notes on Cost driver? (APRIL/MAY 2013) A Cost driver can be described as a process or product factor that has animpact on overall project costs. Cost drivers for project that includes product attributessuch as the required level of reliability.5. Write the test term hierarchy? (NOV/DEC 2012)  Test Manager  Test leader  Test Engineer  Junior Test Engineer.6. Define the term policy (NOV/DEC 2012) A policy can be defined as a high-level statement of principle or course ofaction that is used to govern a set of activities in an organization.7. Define Milestones. (APRIL/MAY 2012) Milestones are tangible events that are expected to occur at a certain time inthe Project‘s lifetime. Managers use them to determine project status.8. Define Test Log. (APRIL/MAY 2012) The Test log should be prepared by the person executing the tests. It is a diaryof the events that take place during the test. It supports the concept of a test as arepeatable experiment.9. Define a Work Breakdown Structure.(WBS) (APRIL/MAY 2014) A Work Breakdown Structure (WBS) is a hierarchical or tree likerepresentation of all the tasks that are required to complete a project.10. Define the term Pass / Fail Criteria (NOV/DEC 2014) Given a test item and a test case, the tester must have a set of criteria to decideon whether the test has been passed or failed upon execution.11. Define Risks & Contingencies. (APRIL/MAY 2014) Every testing effort has risks associated with it. Testing software with a highdegree of critically, complexity, or a tight delivery deadline all impose risks that mayhave negative impacts on project goals.12. Define Breaking the System. (NOV/DEC 2014) The goal of stress test is to try to break the system; Find the circumstancesunder which it will crash. This is sometimes called ―breaking the system13. What is meant by regression testing? (APRIL/MAY 2015) Regression testing is used to check for defects propagated to other modules bychanges made to existing program. Thus, regression testing is used to reduce the sideeffects of the changes. 229

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING14. What are the skills needed by a test specialist?  Personal and managerial Skills Organizational, and planning skills, work with others, resolve conflicts,mentor and train others, written /oral communication skills, think creatively.  Technical Skills General software engineering principles and practices, understanding oftesting principles and practices, ability to plan, design, and execute test cases,knowledge of networks, database, and operating System.15.Define Plan A plan is a document that provides a framework or approach for achieving aset of goals.16. What is the use of V-model in testing The V-model is model that illustrates how testing activities can be integrated into each phase of the standard software life cycle.17. What are the steps in forming the test group.  Upper management support for test function  Establish test group organization, career paths  Define education and skill levels  Develop job description  Interview candidates  Select Test group members18. Define Test incident Report The tester should record in attest incident report (sometimes called aproblem report) any event that occurs during the executions of the tests that isunexpected , unexplainable, and that requires a follow- up investigation.19. Define Goal and Policy A goal can be described as (i) a statement of intent or (ii) a statement of aaccomplishment that an individual or an org wants to achieve. A Policy can be defined as a high- level statement of principle or course ofaction that is used to govern a set of activities in an org.20. What is the function of Test Item Transmittal Report or Locating TestItems? Suppose a tester is ready to run tests on the data described in the test plan. Weneeds to be able to locate the item and have knowledge of its current status. This is thefunction of the Test Item Transmittal Report. Each Test Item Transmittal Report has aunique identifier. 230

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING PART-B 1.Explain the role of Test Planning in detail.(NOV/DEC 2009) Defn: A plan is a document that provides a framework or approach for achieving a set of goals. Milestones are tangible events that are expected to occur at a certain time in the project‘s lifetime. Managers use them to determine project status. Tracking the actual occurrence of the milestone events allows a manager to determine if the project is progressing as planned. Finally, a plan should assess the risks involved in carrying out the project. Test plans for software projects are very complex and detailed documents. The planner usually includes the following essential high-level items. 1. Overall test objectives. As testers, why are we testing, what is to be achieved by the tests, and what are the risks associated with testing this product? 2. What to test (scope of the tests). What items, features, procedures, functions, objects, clusters, and subsystems will be tested? 3. Who will test. Who are the personnel responsible for the tests? 4. How to test. What strategies, methods, hardware, software tools, and techniques are going to be applied? What test documents and deliverable should be produced? 5. When to test. What are the schedules for tests? What items need to be available? 6. When to stop testing. It is not economically feasible or practical to plan to test until all defects have been revealed. This is a goal that testers can never be sure they have reached. Because of budgets, scheduling, and customer deadlines, specific conditions must be outlined in the test plan that allow testers/managers to decide when testing is considered to be complete. The remainder of this chapter focuses on the development of a general- purpose execution-based test plan that will be referred to as a ―test plan.‖ The description of the test plan contents is based on a discussion of recommended test plan components appearing in the IEEE Standard for Software Test Documentation: IEEE/ANSI Std 829-1983. Test plan components 1.Test plan Identifier 2.Introduction 3.Items to be tested 4.Features to be tested 5.Approach 6.Item pass /Fail criteria 7.Suspension and Resumption criteria 8.Test Deliverables 231

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING 9.Testing tasks 10. The testing Environment 11.Responsibilities 12.Stafffing and Training needs 13.Scheduling 14.Risks and contingencies 15.Testing costs 2.Write the various skills needed by a Test Specialist(NOV/DEC2012) Given the nature of technical and managerial responsibilities assigned to the tester that are listed in Section 8.0, many managerial and personal skills are necessary for success in the area of work. On the personal and managerial level a test specialist must have: organizational, and planning skills; the ability to keep track of, and pay attention to, details; the determination to discover and solve problems; the ability to work with others and be able to resolve conflicts;  the ability to mentor and train others;  the ability to work with users and clients;  strong written and oral communication skills;  the ability to work in a variety of environments;  the ability to think creatively They need to be able to visualize the many ways that a software item should be tested, and make hypotheses about the different types of defects that could occur and the different ways the software could fail. On the technical level testers need to have:  An education that includes an understanding of general software engineering principles, practices, and methodologies;  Strong coding skills and an understanding of code structure and behavior;  A good understanding of testing principles and practices;  A good understanding of basic testing strategies, methods, and techniques;  The ability and experience to plan, design, and execute test cases and test procedures on multiple levels (unit, integration, etc.);  A knowledge of process issues;  knowledge of how networks, databases, and operating systems are organized and how they work;  a knowledge of configuration management;  a knowledge of test-related documents and the role each documents plays in the testing process; 232

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING  the ability to define, collect, and analyze test-related measurements;  the ability, training, and motivation to work with testing tools and equipment;  a knowledge of quality issues. Testers must have a knowledge of both white and black box techniques and methods and the ability to use them to design test cases. Organizations need to realize that this knowledge is a necessary prerequisite for tool use and test automation. Testers need to understand the need for multilevel tests and approaches used for testing at each level. 3.Explain the building a Testing group in detail.(APRIL/MAY 2013) It was mentioned that organizing, staffing, and directing were major activities required to manage a project and a process. These apply to managing the testing process as well. Staffing activities include filling positions, assimilating new personnel, education and training, and staff evaluation. They describe four categories for employees based on their performance: (i) retain, (ii) likely to retain, (iii) likely to release, (iv) and release. For each category, appropriate actions need to be taken by the manager to help employee and employer.  Structure of test group By investing in a test organization a company has access to a group of specialists who have the responsibilities and motivation to:o maintain testing policy statements;o plan the testing efforts;o monitor and track testing efforts so that they are on time and within budget;o measure process and product attributes;o provide management with independent product and process quality information;o design and execute tests with no duplication of effort;o automate testing;o participate in reviews to insure quality; are meet. The duties of the team members may vary in individual organizations. The following gives a brief description of the duties for each tester that are common to most organizations.  The Test Manager  The Test Lead  The Test Engineer  The Junior Test Engineer 233

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING4.Explain the Testing and Debugging goals and policies (NOV/DEC 2014) A goal can be described as (i) a statement of intent, or (ii) a statement of aaccomplishment that an individual or an organization wants to achieve. Goal statements can express expectations in quantitative terms or be moregeneral in nature. For the testing goals below, goals 1 and 2 express what is to beachieved in a more quantitative manner than goals 3 and 4. 1. One-hundred percent of testing activities are planned. 2. The degree of automation for regression testing is increased from 50% to80% over the next 3 years. 3. Testing activities are performed by a dedicated testing group. 4. Testing group members have at least a bachelor-level degree and have takena formal course in software testing. A policy can be defined as a high-level statement of principle or course ofaction that is used to govern a set of activities in an organization.  Testing policy :Organizations 1 Delivering software of the highest quality is our company goal. 2.A set of testing standards must be available to all interestedparties on an intra organizational web site. 3.In our organization the following apply to all softwaredevelopment/ maintenance projects: 4. Because testing is an activity that requires special training andan impartial view of the software, it must be carried out by an independent testinggroup 5. Testing must be supported by tools, and, test-relatedmeasurements must be collected and used to evaluate and improve the testing processand the software product. 234

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING 6. Resources must be provided for continuous test processimprovement. 7.Clients/developer/tester communication is important, and clientsmust be involved in acceptance test planning, operational profile development, andusage testing when applicable to the project. 8. A permanent committee consisting of managerial and technicalstaff must be appointed to be responsible for distribution and maintenance oforganizational test policy statements.  DebuggingPolicy: OrganizationX 1. Testing and debugging are two separate processes. 2. Since debugging is a timely activity, all project schedulesmust allow for adequate time to make repairs, and retest the repaired software. 3. Debugging tools, and the training necessary to use the tools,must be available to developers to support debugging activities and tasks. 4. Developers/testers and SQA staff must define and documenta set of defect classes and defect severity levels. These must be must be available to allinterested parties on an intraorganizational web site, and applied to all projects. 5. All defects identified for each project must be catalogedaccording to class and severity level and stored as a part of the project history. 6. Measurement such as total number of defects, total number ofdefects/ KLOC, and time to repair a defect are saved for each project. UNIT V TEST AUTOMATION Software test automation – skill needed for automation – scope of automation – design and architecture for automation – requirements for a test tool – challenges in automation – Test metrics and measurements – project, progress and productivity metrics. KEY NOTES Software Test Automation Skills Needed for Automation Scope of Automation o Identifying the types of testing amenable to automation o Automating areas less prone to change o Automate test that pertain to standards o Manage aspects in automation Requirements for a Test Tool Challenges in Automation Project Metrics 235

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING o Effort variance o Schedule variance o Effort distribution across phases SCM o Identification of the configuration items o Change control o Configuration status reporting o Configuration audits Types of Reviews o Inspection as a type of technical review o Walkthroughs as a type of technical review Developing a Review Program Components of Review Plans o Review goals o Preconditions and items to be reviewed o Roles, participants, tem size and time requirements o Review procedures o Review training Review of process concepts Review of quality issues Review of organizational standards for software artifacts Understanding the material to be reviewed Defect and problem types Communication and meeting management skills Review documentation and record keeping Special instructions Practice review sessions o Review checklists o Requirement review o Design review o Code review o Test plan review Reporting Review Results Evaluating Software Quality o Review of quality concepts o Quality costs o What is quality control? o The role of operational profiles and usage models in quality control Develop the customer profile Establish the user profile 236

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING Develop the system mode profile Develop the functional profile Develop the operational profile o Support for quality control: Statistical testing o Software reliability Measurements of software reliability o Reliability, quality control and step-test decision Applying reliability models o Confidence levels and quality control o Usability testing and quality control o An approach of usability testing o Software quality control and the three critical views Manager roles Tester role User/clients role Manager role Testers role User/client role Testing Maturity Model o Need o Approach to model development o Process improvement model representation o TMM Structure o TMM assessment model o The TMM assessment model components o The TMM ranking procedure o Form and tools for assessment support o Relationship of the TMM to other process improvement models o Industrial application of the TMM PART-A 1. Define Project monitoring or tracking.( NOV /DEC 2012) Project monitoring refers to the activities and tasks managers engage into periodically check the status of each project .Reports are prepared that compare the actual work done to the work that was planned. 2. Define SCM (Software Configuration management). (APRIL/MAY 2013) Software Configuration Management is a set of activities carried out for identifying, organizing and controlling changes throughout the lifecycle of computer software. 237

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING3. Define Project Controlling. (NOV/DEC 2013) It consists of developing and applying a set of corrective actions to get a projecton track when monitoring shows a deviation from what was planned .4. List some examples of testing Milestone(APRIL/MAY 2013)  Completion of the Master test plan  Completion of branch coverage for all units  Execution of all planned system test  Completion of the test summary report.5. Define Base line. (MAY/JUNE 2012) Base lines are formally reviewed and agreed upon versions of software artifacts,from which all changes are measured. They serve as the basis for further developmentand can be changed only through formal change procedures.6. List various Measurements for monitoring testing status. (APRIL/MAY 2013)  Coverage Measures  Test Case Development  Test Execution  Test Harness Development7. What is Testing? (NOV/DEC 2012) Testing is generally described as a group of procedures carried out to evaluatesome aspect of a piece of software. It used for revealing defect in software and toevaluate degree of quality.8. List the types of testing measurements (NOV /DEC 2013)  Coverage  Test Case Development  Test Execution  Test Harness9. Define Review. (MAY/JUNE 2012) Review is a group meeting whose purpose is to evaluate a software artifact or aset of software artifacts.10. What are the various Severity level hierarchy (MAY/JUNE 2014)  Catastrophic  Critical  Marginal  Minor or Annoying11. What is Inspections? (NOV/DEC 2014) It is a type of review that is formal in nature and requires preview preparation onthe part of the review team. The Inspection leader prepares is the checklist of items thatserves as the agenda for the review.12. What are the various steps in the inspection process (MAY/JUNE 2014)  Entry Criteria 238

SEMESTER – VI COMPUTER SCIENCE AND ENGINEERING  Initiation  Preparation  Inspection Meeting  Reporting results  Rework & follow up13. What is Walkthrough? (NOV/DEC 2014) It is a type of technical review where the producer of the reviewed material serves as thereview leader and actually guides the progression of the review .It have traditionally beenapplied to design and code.14. What are the various steps in the inspection process  .Entry Criteria  Initiation  Preparation  Inspection Meeting  Reporting results  Rework & follow up15.List out the members present in the Review Team.  SQA(Software Quality Assurance) staff  Testers  Developers  Specialists.16. List the components of review plans.  Review Goals  Items being reviewed  Preconditions for the review.  Rolls, Team size, participants.  Training requirements.  Review steps.  Time requirements17. What are the types of reports?  Customized reports.  Technical Report  Debug reports.18. What are the disadvantages of first generation automation?  Scripts holds hardcoded values.  Test maintenance cost is maximized.19. Define Milestone. Milestones are tangible events that are expected to occur at a certain timein the projects life time .Managers use them to determine project status. 239