software testing genius

ISTQB Advanced CTAL Exam-Study Guide-Part 7

Welcome to “Software Testing Genius”. Subscribe to my RSS feed for latest content on Software Testing.

ISTQB Advanced CTAL Exam-Study Guide-Part 7

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. 61: What are the key principles to adhere to during system testing?

1) System tests should be developed and performed by a group independent of the people who developed the code.

2) System test plans must be developed and inspected with the same rigor as other elements of the project.

3) System test progress must be planned and tracked similarly to other elements of the project.

4) System tests must be repeatable.

<<<<<<

=================== >>>>>>

Q. 62: What are the types of errors targeted by regression testing?

1) Data corruption errors:
These errors are side effects due to shared data.

2) Inappropriate control sequencing errors: These errors are side effects due to changes in execution sequences. An example of this type of error is the attempt to remove an item from a queue before it is placed into the queue.

3) Resource contention: Examples of these types of errors are potential bottlenecks and deadlocks.

4) Performance deficiencies: These include timing and storage utilization errors.

<<<<<< =================== >>>>>>

Q. 63: What are the types of errors targeted by integration testing?

1) Import/export range errors:
This type of error occurs when the source of input parameters falls outside of the range of their destination. For example, assume module A calls module B with table pointer X. If A assumes a maximum table size of 10 and B assumes a maximum table size of 8, an import/export range error occurs. The detection of this type of error requires careful boundary-value testing of parameters.

2) Import/export type compatibility errors: This type of error is attributed to a mismatch of user-defined
types. These errors are normally detected by compilers or code inspections.

3) Import/export representation errors: This type of error occurs when parameters are of the same type, but the meaning of the parameters is different in the calling and called modules. For example, assume module A passes a parameter Elapsed_Time, of type real, to module B. Module A might pass the value as seconds, while module B is assuming the value is passed as milliseconds. These types of errors are difficult to detect, although range checks and inspections provide some assistance.

4) Parameter utilization errors: Dangerous assumptions are often made concerning whether a module called will alter the information passed to it. Although support for detecting such errors is provided by some compilers, careful testing and/or inspections may be necessary to insure that values have not been unexpectedly corrupted.

5) Integration time domain/ computation errors: A domain error occurs when a specific input follows the wrong path due to an error in the control flow. A computation error exists when a specific input follows the correct path, but an error in some assignment statement causes the wrong function to be computed. Although domain and computation errors are normally addressed during module testing, the concepts apply across module boundaries. In fact, some domain and computation errors in the integrated program might be masked during integration testing if the module being integrated is assumed to be correct and is treated as a black box.

<<<<<< =================== >>>>>>

Q. 64: What are the different strategies for integration testing?

Several strategies for integration testing exist. These strategies may be used independently or in combination. The primary techniques are:

1) Top-down integration:
Top-down integration attempts to combine incrementally the components of the program, starting with the topmost element and simulating lower level elements with stubs. Each stub is then replaced with an actual program component as the integration process proceeds in a top-down fashion. Top-down integration is useful for those components of the program with complicated control structures. It also provides visibility into the integration process by demonstrating a potentially useful product early.

2) Bottom-up integration:
Bottom-up integration attempts to combine incrementally components of the program starting with those components that do not invoke other components. Test drivers must be constructed to invoke these components. As bottom-up integration proceeds, test drivers are replaced

with the actual program components that perform the invocation, and new test drivers are constructed until the "top" of the program is reached. Bottom-up integration is consistent with the notion of developing software as a series of building blocks. Bottom-up integration should proceed wherever the driving control structure is not too complicated.

3) Big-bang integration: Big-bang integration is not an incremental strategy and involves combining and testing all modules at once. Except for small programs, big-bang integration is not a cost-effective technique because of difficulty of isolating integration testing failures.

4) Threaded integration:
Threaded integration is an incremental technique that identifies major processing functions that the product is to perform and maps these functions to modules implementing them. Each processing function is called a thread. A collection of related threads is often called a build. Builds may serve as a basis for test management. To test a thread, the group of modules corresponding to the thread is combined. For those modules in the thread with interfaces to other modules not supporting the thread, stubs are used. The initial threads to be tested normally correspond to the "backbone" or "skeleton" of the product under test. The addition of new threads for the product undergoing integration proceeds incrementally in a planned fashion.

<<<<<< =================== >>>>>>

Q. 65: What are the guidelines for selecting paths in a transaction Flow?

1)
Test every link/decision in the transaction flow graph.

2) Test each loop with a single, double, typical, maximum, and maximum- less-one number of iterations

3) Test combinations of paths within and between transaction flows.

4) Test that the system does not do things that it is not supposed to do, by watching for unexpected sequences of paths within and between transaction flows.

Once the transaction flows have been identified black-box testing techniques can be utilized to generate test data for selected paths through the transaction flow diagram.

<<<<<< =================== >>>>>>

Q. 66: What is Failure Analysis?

