ISTQB Advanced Study Guide - 3
Upcoming SlideShare
Loading in...5
×
 

ISTQB Advanced Study Guide - 3

on

  • 952 views

ISTQB Advanced Level Certification – Study Guide - 3

ISTQB Advanced Level Certification – Study Guide - 3

Statistics

Views

Total Views
952
Views on SlideShare
943
Embed Views
9

Actions

Likes
1
Downloads
152
Comments
0

1 Embed 9

http://testingbaires.com 9

Accessibility

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ISTQB Advanced Study Guide - 3 ISTQB Advanced Study Guide - 3 Document Transcript

  • ISTQB Advanced Level Certification – Study Guide (Part 3) Prior to appearing for exam for ISTQB Advanced Level certification, it is wise to quickly brush up your knowledge by reviewing the following questions – answers that are extremely important from the examination point of view. Q. 21: What is the underlying objective of Regression Testing? Retesting the affected function is necessary after the change is incorporated since as many as 20 percent of all corrections result in additional errors. Frequently, additional functions will need to be tested to ensure that no latent defects were induced by the correction, one method of resolution would be to treat them as new errors and initiate a new error report. The description of regression testing should include: # A list of test paragraphs/objectives retested # The version of software used to perform regression test # Indication of successful/unsuccessful accomplishment of test. <<<<<< =================== >>>>>> Q. 22: What is the utility of an Error Frequency Report? Error frequency charts report the quantity of errors per unit of software product. The unit used may be a section of a requirements specification, a test procedure paragraph, a source code program unit, or any other objectively identifiable component of a software. The utility of an error frequency report is based on the Pareto Principle of non homogeneous error distribution. If errors are non homogeneously distributed in the product to be examined, then units with high detected error frequencies will probably also have a larger than normal number of latent errors. <<<<<< =================== >>>>>> Q. 23: What is the Adequacy Criteria for testing? Verification of software by testing or other means, is quite indirect. It is necessary to judiciously constrain the verification process. Conditions that are required to be satisfied during testing are called adequacy criteria. For example, testing may be considered inadequate if the test data do not include boundary cases specified by the requirements, do not cause execution of every line of code, or do not cause the software to deal with error-prone situations. The intent in establishing these criteria is to improve the quality of the testing. As such, adequacy criteria serve a purpose somewhat akin to software development standards. Adequacy criteria act as both specifier and judge: as specifier by indicating the constraints that must be satisfied by the testing, and as judge by indicating deficiencies in a particular test. Adequacy criteria for testing are generally expressed by stating some required coverage the test data should achieve. Desirable coverages include the required features, the software structure, or the potential errors that might occur in the life cycle. <<<<<< =================== >>>>>> Q. 24: What are the limitations of testing? Some problems cannot be solved on a computer because are either intractable or undecidable. An undecidable problem is one for which no algorithmic solution is possible. In general, programs cannot be exhaustively tested (tested for each input). Huang shows that to test exhaustively a program that reads two 32-bit integers would take on the order of 50 billion years. Even if the input space is smaller, on the very first input it may be the case that the program does not halt
  • within a reasonable time. It may even be the case that it is obvious the correct output will be produced if the program ever does halt. Exhaustive testing can only be completed, therefore, if all non-halting cases can be detected and eliminated. Another limitation on the power of testing is its reliance on an oracle. An oracle is a mechanism that judges whether or not a given output is correct for a given input. In some cases, no oracle may be available e.g., when the program is written to compute an answer that cannot, in practice, be computed by hand. Imperfect oracles may be available, but their use is risky. The absence of an oracle, or the presence of an imperfect oracle weakens significantly any conclusions drawn from testing. <<<<<< =================== >>>>>> Q. 25: What is Fault Seeding? Fault seeding is a statistical method used to assess the number and nature of the faults remaining in a program. First, faults are seeded into a program. Then the program is tested, and the number of faults discovered is used to estimate the number of faults yet undiscovered. A difficulty with this technique is that the faults seeded must be representative of the yet- undiscovered faults in the program. <<<<<< =================== >>>>>> Q. 26: What is Mutation Analysis? Mutation analysis uses fault seeding to investigate properties of test data. Programs with seeded faults are called mutants. Mutants are executed to determine whether or not they behave differently from the original program. Mutants that behave differently are said to have been killed by the test. The product of mutation analysis is a measure of how well test data kill mutants. Mutants are produced by applying a mutation operator. Such an operator changes a single expression in the program to another expression, selected from a finite class of expressions. For example, a constant might be incremented by one, decremented by one, or replaced by zero, yielding one of three mutants. Applying the mutation operators at each point in a program where they are applicable forms a finite, albeit large, set of mutants. <<<<<< =================== >>>>>> Q. 27: What are the conditions necessary for a fault to cause a program failure? Three conditions necessary and sufficient for a fault to cause a program failure are execution, infection, and propagation. The fault location must be executed, the resulting data state must be infected with an erroneous value, and the succeeding computation must propagate the infection through erroneous data states, producing a failure. Sensitivity analysis investigates the three conditions required for failure, with particular focus on infection and propagation of errors. Infection analysis employs mutation analysis to determine the probability of a data state’s being infected after a potentially faulty statement is executed. Propagation analysis mutates the data state to determine the probability that an infected data state will cause a program failure. <<<<<< =================== >>>>>> Q. 28: What is Symbolic Analysis?
  • Symbolic analysis seeks to describe the function computed by a program in a more general way. A symbolic execution system accepts three inputs: a program to be interpreted, symbolic input for the program, and the path to follow. It produces two outputs: the symbolic output that describes the computation of the selected path, and the path condition for that path. The specification of the path can be either interactive or pre-selected. The symbolic output can be used to prove the program correct with respect to its specification, and the path condition can be used for generating test data to exercise the desired path. Structured data types cause difficulties, however, since it is sometimes impossible to deduce what component is being modified. <<<<<< =================== >>>>>> Q. 29: What is Specification Oriented Testing? Program testing is specification-oriented when test data are developed from documents and understandings intended to specify a module’s behavior. Sources include, but are not limited to, the actual written specification and the high- and low-level designs of the code to be tested. The goal is to test for the presence of each (required) software feature, including the input domains, the output domains, categories of inputs that should receive equivalent processing, and the processing functions themselves. Specification-oriented testing seeks to show that every requirement is addressed by the software. An unimplemented requirement may be reflected in a missing path or missing code in the software. Specification-oriented testing assumes a functional view of the software and sometimes is called functional or black-box testing. <<<<<< =================== >>>>>> Q. 30: What is Input Domain Testing? It is the testing based on the interface of the module. In extremal testing, test data are chosen to cover the extremes of the input domain. Similarly, midrange testing selects data from the interiors of domains. For structured input domains, combinations of extremal points for each component are chosen. This procedure can generate a large quantity of data. Read More articles on ISTQB CTAL Advanced Level Certifications at http://www.softwaretestinggenius.com/categoryDetail.php?catId=166