ISTQB Advanced Study Guide - 6


Published on

ISTQB Advanced Level Certification – Study Guide - 6

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ISTQB Advanced Study Guide - 6

  1. 1. ISTQB Advanced Level Certification – Study Guide (Part 6) 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. 51: What is Error-based Testing? Error-based testing seeks to demonstrate that certain errors have not been committed in the programming process. Error-based testing can be driven by histories of programmer errors, measures of software complexity, knowledge of error-prone syntactic constructs, or even error guessing. Error-based testing begins with the programming process, identifies potential errors in that process and then asks how those errors are reflected as faults. It then seeks to demonstrate the absence of those faults. In the error-based approach to program testing and analysis, the focus is on errors that a programmer or designer may make during the software development process, and on techniques that can be used to detect their occurrence. It is often the case that a program is constructed without any formal, detailed specification. In this case the code itself is the only complete specification. This means that the only way to verify such a program is to ensure that no errors were made by the programmer during programming. The term “errors” here means errors that occur due to human fallibility. This requires that we study the ways in which humans make mistakes in the construction of artifacts, and then build methods to detect when they have occurred. There is a simple model in which human errors are classified as being either errors of decomposition or errors of abstraction. <<<<<< =================== >>>>>> Q. 52: What is Flavor analysis? Flavor analysis is a kind of dynamic type checking. It allows the programmer to document properties of objects that change during the operation of a program, and to check if assumptions about an object’s current set of properties are correct. <<<<<< =================== >>>>>> Q. 53: What is Fault-based testing? Fault-based testing aims at demonstrating that certain prescribed faults are not in the code. Fault- based testing methods differ in both extent and breadth. One with local extent demonstrates that a fault has a local effect on computation; it is possible that this local effect will not produce a program failure. A method with global extent demonstrates that a fault will cause a program failure. Breadth is determined by whether the technique handles a finite or an infinite class of faults. Extent and breadth are orthogonal. Infection- and propagation-oriented techniques could be classified as fault-based if they are interpreted as seeking to demonstrate the absence of particular faults. Infection-oriented techniques are of local extent. Morell has defined a fault-based method based on symbolic execution that permits elimination of infinitely many faults through evidence of global failures. Symbolic faults are inserted into the code, which is then executed on real or symbolic data. Program output is then an expression in terms of the symbolic faults. It thus reflects how a fault at a given location will impact the program’s output. This expression can be used to determine actual faults that could not have
  2. 2. been substituted for the symbolic fault and remain undetected by the test. <<<<<< =================== >>>>>> Q. 54: What is a software life cycle model? A sofware life cycle model is either a descriptive or prescriptive characterization of software evolution. Typically, it is easier to articulate a prescriptive life cycle model for how software systems should be developed. This is possible since most such models are intuitive. This means that many software development details can be ignored, glossed over, or generalized. This, of course, should raise concern for the relative validity and robustness of such life cycle models when developing different kinds of application systems in different kinds of development settings. Descriptive life cycle models, on the other hand, characterize how software systems are actually developed. As such, they are less common and more difficult to articulate for an obvious reason: one must observe or collect data throughout the development of a software system, a period of elapsed time usually measured in years. Also, descriptive models are specific to the systems observed, and only generalizable through systematic analysis. Therefore, this suggests the prescriptive software life cycle models will dominate attention until a sufficient base of observational data is available to articulate empirically grounded descriptive life cycle models. <<<<<< =================== >>>>>> Q. 55: How can we use software life cycle models? Some of the ways these models can be used include: 1) To organize, plan, staff, budget, schedule and manage software project work over organizational time, space, and computing environments. 2) As prescriptive outlines for what documents to produce for delivery to client. 3) As a basis for determining what software engineering tools and methodologies will be most appropriate to support different life cycle activities. 4) As frameworks for analyzing or estimating patterns of resource allocation and consumption during the software life cycle. 5) As comparative descriptive or prescriptive accounts for how software systems come to be the way they are. 6) As a basis for conducting empirical studies to determine what affects software productivity, cost, and overall quality. <<<<<< =================== >>>>>> Q. 56: What is a software process model? A software process model often represents a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing. Software process networks can be viewed as representing methodical task chains. Task chains structure the transformation of computational entities through a passage of sequence of actions
  3. 3. that denote each process activity. Task chains are idealized plans of what actions should be accomplished, and in what order. <<<<<< =================== >>>>>> Q. 57: What is the difference between Evolutionistic and Evolutionary Models? Every model of software evolution makes certain assumptions about what is the meaning of evolution. In one such analysis of these assumptions, two distinct views are apparent: Evolutionistic models focus attention to the direction of change in terms of progress through a series of stages eventually leading to some final stage; evolutionary models on the other hand focus attention to the mechanisms and processes that change systems. Evolutionistic models are often intuitive and useful as organizing frameworks for managing and tooling software development efforts. But they are poor predictors of why certain changes are made to a system, and why systems evolve in similar or different ways. Evolutionary models are concerned less with the stage of development, but more with the technological mechanisms and organizational processes that guide the emergence of a system over space and time. As such, it should become apparent that the traditional models are evolutionistic, while the most of the alternative models are evolutionary. <<<<<< =================== >>>>>> Q. 58: What is Classic Software life cycle? The classic software life cycle is often represented as a simple waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in linear order. Such models resemble finite state machine descriptions of software evolution. However, such models have been perhaps most useful in helping to structure and manage large software development projects in organizational settings. <<<<<< =================== >>>>>> Q. 59: What is the Spiral Model or Non-Operational Process Model? The spiral model of software development and evolution represents a risk-driven approach to software process analysis and structuring. The approach incorporates elements of specification- driven and prototype driven process methods. It does so by representing iterative development cycles in a spiral manner, with inner cycles denoting early analysis and prototyping, and outer cycles denoting the classic system life cycle. The radial dimension denotes cumulative development costs, and the angular dimension denotes progress made in accomplishing each development spiral. Risk analysis, which seeks to identify situations, which might cause a development effort to fail or go over budget/schedule, occurs during each spiral cycle. In each cycle, it represents roughly the same amount of angular displacement, while the displaced sweep volume denotes increasing levels of effort required for risk analysis. System development in this model therefore spirals out only so far as needed according to the risk that must be managed. <<<<<< =================== >>>>>> Q. 60: What are the various levels of testing?
  4. 4. Following are the different levels of testing activities each with its own specific goals. 1) Module Testing: Module (or unit) testing is the lowest level of testing and involves the testing of a software module or unit. The goal of module-level testing is to insure that the component being tested conforms to its specifications and is ready to be integrated with other components of the product. 2) Integration Testing: Integration testing consists of the systematic combination and execution of product components Multiple levels of integration testing are possible with a combination of hardware and software components at several different levels. The goal of integration testing is to insure that the interfaces between the components are correct and that the product components combine to execute the product’s functionality correctly. 3) System Testing: System testing is the process of testing the integrated hardware and software system to verify that the system meets its specified requirements. Practical priorities must be established to complete this task effectively. One general priority is that system testing must concentrate more on system capabilities rather than component capabilities. This suggests that system tests concentrate on insuring the use and interaction of functions rather than testing the details of their implementations. Another priority is that testing typical situations is more important that testing special cases. This suggests that test cases be constructed corresponding to high-probability user scenarios. This facilitates early detection of critical problems that would greatly disrupt a user. 4) Regression Testing: Regression testing can be defined as the process of executing previously defined test cases on a modified program to assure that the software changes have not adversely affected the program’s previously existing functions. The error-prone nature of software modification demands that regression testing be performed.