Failure analysis is the examination of the productís reaction to failures of hardware or software. The productís specifications must be examined to determine precisely which types of failures must be analyzed and what the productís reaction must be. Failure analysis is sometimes referred to as "recovery testing".

Failure analysis must be performed during each of the productís V&V activities. It is essential during requirement and specification V&V activities that a clear statement of the productís response to various types of failures be addressed in terms that allow analysis. The design must also be analyzed to show that the productís reaction to failures satisfies its specifications. The failure analysis of implementations often occurs during system testing. This testing may take the form of simulating hardware or software errors or actual introduction of these types of errors.

Failure analysis is essential to detecting product recovery errors. These errors can lead to lost files, lost data, duplicate transactions, etc. Failure analysis techniques can also be combined with other approaches during V&V activities to insure that the productís specifications for such attributes as performance, security, safety, usability, etc., are met.

<<<<<< =================== >>>>>>

Q. 67: What is Concurrency Analysis?

Concurrency analysis examines the interaction of tasks being executed simultaneously within the product to insure that the overall specifications are being met. Concurrent tasks may be executed in parallel or have their execution interleaved. Concurrency analysis is sometimes referred to as "background testing".

For products with tasks that may execute in parallel, concurrency analysis must be performed during each of the productís V&V activities. During design, concurrency analysis should be performed to identify such issues as potential contention for resources, deadlock, and priorities. A concurrency analysis for implementations normally takes place during system testing. Tests must be designed, executed, and analyzed to exploit the parallelism in the system and insure that the specifications are met.

<<<<<< =================== >>>>>>

Q. 68: What is Performance Analysis?

The goal of performance analysis is to insure that the product meets its specified performance objectives. These objectives must be stated in measurable terms, so far as possible. Typical performance objectives relate to response time and system throughput.

A performance analysis should be applied during each of the productís V&V activities. During requirement and specification V&V activities, performance objectives must be analyzed to insure completeness, feasibility, and testability. Prototyping, simulation, or other modeling approaches may be used to insure feasibility. For designs, the performance requirements must be allocated to individual components.

These components can then be analyzed to determine if the performance requirements can be met. Prototyping, simulation and other modeling approaches again are techniques applicable to this task. For implementations a performance analysis can take place during each level of testing. Test data must be carefully constructed to correspond to the scenarios for which the performance requirements were specified.

<<<<<< =================== >>>>>>

Q. 69: What is Proof of Correctness?

Proof of correctness is a collection of techniques that apply the formality and rigor of mathematics to the task of proving the consistency between an algorithmic solution and a rigorous, complete specification of the intent of the solution. This technique is also often referred to as "formal verification."

Proof of correctness techniques are normally represented in the context of verifying an implementation against a specification. The techniques are also applicable in verifying the correctness of other products, as long as they possess a formal representation.

<<<<<< =================== >>>>>>

Q. 70: What are the different types of evaluations for assuring software quality?

Different evaluation types are:

1) Internal consistency of product
2) Understandability of product
3) Traceability to indicated documents
4) Consistency with indicated documents
5) Appropriate allocation of sizing, timing resources
6) Adequate test coverage of requirements
7) Consistency between data definitions and use
8) Adequacy of test cases and test procedures
9) Completeness of testing
10) Completeness of regression testing

Reference: Technical archive from SEI - Software Engineering Institute

Read Part -8 of the Study Guide

Full Study Material for ISTQB Test Analyst & Technical Test Analyst Exam

ISTQB Advanced CTAL Test Manager Exam - Full Crash Course for Download

Consolidated Study Material - All ISTQB Certification Exams

What Successful Testers say about the Quality of this website

If you want to keep track of further articles on Software Testing,
I suggest you to subscribe my
RSS feed
.

You can also Subscribe by E-mail
and get All New articles delivered directly to your Inbox.


Quick Navigation of Software Testing Genius

Get your Absolutely Free Copy of Several MS PowerPoint Presentations & E-Books related to ISTQB, HP Load Runner, IBM RFT, HP QTP & QC Certification Exams, prepared by Popular Writers & Trainers, by writing to: Software.testing.genius@gmail.com

Study Material for Certification Exams on Other Automation Tools:

Download Full Study Material - HP QTP & QC Certification Exams

Practical Roadmap to QTP Certification

Rehearsal of QTP in 1 Hr. -  Interview Questions

Study Material - HP LoadRunner Certification Exams for All Modules

Rehearsal of LoadRunner in 1 Hr. -  Interview Questions

Study Material - IBM RFT Certification Exam

Study Material to prepare for Manual Testing & QA:

Practical Roadmap to CSTE Certification

Consolidated Study Material - Testing & QA

 

Comments :

0 comments ↓


Leave Your Comments: (*) Marked Fields are Mandatory

You can apply basic formatting to the text

Name *
 
Email Address *
 
Website
 
Speak your mind
characters
sex hikayeleri