QTP Training

QTP Complete Reference

2012-02-11T05:29:00.001-08:00

QTP Complete Reference

Step by Step QTP Guide for beginners as well as advanced learners. It explains QTP Tool fundamentals and features in detailed manner. It covers QTP tool window keyelements, QTP test process, Recording and Running tests,Enhancing tests, Debugging Tests, Analyzing Test Results and Reporting Defects.

It describes QTP important features like Step Generator, Sychronization, Parameterization, Recovery scenarios and Object Identification Configuration.

An overview on Test Automation

QTP Basic features

Add-in Manager

Key elements of QTP

Test Pane

QTP Commands

QTP Test Process

Recording Tests

Keyword Driven Methodology

Test Object Model

Object Repository

Object Identification Configuration

QTP Test Methods

Data Table Methods

Descriptive Programming

Enhancing Tests

Inserting Checkpoints

Inserting Output values

Parameterization

Synchronization

Inserting Transaction Points

Step Generator

Adding Comments

Inserting Flow Control Statements

Debugging Tests

Running/Executing Tests

Analyzing Test Results & Reporting

Reporting Defects

Actions

Functions

Environment Variables

Regular Expressions

Virtual Object Configuration

Batching Testing

Recovery Scenarios

File System Operations

Database connections

Automation Object Model

Dynamic Handling of Object Repositories

QTP Performance Tips

****************************************

QTP Scripting

QTP Tests in VB Script orientation provides a real-time approach on Scripting. It explains Flat file scripts, Excel Scripts, GUI Scripts, Web scripts, Database scripts and xml scripts with syntax and examples.

****************************************

File System Scripts

Flat File Scripts

Database Scripts-I

Database Scripts-II

Excel Scripts

GUI Scripts

Web Scripts

Web Scripts -II

QTP Real-time Script Examples

Network Administration

System Administration

Power point Scripts

Word Scripts

XML Scripts

QTP Skills

Error Handling in QTP
****************************

VB Script for QTP

It explains VB Script in QTP orientation, It covers all most all VB Script Fundamentals and Features.

It describes, Variables, constants declarations, usage of operators, VB Script flow control statements, Procedures, Coding conventions, Regular Expressions, File system Operations, Database Operations etc..

****************************************

Scripting Languages Vs Programming Languages

VB Script Fundamentals & Features

Comments

VB Script Variables

VB Script Data Types

VB Script Operators

Input/Output Operations

VB Script Constants

VB Script Conditional Statements

Loop through Code

VB Script Statements

VB Script Procedures

VB Script Errors

VB Script Built-In Functions

User Defined Functions

Regular Expressions

VB Script Methods

VB Script Objects

VB Script Coding Conventions

VB Script Classes

VB Script Keywords

VB Script syntax rules and guidelines

VB Script General Examples

VB Script General Examples-II

VB Script Glossary

QTP Online Training

QTP Training (Basics to Advanced) by G C Reddy.

******************************************

QTP Framework

This section provides concepts on How to implement Automation Framework. It explains about Automation Infrastructure development, Resources creation, Driver script creation, Initialization script creation etc.

It describes data driven framework, keyword driven framework and Hybrid framework in detailed manner. It also provides Test estimations, Approvals, Reporting, Organizing and maintaining frameworks.

**********************************************

QTP Interview Questions

QTP Model Resumes
This section provides, Resume preparation guidelines for fresher as well as experienced. It provides some model QTP Resumes for reference.

QTP Job News
This section Provides QTP Job news weekly. Information can be collected by Employers, Consultants and employees. QTP Professionals can use this information and their resumes directly to Employer's and consultants mail ids.

QTP Certification

This section provides HP QTP Certification guidelines and model Questions, It useful for QTP test professionals for preparing Certification exam.
QTP Training Programs

This section provides information on variou QTP Training programs like QTP Basics program for beginners, Advanced program for working people, QTP Framework, and VB Script for QTP that conducted by gcreddy.com

Manual Testing Documents

This section Provides link to our another website gcreddy.net, there you can get Manual Testing Information like, Software Testing Guide, Manual Testing Interview question and answers, Test management guidelines, Test planning, Test design and other documents.

*******************************************

Quality Center

This Section Provides Quality Center Fundamentals and features; Site Administration, Creating Domains, Projects, and Users. Creating Requirements, Designing Manual & Automated Tests, Executing Manual and Automated Tests and Entering defects. Sending Defects directly from QTP Result window.

**********************************************************

LoadRunner

This section provides LoadRunner tool Fundamentals and Features; Vuser generator, Controller, Load Generator, Analysis and LoadRunner Interview Questions.

*********************************************************

QTP Other Topics

This section provides QTP Related articles and other information like, challenges in Test Automation using QTP, Migrating Test scripts from old version to New version, QTP trends, enhancements, New release information, Browser compatibility issues etc..

QTP Software Download Link

SQL Server Guide

Software Testing Documents

Documents on Unit Testing, Web Testing, Software Testing Artifacts, Software Test Process Etc..

QTP Training in Scripting Orientation

Software Test Metrics

2012-02-11T05:28:00.003-08:00

Software Test Metrics

I) Introduction

When we can measure what we are speaking about and express it in numbers, we know something about it; but when we cannot measure, when we cannot express it in numbers, our knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but we have scarcely, in your thoughts, advanced to the stage of science.

Why we need Metrics?

“We cannot improve what we cannot measure.”
“We cannot control what we cannot measure”

AND TEST METRICS HELPS IN

o    Take decision for next phase of activities
o    Evidence of the claim or prediction
o    Understand the type of improvement required
o    Take decision on process or technology change

II) Type of metrics

Base Metrics (Direct Measure)

Base metrics constitute the raw data gathered by a Test Analyst throughout the testing effort. These metrics are used to provide project status reports to the Test Lead and Project Manager; they also feed into the formulas used to derive Calculated Metrics.

Ex: # of Test Cases, # of Test Cases Executed

Calculated Metrics (Indirect Measure)

Calculated Metrics convert the Base Metrics data into more useful information. These types of metrics are generally the responsibility of the Test Lead and can be tracked at many different levels (by module, tester, or project).

Ex: % Complete, % Test Coverage

Base Metrics & Test Phases

o    # of Test Cases (Test Development Phase)
o    # of Test Cases Executed (Test Execution Phase)
o    # of Test Cases Passed (Test Execution Phase)
o    # of Test Cases Failed (Test Execution Phase)
o    # of Test Cases Under Investigation (Test Development Phase)
o    # of Test Cases Blocked (Test dev/execution Phase)
o    # of Test Cases Re-executed (Regression Phase)
o    # of First Run Failures (Test Execution Phase)
o    Total Executions (Test Reporting Phase)
o    Total Passes (Test Reporting Phase)
o    Total Failures (Test Reporting Phase)
o    Test Case Execution Time ((Test Reporting Phase)
o    Test Execution Time (Test Reporting Phase

Calculated Metrics & Phases

The below metrics are created at Test Reporting Phase or Post test Analysis phase
o    % Complete
o    % Defects Corrected
o    % Test Coverage
o    % Rework
o    % Test Cases Passed
o    % Test Effectiveness
o    % Test Cases Blocked
o    % Test Efficiency
o    1st Run Fail Rate
o    Defect Discovery Rate
o    Overall Fail Rate

III) Crucial Web Based Testing Metrics

Test Plan coverage on Functionality

Total number of requirement v/s number of requirements covered through test scripts.
• (No of requirements covered / total number of requirements) * 100
Define requirements at the time of Effort estimation

Example: Total number of requirements estimated are 46, total number of requirements tested 39; blocked 7…define what is the coverage?

Note: Define requirement clearly at project level

Test Case defect density

Total number of errors found in test scripts v/s developed and executed.
•    (Defective Test Scripts /Total Test Scripts) * 100

Example: Total test script developed 1360, total test script executed 1280, total test script passed 1065, total test script failed 215
So, test case defect density is
               215 X 100
        ---------------------------- = 16.8%
            1280

This 16.8% value can also be called as test case efficiency %, which is depends upon total number of test cases which uncovered defects

Defect Slippage Ratio

Number of defects slipped (reported from production) v/s number of defects reported during execution.
• Number of Defects Slipped / (Number of Defects Raised - Number of Defects Withdrawn)

Example: Customer filed defects are 21, total defect found while testing are 267, total number of invalid defects are 17

So, Slippage Ratio is
[21/ (267-17)] X 100 = 8.4%

Requirement Volatility

Number of requirements agreed v/s number of requirements changed.
•    (Number of Requirements Added + Deleted + Modified) *100 / Number of Original Requirements
•    Ensure that the requirements are normalized or defined properly while estimating
Example: VSS 1.3 release had total 67 requirements initially, later they added another 7 new requirements and removed 3 from initial requirements and modified 11 requirements

So, requirement Volatility is
        (7 + 3 + 11) * 100/67 = 31.34%
Means almost 1/3 of the requirement changed after initial identification

Review Efficiency

The Review Efficiency is a metric that offers insight on the review quality and testing
Some organization also use this term as “Static Testing” efficiency and they are aiming to get min of 30% defects in static testing

Review efficiency=100*Total number of defects found by reviews/Total number of project defects

Example: A project found total 269 defects in different reviews, which were fixed and test team got 476 defects which were reported and valid

So, Review efficiency is [269/(269+476)] X 100 = 36.1%

Efficiency and Effectiveness of Processes

•    Effectiveness: Doing the right thing. It deals with meeting the desirable attributes that are expected by the customer.

•    Efficiency: Doing the thing right. It concerns the resources used for the service to be rendered

Metrics for Software Testing

•    Defect Removal Effectiveness

DRE= Defects removed during development phase   x100%
                   Defects latent in the product

Defects latent in the product = Defects removed during development
                                                 Phase+ defects found later by user

•    Efficiency of Testing Process (define size in KLoC or FP, Req.)

Testing Efficiency= Size of Software Tested
                Resources used
----------------------------------------------------
Terms:

What is metric?
A measurement scale and the method used for measurement

What is measurement?
The process of assigning a number or category to an entity to describe an attribute of that entity.

What is measurement scale?
A scale that constrains the type of data analysis that can be performed on it.

What is measure?
The number or category assigned to an attribute of an entity by making a measurement.

Static Testing

2012-02-11T05:28:00.002-08:00

Static Testing

Important Terms:

Static techniques and the test process

dynamic testing, static testing, static technique

Review process

entry criteria, formal review, informal review, inspection, metric, moderator/inspection leader, peer review, reviewer, scribe, technical review, walkthrough.

Static analysis by tools

Compiler, complexity, control flow, data flow, static analysis

I) Phases of a formal review

1) Planning	Selecting the personal, allocating roles, defining entry and exit criteria for more formal reviews etc.
2) Kick-off	Distributing documents, explaining the objectives, checking entry criteria etc.
3) Individual preparation	Work done by each of the participants on their own work before the review meeting, questions and comments etc.
4) Review meeting	Discussion or logging, make recommendations for handling the defects, or make decisions about the defects etc.
5) Rework	Fixing defects found, typically done by the author Fixing defects found, typically done by the author
6) Follow-up	Checking the defects have been addressed, gathering metrics and checking on exit criteria

II) Roles and responsibilities

Manager	Decides on execution of reviews, allocates time in projects schedules, and determines if the review objectives have been met
Moderator	Leads the review, including planning, running the meeting, follow-up after the meeting.
Author	The writer or person with chief responsibility of the document(s) to be reviewed.
Reviewers	Individuals with a specific technical or business background. Identify defects and describe findings.
Scribe (recorder)	Documents all the issues, problems

III) Types of review

Informal review	No formal process, pair programming or a technical lead reviewing designs and code. Main purpose: inexpensive way to get some benefit.
Walkthrough	Meeting led by the author, ‘scenarios, dry runs, peer group’, open-ended sessions. Main purpose: learning, gaining understanding, defect finding
Technical review	Documented, defined defect detection process, ideally led by trained moderator, may be performed as a peer review, pre meeting preparation, involved by peers and technical experts Main purpose: discuss, make decisions, find defects, solve technical problems and check conformance to specifications and standards
Inspection	Led by trained moderator (not the author), usually peer examination, defined roles, includes metrics, formal process, pre-meeting preparation, formal follow-up process Main purpose: find defects.

Note: walkthroughs, technical reviews and inspections can be performed within a peer group-colleague at the same organization level. This type of review is called a “peer review”.

IV) Success factors for reviews

Each review has a clear predefined objective.
The right people for the review objectives are involved.
Defects found are welcomed, and expressed objectively.
People issues and psychological aspects are dealt with (e.g. making it a positive experience for the author).
Review techniques are applied that are suitable to the type and level of software work products and reviewers.
Checklists or roles are used if appropriate to increase effectiveness of defect identification.
Training is given in review techniques, especially the more formal techniques, such as inspection.
Management supports a good review process (e.g. by incorporating adequate time for review activities in project schedules).
There is an emphasis on learning and process improvement.

V) Cyclomatic Complexity

The number of independent paths through a program

Cyclomatic Complexity is defined as: L – N + 2P

L = the number of edges/links in a graph
N = the number of nodes in a graphs
P = the number of disconnected parts of the graph (connected components)

Alternatively one may calculate Cyclomatic Complexity using decision point rule
Decision points +1

Cyclomatic Complexity and Risk Evaluation
1 to 10a simple program, without very much risk
11 to 20 a complex program, moderate risk
21 to 50, a more complex program, high risk
> 50an un-testable program (very high risk)

Fundamentals of Testing

2012-02-11T05:28:00.001-08:00

Fundamentals of Testing

Important Terms:

Why testing necessary?

bug, defect, error, failure, mistake, quality, risk, software, testing and exhaustive testing.

What is testing?

code, debugging, requirement, test basis, test case, test objective

Testing principles

Fundamental test process

conformation testing, exit criteria, incident, regression testing, test condition, test coverage, test data, test execution, test log, test plan, test strategy, test summary report and testware.

The psychology of testing

independence.

I) General testing principles

Principles

A number of testing principles have been suggested over the past 40 years and offer general guidelines common for all testing.

Principle 1 – Testing shows presence of defects

Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

Principle 2 – Exhaustive testing is impossible

Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.

Principle 3 – Early testing

Testing activities should start as early as possible in the software or system development life cycle, and should be focused on defined objectives.

Principle 4 – Defect clustering

A small number of modules contain most of the defects discovered during pre-release testing, or are responsible for the most operational failures.

Principle 5 – Pesticide paradox

If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

Principle 6 – Testing is context dependent

Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.

Principle 7 – Absence-of-errors fallacy

Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations.

II) Fundamental test process

1) Test planning and control

Test planning is the activity of verifying the mission of testing, defining the objectives of testing and the specification of test activities in order to meet the objectives and mission.

It involves taking actions necessary to meet the mission and objectives of the project. In order to control testing, it should be monitored throughout the project. Test planning takes into account the feedback from monitoring and control activities.

2) Test analysis and design

Test analysis and design is the activity where general testing objectives are transformed into tangible test conditions and test cases.

Test analysis and design has the following major tasks:

Ø Reviewing the test basis (such as requirements, architecture, design, interfaces).

Ø Evaluating testability of the test basis and test objects.

Ø Identifying and prioritizing test conditions based on analysis of test items, the specification, behaviour and structure.

Ø Designing and prioritizing test cases.

Ø Identifying necessary test data to support the test conditions and test cases.

Ø Designing the test environment set-up and identifying any required infrastructure and tools.

3) Test implementation and execution

Ø Developing, implementing and prioritizing test cases.

Ø Developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts.

Ø Creating test suites from the test procedures for efficient test execution.

Ø Verifying that the test environment has been set up correctly.

Ø Executing test procedures either manually or by using test execution tools, according to the planned sequence.

Ø Logging the outcome of test execution and recording the identities and versions of the software under test, test tools and testware.

Ø Comparing actual results with expected results.

Ø Reporting discrepancies as incidents and analyzing them in order to establish their cause (e.g. a defect in the code, in specified test data, in the test document, or a mistake in the way the test was executed).

Ø Repeating test activities as a result of action taken for each discrepancy. For example, reexecution of a test that previously failed in order to confirm a fix (confirmation testing), execution of a corrected test and/or execution of tests in order to ensure that defects have not been introduced in unchanged areas of the software or that defect fixing did not uncover other defects (regression testing).

4) Evaluating exit criteria and reporting

Ø Checking test logs against the exit criteria specified in test planning.

Ø Assessing if more tests are needed or if the exit criteria specified should be changed.

Ø Writing a test summary report for stakeholders.

5) Test closure activities

Ø Checking which planned deliverables have been delivered, the closure of incident reports or raising of change records for any that remain open, and the documentation of the acceptance of the system.

Ø Finalizing and archiving testware, the test environment and the test infrastructure for later reuse.

Ø Handover of testware to the maintenance organization.

Ø Analyzing lessons learned for future releases and projects, and the improvement of test maturity.

III) The psychology of testing

Ø Tests designed by the person(s) who wrote the software under test (low level of independence).

Ø Tests designed by another person(s) (e.g. from the development team).

Ø Tests designed by a person(s) from a different organizational group (e.g. an independent test team) or test specialists (e.g. usability or performance test specialists).

Ø Tests designed by a person(s) from a different organization or company (i.e. outsourcing or certification by an external body).

software life cycle

2012-02-11T05:28:00.000-08:00

Testing throughout the software life cycle

Important Terms:

Software development models

COTS, interactive-incremental development model, validation, verification, V-model.

Test levels

Alfa testing, beta testing, component testing (also known as unit/module/program testing), driver, stub, field testing, functional requirement, non-functional requirement, integration, integration testing, robustness testing, system testing, test level, test-driven development, test environment, user acceptance testing.

Test types

Black box testing, code coverage, functional testing, interoperability testing, load testing, maintainability testing, performance testing, portability testing, reliability testing, security testing, specification based testing, stress testing, structural testing, usability testing, white box testing

Maintenance testing

Impact analysis, maintenance testing.

i) Software development models

a) V-model (sequential development model)

Although variants of the V-model exist, a common type of V-model uses four test levels,

corresponding to the four development levels.

The four levels used in this syllabus are:

component (unit) testing;
integration testing;
system testing;
acceptance testing.

b) Iterative-incremental development models

Iterative-incremental development is the process of establishing requirements, designing, building and testing a system, done as a series of shorter development cycles. Examples are: prototyping, rapid application development (RAD), Rational Unified Process (RUP) and agile development models.

c) Testing within a life cycle model

In any life cycle model, there are several characteristics of good testing:

For every development activity there is a corresponding testing activity.
Each test level has test objectives specific to that level.
The analysis and design of tests for a given test level should begin during the corresponding development activity.
Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle.

ii) Test levels

a) Component testing

Component testing searches for defects in, and verifies the functioning of, software (e.g. modules, programs, objects, classes, etc.) that are separately testable.

Component testing may include testing of functionality and specific non-functional characteristics, such as resource-behaviour (e.g. memory leaks) or robustness testing, as well as structural testing (e.g. branch coverage).

One approach to component testing is to prepare and automate test cases before coding. This is called a test-first approach or test-driven development.

b) Integration testing

Integration testing tests interfaces between components, interactions with different parts of a system, such as the operating system, file system, hardware, or interfaces between systems.

Component integration testing tests the interactions between software components and is done after component testing;

System integration testing tests the interactions between different systems and may be done after system testing.

Testing of specific non-functional characteristics (e.g. performance) may be included in integration testing.

c) System testing

System testing is concerned with the behaviour of a whole system/product as defined by the scope of a development project or programme.

In system testing, the test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing.

System testing may include tests based on risks and/or on requirements specifications, business processes, use cases, or other high level descriptions of system behaviour, interactions with the operating system, and system resources.

System testing should investigate both functional and non-functional requirements of the system.

d) Acceptance testing

Acceptance testing is often the responsibility of the customers or users of a system; other stakeholders may be involved as well.

The goal in acceptance testing is to establish confidence in the system, parts of the system or specific non-functional characteristics of the system

Contract and regulation acceptance testing

Contract acceptance testing is performed against a contract’s acceptance criteria for producing custom-developed software. Acceptance criteria should be defined when the contract is agreed. Regulation acceptance testing is performed against any regulations that must be adhered to, such as governmental, legal or safety regulations.

Alpha and beta (or field) testing

Alpha testing is performed at the developing organization’s site. Beta testing, or field testing, is performed by people at their own locations. Both are performed by potential customers, not the developers of the product.

iii) Test types

a) Testing of function (functional testing)

The functions that a system, subsystem or component are to perform may be described in work products such as a requirements specification, use cases, or a functional specification, or they may be undocumented. The functions are “what” the system does.

A type of functional testing, security testing, investigates the functions (e.g. a firewall) relating to detection of threats, such as viruses, from malicious outsiders. Another type of functional testing, interoperability testing, evaluates the capability of the software product to interact with one or more specified components or systems.

b) Testing of non-functional software characteristics (non-functional testing)

Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability testing. It is the testing of “how” the system works.

Non-functional testing may be performed at all test levels.

c) Testing of software structure/architecture (structural testing)

Structural (white-box) testing may be performed at all test levels. Structural techniques are best used after specification-based techniques, in order to help measure the thoroughness of testing through assessment of coverage of a type of structure.

Structural testing approaches can also be applied at system, system integration or acceptance testing levels (e.g. to business models or menu structures).

d) Testing related to changes (confirmation testing (retesting) and regression testing)

After a defect is detected and fixed, the software should be retested to confirm that the original defect has been successfully removed. This is called confirmation. Debugging (defect fixing) is a development activity, not a testing activity.

Regression testing is the repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s). It is

performed when the software, or its environment, is changed.

Regression testing may be performed at all test levels, and applies to functional, non-functional and structural testing.

iv) Maintenance testing

Once deployed, a software system is often in service for years or decades. During this time the system and its environment are often corrected, changed or extended.

Modifications include planned enhancement changes (e.g. release-based), corrective and

emergency changes, and changes of environment,

Maintenance testing for migration (e.g. from one platform to another) should include operational tests of the new environment, as well as of the changed software.

Maintenance testing for the retirement of a system may include the testing of data migration or archiving if long data-retention periods are required.

Maintenance testing may be done at any or all test levels and for any or all test types.

ISTQB Foundation Syllabus

2012-02-09T21:32:00.004-08:00

ISTQB Foundation Syllabus
(Version 2011)

1. Fundamentals of Testing (07 marks)
1.1 Why testing necessary?
1.2 What is testing?
1.3 Testing principles
1.4 Fundamental test process
1.5 The psychology of testing

2. Testing throughout the software life cycle (06 marks)

2.1 Software development models
2.2 Test levels
2.3 Test types
2.4 Maintenance testing

3) Static Techniques (03 marks)
3.1 Static techniques and the test process
3.2 Review process
3.3 Static analysis by tools

4) Test Design Techniques(12 marks)
4.1 The test development process
4.2 Categories of test design techniques
4.3 Specification-based or black box techniques
4.4 Structure-based or white box techniques
4.5 Experience-based techniques
4.6 Choosing test techniques

5) Test management(08 marks)
5.1 Test organization
5.2 Test planning and estimation
5.3 Test progress monitoring and control
5.4 Configuration management
5.5 Risk and testing
5.6 Incident Management

6) Tool support for testing (04 marks)
6.1 Types of test tool
6.2 Effective use of tools: potential benefits and risks
6.3 introducing a tool into an organization

ISTQB Foundation

2012-02-09T21:32:00.003-08:00

ISTQB Foundation Level Exam

"CTFL" for "Certified Tester Foundation Level"

About ISTQB:

The ISTQB was officially founded as an International Software Testing Qualifications Board in Edinburgh in November 2002. The international recognition of the certification is due to the participation of many countries as opposed to any country-specific scheme.

The main aims, tasks, and responsibilities of the ISTQB are:

To define and maintain all aspects of the ISTQB Certified Tester scheme such as core syllabi, examination structure, regulations, and certification guidelines.
To ensure that each successful participant receive the "ISTQB Certified Tester" certificate (or the local variant with the added "ISTQB compliant" logo).
To promote testing as a profession, increase the number of qualified testers, and develop a common body of understanding and knowledge about testing, through the syllabus & terminology.
To approve, monitor compliance, or expel national boards.

Foundation Level:

The Foundation Level qualification is aimed at anyone involved in software testing. This includes people in roles such as testers, test analysts, test engineers, test consultants, test managers, user acceptance testers and software developers. This Foundation Level qualification is also appropriate for anyone who wants a basic understanding of software testing, such as project managers, quality managers, software development managers, business analysts, IT directors and management consultants. Holders of the Foundation Certificate will be able to go on to a higher level software testing qualification.

Exam Structure:

The Foundation Level exam comprises 40 multiple-choice questions, with a scoring of 1 point for each correct answer, a pass mark of 65% (26 or more points) and a duration of 60 minutes (or 75 minutes for candidates taking exams that are not in their native or local language).

Foundation Exam Info:

o    All questions must be written in US English.
o    Use good grammar, punctuation, and spelling.
o    Questions must be based on the syllabus but should also be consistent with the ‘real world’.
o    Type of the exam: Objective (Multiple choices)
o    Total no of Questions: 40
o    Pass marks: 26 (65%), No negative marks
o    Examination fees: 4000
o    Re-examination fees: 2500
o    Exam duration: 75 Minutes
o    Mode of Exam: Online
o    ISTQB Foundation Level Certification Validity: Lifetime, where as Advanced Certification Validity is 3 years.
o    No pre-requisites for ISTQB Foundation Level Certification, where as Advanced Certification requires ‘Foundation Certification and 2 years of work experience’.
o    160000 ISTQB Certifications by Sep 2011

Types of multiple-choice questions

Within the multiple-choice format, questions can be presented in different ways. For example, the amount of information presented in a question’s stem can be limited or extensive. Also, a question writer can include written code within the stem, specifically for example, when writing questions to test knowledge of white box techniques.
Following are examples of the type of multiple-choice items to be used in any ISTQB qualification. Correct answers should always be the first option.

Basic Type Questions

The basic multiple-choice question has a short stem and a single correct response. A limited amount of information is presented in the stem, and a single set of response options is presented to the candidates. The following example of a basic multiple-choice question is targeted to assess knowledge of static testing at K1 cognitive level of application.
Example:

What does a tester do during "Static testing"?

a) Reviews requirements and compares them with the design
b) Runs the tests on the exact same setup each time
c) Executes test to check that all hardware has been set up correctly
d) Runs the same tests multiple times, and checks that the results are statistically meaningful

Roman Type Questions

Another variation of the basic multiple-choice question is the Roman type. In this format, the candidate is presented with several statements; each proceeded by either a Roman numeral or a letter of the alphabet. This differs from the multiple-choice questions already discussed in that the response options may require the candidate to know or derive several pieces of related information. The task for the candidate is to select the option that represents the correct combination of statements; as shown in the following example:

Which of the following answers reflect when Regression testing should normally be performed?

A. Every week
B. After the software has changed
C. On the same day each year
D. When the environment has changed
E. Before the code has been written

1) B & D are true, A, C & E are false
2) A & B are true, C, D & E are false
3) B, C & D are true, A & E are false
          4) B is true, A, C, D & E are false

ISTQB Advanced Level

2012-02-09T21:32:00.002-08:00

ISTQB Advanced Level Exam

"CTAL" for "Certified Tester Advanced Level"

Advanced Level:

The Advanced Level qualification is aimed at people who have achieved an advanced point in their careers in software testing. This includes people in roles such as testers, test analysts, test engineers, test consultants, test managers, user acceptance testers and software developers. This Advanced Level qualification is also appropriate for anyone who wants a deeper understanding of software testing, such as project managers, quality managers, software development managers, business analysts, IT directors and management consultants. To receive Advanced Level certification, candidates must hold the Foundation Certificate and satisfy the Exam Board which examines them that they have sufficient practical experience to be considered Advanced Level qualified. Refer to the relevant Exam Board to understand their specific practical experience criteria.

Exam Details:

The Advanced Level exams comprise 65 multiple-choice questions, with different scoring (from 1 to 3 points) for the correct answer according to the question’s level of difficulty, a pass mark of 65% (65 or more points), and a duration of 180 minutes (or 225 minutes for candidates taking exams that are not in their native or local language).
The breakdown of the exam questions per K-level is done according to international guidelines and exam content reviews are periodically conducted to ensure consistency.

The Exam Sub Levels::

Technical Test Analyst
Test Analyst
Test Manager

A single syllabus exists for all the three sublevels. There is an separate paper for each sub-level and each Paper is of 180 Minutes Duration. Sub-Levels can be taken up in any order. An individual Certificate is granted on successful completion of each sub-level.
o    Time Duration: 180 Min. for each sub-level
o    Total No. of Question: 65 for each sub-level
o    Total Marks: 100 Marks (1 Mark, 2 marks & 3 mark questions)(Distribution not pre-specified)
o    Passing Criteria: 65%

Eligibility:

For Bachelor’s Degree (or higher) Holders in Computer Science or related fields
•    Foundation Level Clearance
•    24 Months of Testing Experience in IT, Testing,
Development, QA, Engineering or related fields (For any 2 sub-levels)
•    Min. 36 Months of experience mandatory for Adv. Complete Certification(For all 3 sub-levels)
For Non Bachelor ’s Degree (or higher) Holders in Computer Science or related fields
•    Foundation Level Clearance
•    60 Months of Testing Experience in IT, Testing,
Development, QA, Engineering or related fields

Advanced Level Test Manager

Advanced Level Test Management professionals should be able to:

•    Define the overall testing goals and strategy for the systems being tested
•    Plan, schedule and track the tasks
•    Describe and organize the necessary activities
•    Select, acquire and assign the adequate resources to the tasks
•    Select, organize and lead testing teams
•    Organize the communication between the members of the testing teams, and between the testing teams and all the other stakeholders
•    Justify the decisions and provide adequate reporting information where applicable

Advanced Level Test Analyst

Advanced Level Test Analysts should be able to:

•    Structure the tasks defined in the test strategy in terms of business domain requirements
•    Analyze the system in sufficient detail to meet the user quality expectations
•    Evaluate the system requirements to determine domain validity
•    Prepare and execute the adequate activities, and report on their progress
•    Provide the necessary evidence to support evaluations
•    Implement the necessary tools and techniques to achieve the defined goals

Advanced Level Technical Test Analyst

Advanced Level Technical Test Analysts should be able to:
•    Structure the tasks defined in the test strategy in terms of technical requirements
•    Analyze the internal structure of the system in sufficient detail to meet the expected quality level
•    Evaluate the system in terms of technical quality attributes such as performance, security, etc.
•    Prepare and execute the adequate activities, and report on their progress
•    Conduct technical testing activities
•    Provide the necessary evidence to support evaluations
•    Implement the necessary tools and techniques to achieve the defined goals

ISTQB Advanced Level Syllabus

2012-02-09T21:32:00.001-08:00

ISTQB Advanced Level Syllabus

1. Basic Aspects of Software Testing
1.1 Introduction
1 .2 Testing in the Software Lifecycle
1 .3 Specific Systems
1.3.1 Systemsof Systems
1.3.2 Safety Critical Systems
1 .4 Metrics & Measurement
1.5 Ethics

2. Testing Processes
2.1 Introduction
2.2 Test Process Models
2.3 Test Planning & Control
2.4 Test Analysis & Design
2.4.1 Identification of Test Conditions
2.4.2 Creation of Test Cases
2.5 Test Implementation & Execution
2.5.1 Test Implementation
2.5.2 Test Execution
2.6 Evaluating Exit Criteria and Reporting
2.7 Test Closure Activities

3. Test Management
3.1 Introduction
3.2 Test Management Documentation
3.2.1 Test Policy
3.2.2 Test Strategy
3.2.3 MasterTestPlan
3.2.4 Level Test Plan
3.3 Test Plan Documentation Templates
3.4 Test Estimation
3.5 Scheduling Test Planning
3.6 Test Progress Monitoring & Control
3.7 Business Value of Testing
3.8 Distributed, Outsourced & Insourced Testing
3.9 Risk-Based Testing
3.9.1 Introduction to Risk-Based Testing
3.9.2 Risk Management
3.9.3 Risk Management in the Lifecycle
3.10 Failure Mode and Effects Analysis
3.10.1 Areas of Application
3.10.2 Implementation Steps
3.10.3 Benefits & Costs
3.11 Test Management Issues
3.11.1 Test Management Issues for Exploratory Testing
3.11.2 Test Management Issues for Systems of Systems
3.11.3 Test Management Issues for Safety Critical Systems
3.11.4 Other Test Management Issues

4. Test Techniques
4.1 Introduction
4.2 Specification-based
4.3 Structure-based
4.4 Defect- and Experience-based
4.4.1 Defect-based techniques
4.4.2 Experienced-based techniques
4.5 StaticAnalysis
4.5.1 Static Analysis of Code
4.5.2 Static Analysis of Architecture
4.6 Dynamic analysis
4.6.1 Overview
4.6.2 Detecting Memory Leaks
4.6.3 Detecting Wild Pointers
4.6.4 Analysis of Performance

5. Testing of Software Characteristics
5.1 Introduction
5.2 Quality attributes for domain testing
5.2.1 Accuracy Testing
5.2.2 Suitability Testing
5.2.3 Interoperability Testing
5.2.4 Functional Security Testing
5.2.5 Usability Testing
5.2.6 Accessibility Testing
5.3 Quality attributes for technical testing
5.3.1 Technical Security Testing
5.3.2 Reliability Testing
5.3.3 Efficiency Testing
5.3.4 Maintainability Testing
5.3.5 Portability Testing

6. Reviews
6.1 Introduction
6.2 The Principles of Reviews
6.3 Types of Reviews
6.3.1 Management review and audit
6.3.2 Reviews of particular work products
6.3.3 Performing a formal review
6.4 Introducing Reviews
6.5 Success Factors for Reviews

7. Incident Management
7.1 Introduction
7.2 When can a Defect be detected’?
7.3 Defect Lifecycle
7.3.1 Step 1: Recognition
7.3.2 Step 2: Investigation
7.3.3 Step3:Action
7.3.4 Step 4: Disposition
7.4 Defect Fields
7.5 Metrics & Incident Management
7.6 Communicating Incidents

8. Standards & Test Improvement Process
8.1 Introduction
8.2 Standards Considerations
8.2.1 General Aspects on Standards
8.2.2 International Standards
8.2.3 National Standards
8.2.4 Domain Specific Standards
8.2.5 Other Standards
8.3 Test Improvement Process
8.3.1 Introduction to Process Improvement
8.3.2 Types of Process Improvement
8.4 Improving the Test Process
8.5 Improving the Test Process with TMM
8.6 Improving the Test Process with TPI
8.7 Improving the Test Process with CTP (CTP)
8.8 Improving the Test Process with STEP
8.9 Capability Maturity Model Integration, CMMI

9. Test Tools & Automation
9.1 Introduction
9.2 Test Tool Concepts
9.2.1 Cost benefits and Risks of Test Tools and Automation
9.2.2 Test Tool Strategies
9.2.3 Integration & Information Interchange Between Tools
9.2.4 Automation Languages: Scripts, Script Language
9.2.5 The Concept of Test Oracles
9.2.6 Test Tool Deployment
9.2.7 Usage of Open Source Test Tools
9.2.8 Developing Your Own Test Tool
9.2.9 Test Tool Classification
9.3 Test Tools Categories
9.3.1 Test Management Tools
9.3.2 Test Execution Tools
9.3.3 Debugging & Troubleshooting Tools
9.3.4 Fault Seeding & Fault Injection Tools
9.3.5 Simulation & Emulation Tools
9.3.6 Static and Dynamic Analysis Tools
9.3.7 Keyword-Driven Test Automation
9.3.8 Performance Testing Tools
9.3.9 Web Tools

10. People Skills—Team Composition
10.1 Introduction
10.2 Individual Skills
10.3 Test Team Dynamics
10.4 Fitting Testing Within an Organization
10.5 Motivation
10.6 Communication

ISTQB

2012-02-09T21:32:00.000-08:00

ISTQB Certification

ISTQB Foundation Exam Details

ISTQB Foundation Level Syllabus

ISTQB Foundation Level Model Questions

ISTQB Advanced Exam Details

ISTQB Advanced Level Syllabus

ISTQB Advanced Level Model Questions

ISTQB Expert Level Exam Details

ISTQB Expert Level Syllabus

Test Principles and Concepts

2012-02-08T21:40:00.004-08:00

Software Test Principles

1.Which of these is NOT part of the Cost of Quality?
a) Failure costs
b) Error Detection costs
c) RTF costs
d) Error prevention costs

2.The term "fit for use" refers to whose view of quality?
a) Supplier's
b) Auditor's
c) Producer's
d) Customer's

3.Which of these is a challenge/obstacle to implementing testing in an organization?
a) People think testing is not essential for delivery; testing is often unstructured and subjective
b) Testing is error prone; testing is too expensive
c) Testing is often not managed properly; the mindset that you can test quality into software
d) All of the above

4."PDCA", or "Plan, Do, Check, Act" is also known as

a) The Shewhart cycle
b) The Deming Wheel
c) both
d) neither

5.What are the three main categories defects can fall into?

a) Wrong, Missing, and Extra
b) Regression, Unit, and Integration
c) FUBAR, really FUBAR, and uber-FUBAR
d) display, processing, output

6.Which of these is NOT an important part of a Test Strategy?

a) The procedure for logging defects
b) how you will validate that the system meets user requirements
c) how you will validate the software at each stage of development
d) how you will use test data to examine the behavior of the system

7.Which of these are good ways to raise management's awareness of the importance of testing?

a) Make sure management knows what they get for the money they spend on testing
b) relay other benefits of testing (shorter test times, higher quality software)
c) Collect and distribute articles about testing
d) all of the above

8.Continuous process improvement only works if you:

a) Monitor performance of prior improvement initiatives
b) base improvement efforts on the organization's needs and business goals
c) enforce the newly developed processes
d) all are needed

9.Which is a more effective approach to risk mitigation?

a) Test based on user requirements
b) Test based on system specifications
c) Test more heavily in areas deemed higher risk
d) all of the above

10.Establishing a testing policy should include four main criteria. A definition of testing, the testing system, evaluation methods, and ________?

a) Standards against which testing will be measured
b) Data Requirements for a typical project
c) Templates for deliverables generated by the test group
d) All of the above

11.Which of these is the most effective method for establishing a testing policy?

a) Information Services Consensus Policy
b) Users Meeting
c) Industry Standard
d) Management Directive

12.During what phase of the project should you START thinking about Testing Scenarios?

a) Requirements
b) Maintenance
c) Coding
d) Design

13.What is the appropriate timing for Static, Structural tests?

a) Analysis and design only
b) testing phase
c) as early as possible and in every phase thereafter
d) not until the coding phase

14.Test coverage tools are useful starting in which phase?

a) Any phase
b) Analysis and Design
c) Testing (functional testing)
d) Coding (unit testing)

15.A Test Factor is:

a) The risk or issue that needs to be addressed during testing
b) a variable in a test script
c) an error inserted by programmers to measure the effectiveness of testing
d) part of the audit trail

16.means that the data entered, processed, and output by the application is accurate and complete.

a) Completeness
b) File integrity
c) Correctness
d) Audit trail

17.Validating that the right file is used and the data on that file is correct and in the correct sequence is known as:

a) Structural analysis
b) Data dictionary validation
c) Black box testing
d) File integrity testing

18._____________ can substantiate the processing that has occurred and allow analysts to reconstruct what happened at any point in a transaction.

a) Continuity of Processing
b) None of these
c) Data Dictionaries
d) Audit Trails

19.Failover testing at Chase is verification that ___________ is intact

a) Continuity of processing
b) audit trails
c) maintainability
d) both A and C

20.Processing time and "up time" goals are examples of

a) Statistical process control
b) metrics
c) service levels
d) workbenches

21.Access control testing is also known as

a) Error handling
b) Security testing
c) Static testing
d) Fault based testing

22.Audits to ensure that the system is designed in accordance with organization strategy, policies, procedures, and standards are designed to test which quality factor?

a) Best practices
b) correctness
c) maintainability
d) compliance

23.An application which performs its intended function with the required precision over an extended period of time has this quality factor:

a) Validity
b) ease of use
c) service level
d) reliability

24.If it is difficult to locate and fix errors in a program, that program is missing which quality factor?

a) Coupling
b) maintainability
c) portability
d) ease of operation

25.The quality factor "ease of use" is best measured by doing what type of testing?

a) Performance test
b) manual support test
c) white box test
d) acceptance test

26.Portability refers to

a) How easy it is to transfer a program to other hardware or OS
b) whether it's possible to uninstall the program
c) both of these
d) neither of these

27.The effort required to interconnect components of an application to other applications for data transfer is:

a) Coupling
b) I/O
c) flowchart analysis
d) system testing

28.If defects are hard to find, that's a sign that...

a) Test coverage is inadequate
b) there are errors in the test scripts
c) neither of these
d) either of these

29. Which way(s) can lower the cost of testing without reducing it's effectiveness?

a) Phase containment
b) the V concept of testing
c) testing the artifacts of each development phase, not just the program itself
d) all of the above

30.________ ensures that we designed and built the right system, while _________ ensures that the system works as designed.

a) Validation, verification
b) white box testing, black box testing
c) verification, validation
d) the project manager, the test team

31.Walkthroughs, peer reviews, and other structural tests tend to be __________ tasks

a) Verification
b) quality control
c) quality assurance
d) validation

32.Input, Procedures to DO, Procedures to CHECK, and Output are the four components of the:

a) Workbench concept
b) test phase
c) reporting cycle
d) Shewhart cycle

33.Which of these are considerations when developing testing methodologies?

a) The type of development project, the type of software system
b) tactical risks, project scope
c) both of these
d) neither of these

34.Deriving test cases based on known program structure and logic is...

a) Control testing
b) white box testing
c) black box testing
d) fault-driven testing

35.Functional testing that simulates the end user's actions is known as...

a) Access control testing
b) performance testing
c) black box testing
d) structural testing

36.Breaking variables into chunks that should have the same expected results is:

a) Workbench
b) usability testing
c) equivalence partitioning
d) data mapping

37.Developing tests based on where you think the program's weak points are is known as

a) Error-handling testing
b) risk based testing
c) error guessing
d) negative testing

38.Top-down and Bottom-up are two ways to approach

a) Incremental testing
b) thread testing
c) boundary analysis
d) none of these

39.An end-to-end, task based test that uses integrated components of a system is a...

a) Performance test
b) thread test
c) unit test
d) structural test

40.Which is a benefit of having a user committee develop the company's test policy?

a) All involved parties participate and sign off
b) outside users learn the options and costs associated with testing
c) testing and quality are seen as organization-wide responsibilities, not just IT
d) all of these

41.Which of these types of reviews is NOT an effective phase containment mechanism?

a) Post implementation review
b) decision point review
c) phase end review
d) in process review

42.Which of these was not a Quality professional?

a) Deming
b) Townsend
c) Juran
d) Pareto

43.The successful implementation of a quality improvement program will have what long-term effect on productivity?

a) There is no relationship between quality and productivity
b) it will lower productivity
c) it will raise productivity
d) productivity will remain the same

44.Which of these are some of Deming's 7 Deadly Management Diseases?

a) Lack of constancy of purpose and emphasis on short-term profits
b) evaluation of performance or annual review of performance
c) running an organization on visible figures alone and excessive costs of warranty
d) all of these

45.The scientific method is

a) Relevant to developers
b) a logical, systematic approach to processes
c) useful when developing test cases
d) all of these

46.Deming's biggest contribution to the quality profession is:

a) Zero Defects Day
b) Using slogans and targets to motivate the work force
c) focusing on process improvement, not the product itself
d) all of these

47.Instituting pride in workmanship and eliminating numerical quotas were suggestions for management created by

a) Pareto
b) Shewhart
c) Deming
d) Juran

48.Which is an important source of data for Continuous Process Improvement?

a) Defect databases
b) Post-mortems
c) Neither of these
d) both of these

49.Who should NOT participate in testing?

a) End users
b) developers’
c) management
d) all should participate

50.According to Deming, 90% of defects are attributable to:

a) Vague user requirements
b) programmer error
c) process problems
d) communication errors

51.Which of these are NOT test factors

a) Error guessing, incremental testing, boundary analysis
b) compliance, reliability, access control
c) correctness, audit trail, continuity of processing
d) maintainability, portability, ease of operation

52.A test strategy matrix does not include:

a) Test phases
b) risks
c) test factors
d) script mapping

53.Of the four options listed below, which is able to detect an infeasible path?

a) Performance testing
b) black box testing
c) structural testing
d) manual support testing

54.Black box testing, thread testing, and incremental testing are all kinds of:

a) Dynamic testing
b) static analysis
c) both of these
d) neither of these

55.Which catches errors earlier, verification or validation?

a) Verification
b) Validation
c) Neither
d) Both

56.Mapping requirements to tests in order to prove that the system functions as designed is known as:

a) Data mapping
b) requirement validation
c) requirements tracing
d) metrics gathering

57.Who should not be allowed to participate in and contribute to the improvement of processes?

a) Line workers
b) nobody - all should be allowed
c) the author of the original process
d) management

58.Improving weaknesses in a process you just piloted is an example of which piece of the Shewhart cycle?

a) Do
b) Act
c) Plan
d) Check

configuration management

2012-02-08T21:40:00.003-08:00

Configuration Management

Configuration management

Configuration management is unique identification, controlled storage, change
control, and status reporting of selected intermediate work products, product
components, and products during the life of a system.

Configuration Management Planning

Configuration Management starts during the early phases of the project All products of the software process may have to be managed

Example:
o    Specifications
o    code
o    Designs
o    Programs
o    Test data
o    User manuals

Thousands of separate documents may be generated for a large software system

Configuration Management Plan

o    Defines the types of documents to be managed and a document naming scheme
o    Defines who takes responsibility for the CM procedures and creation of “baselines”
o    Defines policies for change control and version management
o    Defines the CM records which must be maintained
o    Describes the tools which should be used to assist the CM process and any limitations on their use

Configuration item identification

o    Large projects typically produce thousands of documents which must be uniquely identified. Some of these documents must be maintained for the lifetime of the software
o    Document naming scheme should be defined so that related documents have related names.
o    A hierarchical scheme with multi-level names is probably the most flexible approach

The configuration database

All CM information should be maintained in a configuration database. This should allow queries about configurations to be answered
o    Who has a particular system version?
o    What platform is required for a particular version?
o    What versions are affected by a change to component X?
o    How many reported faults in version T?
o    The CM database should preferably be linked to the software being managed

Change Management

Software systems are subject to continual change requests
o    From users
o    From developers
o    From market forces

Change management is concerned with keeping track of these changes and ensuring that they are implemented in the most cost-effective way

Version and Release Management

o    Invent identification scheme for system versions
o    Plan when new system version is to be produced
o    Ensure that version management procedures and tools are properly applied
o    Plan and distribute new system releases

Versions/Variants/Releases

Version: An instance of a system which is functionally distinct in some way from other system instances

Variant: An instance of a system which is functionally identical but non-functionally distinct from other instances of a system

Release: An instance of a system which is distributed to users outside of the development team

Version identification

o    Procedures for version identification should define an unambiguous way of identifying component versions
o    Three basic techniques for component identification
o    Version numbering
o    Attribute-based identification
o    Change-oriented identification

Release management

o    Releases incorporate changes forced on the system by errors discovered by users and by hardware changes
o    They also incorporate new system functionality
o    Release planning is concerned with when to issue a system version as a release

System releases

o    Not just a set of executable programs, may also include Compilers
o    configuration files defining how the release is configured for a particular installation
o    Data files needed for system operation
o    An installation program or shell script to install the system on target hardware
o    Electronic and paper documentation
o    Packaging and associated publicity
o    Systems are now normally released on CD-ROM or as downloadable installation files from the Web

Release problems

o    Customer may not want a new release of the system
o    They may be happy with their current system as the new version may provide unwanted functionality
o    Release management must not assume that all previous releases have been accepted
o    All files required for a release should be re-created when a new release is installed

Release creation
o    Release creation involves collecting all files and documentation required to create a system release
o    Configuration descriptions have to be written for different hardware and installation scripts have to be written
o    The specific release must be documented to record exactly what files were used to create it
•    This allows it to be re-created if necessary

System building

o    The process of compiling and linking software components into an executable system
o    Different systems are built from different
combinations of components
o    Invariably supported by automated tools that are driven by ‘build scripts’

System building problems

o    When there are many hundreds of components making up a system, it is easy to miss one out; this should normally be detected by the linker.
o    A system built with the wrong version may work initially but fail after delivery
o    Embedding absolute names in code almost always causes problems as naming conventions differ from place to place
o    Different compiler versions may actually generate different code and the compiled component will exhibit different behaviour

Key points

o    Configuration management is the management of system change to software products
o    A formal document naming scheme should be established and documents should be managed in a database
o    The configuration database should record information about changes and change requests
o    A consistent scheme of version identification should be established using version numbers, attributes or change sets
o    System releases include executable code, data, configuration files and documentation
o    System building involves assembling components into a system
-------------------------------------------------
Configuration Management FAQ

Types of Test Tools

2012-02-08T21:40:00.002-08:00

Tool support for software testing

Important Terms:

Types of test tool

Configuration management tool, debugging tool, dynamic analysis tool, incident management tool, load testing tool, modeling tool, monitoring tool, performance testing tool, probe effect, requirement management tool, review tool, static analysis tool, stress testing tool, test comparator, test data preparation tool, test design tool, test harness, test execution tool, test management tool, unit test framework tool.

Effective use of tools: potential benefits and risks

Data driven (testing), keyword-driven (testing), scripting language

introducing a tool into an organization

Types of test tool

management of testing and tests	Requirement management tools Incident management tools Configuration management tools
Static testing	Review tools Static analysis tools (D) Modeling tools (D)
Test specification	§ Test design tools § Test data preparation tools
Test execution and logging	Test execution tools Test harness/unit test framework tools (D) Test comparators Coverage measurement tools (D) Security tools
Performance and monitoring	Dynamic analysis tools Performance/Load/Stress Testing tools Monitoring tools
Specific application areas	Special tools for web-based applications Special tools for specific development flat forms Special tools for embedded systems
Tool support using other tools

Test Tools and their purposes

Requirement management tools	Store requirements, check for consistency, allow requirements to be prioritized, trace changes, coverage of requirements etc.
Incident management tools	Store and manage incident reports, facilitating prioritization, assessment of actions to people and attribution of status etc.
Configuration management tools	Store information about versions and builds of software and testware; enable traceability between testware and software work products etc.
Review tools	Store information, store and communicate review comments etc.
Static analysis tools (D)	The enforcement of coding standards, the analysis of structures and dependencies, aiding in understanding the code etc.
Modeling tools (D)	Validate models of the software, find defects in data model, state model or an object model etc.
Test design tools	Generate test inputs or executable tests, generate expected out comes etc.
Test data preparation tools	Preparing test data, Manipulate databases, files or data transmissions to set up test data etc.
Test execution tools	Record tests, Automated test execution, use inputs and expected outcomes, compare results with expected outcomes, repeat tests, dynamic comparison, manipulate the tests using scripting language etc.
Test harness/unit test framework tools (D)	Test components or part of a system by simulating the environment, provide an execution framework in middleware etc.
Test comparators	Determine differences between files, databases or test results post-execution comparison, may use test oracle if it is automated etc.
Coverage measurement tools (D)	Measure the percentage of specific types of code structure (ex: statements, branches or decisions, and module or function calls)
Security tools	Check for computer viruses and denial of service attacks, search for specific vulnerabilities of the system etc.
Dynamic analysis tools (D)	Detect memory leaks, identify time dependencies and identify pointer arithmetic errors.
Performance/Load/Stress Testing tools	Measure load or stress, Monitor and report on how a system behaves a variety of simulated usage conditions, simulate a load on an application/a database/or a system environment, repetitive execution of tests etc.
Monitoring tools	Continuously analyze, verify and report on specific system resources; store information about the version and build of the software and testware, and enable traceability.
Tool support using other tools	Some tools use other tools (Ex: QTP uses excel sheet and SQL tools)

Potential benefits and risks of tool support for testing

Benefits:

Repetitive work is reduced
Greater consistency and repeatability
Objective assessment
Ease of access to information about tests or testing

Risks:

Unrealistic expectations for the tool
Underestimating the time and effort needed to achieve significant and continues benefits from the tool
Underestimating the effort required to maintain the test assets generated by the tool
Over-reliance on the tool

Special considerations for some types of tools

Following tools have special considerations

ü Test execution tools

ü Performance testing tools

ü Static testing tools

ü Test management tools

Introducing a tool into an organization

The following factors are important in selecting a tool:

Assessment of the organization maturity
Identification of the areas within the organization where tool support will help to improve testing process
Evaluation of tools against clear requirements and objective criteria
Proof-of-concept to see whether the product works as desired and meets the requirements and objectives defined for it
Evaluation of the vendor (training, support and other commercial aspects) or open-source network of support
Identifying and planning internal implementation (including coaching and mentoring for those new to the use of the tool)

The objectives for a pilot project for a new tool

To learn more about the tool
To see how the tool would fit with existing processes or documentation
To decide on standard ways of using the tool that will work for all potential users
To evaluate the pilot project agonist its objectives

Successes factors for the deployment of the new tool within an organization

Rolling out the tool to the rest of the organization incrementally
Adapting and improving process to fit with the use of the tool
Providing training and coaching/mentoring for new users.
Defining usage guidelines
Implementing a way to learn lessons from tool use.
Monitoring tool use and benefits.

Quality Standards

2012-02-08T21:40:00.001-08:00

Software Quality Standards

ISO - International Organization for Standardization (1947)

IEEE - Institute of Electrical and Electronics Engineers (1963)

IEC - International Electrotechnical Commission (1906)

BS (BSI) - British Standards (1901)

CMMI- Capability Maturity Model Integration

1) IEEE 610.12-1990

IEEE Standard Glossary of Software Engineering Terminology

2) IEEE 829-1998

IEEE Standard for Software Test Documentation

The Types of Document:

There are eight document types in the IEEE 829 standard, which can be used in three distinct phases of software testing:

Preparation of Tests

Test Plan: Plan how the testing will proceed.

Test Design Specification: Decide what needs to be tested.

Test Case Specification: Create the tests to be run.

Test Procedure: Describe how the tests are run.

Test Item Transmittal Report: Specify the items released for testing.

Running the Tests

Test Log: Record the details of tests in time order.

Test Incident Report: Record details of events that need to be investigated.

Completion of Testing

Test Summary Report: Summarise and evaluate tests.

3) IEEE Standard 1012-1998

IEEE Standard for Software Verification and Validation -Description

4) IEEE Standard 1028-1997

IEEE Standard for Software Reviews -Description

5) IEEE 1008

IEEE Standard for Software Unit Testing

6) IEEE 1044-1993

IEEE Standard Classification for Software Anomalies

7) IEEE 1219-1998

Standard for Software Maintenance

8) ISO/IEC 9126-1:2001

(Software engineering – Software product quality- part 1)

Support for review, verification and validation, and a framework for quantitative quality evaluation, in the support process;

Support for setting organisational quality goals in the management process.

9) ISO/IEC 12207:2008

Systems and software engineering -- Software life cycle processes

10) ISO/IEC 14598-1:1999

Information technology -- Software product evaluation

11) ISO/IEC 2382-1:1993

Data Processing -- Vocabulary -- Part 1: Fundamental terms

12) ISO 9000:2000

Quality management systems – Fundamentals and vocabulary

13) BS 7925-2:1998

Software testing, Software component testing

(This standard defines the process for software component testing using specified test case design and measurement techniques. This will enable users of the standard to directly improve the quality of their software testing, and improve the quality of their software products)

14) DO-178B:1992

– Software Considerations in Airborne Systems and Equipment

15) BS7925-1

The British software testing standard governing testing terminology

Test Environment

2012-02-08T21:40:00.000-08:00

Build the Test Environment

1.________ and ________ are used within individual workbenches to produce the right output products.
a) Tools and techniques
b) procedures and standards
c) none of these
d) processes and walkthroughs

2.The Standards Manager's role(s) include:
a) Training the standards committee
b) promoting the concept of standards
c) choosing members for ad hoc committees
d) a and b only

3.A Toolsmith is:
a) Always the head software engineer
b) the person with specialized knowledge of the tool being introduced
c) both of these
d) neither of these

4.Whose responsibility is it to set policies?
a) Testers
b) Senior management
c) Lead technical staff
d) Independent audit boards

5.Which of these is typically NOT the role of management during tool selection?
a) Identify tool objectives
b) define selection criteria
c) make the final selection of the tool or the source
d) prepare a ranked list of selection choices

6.If procedures and standards are working properly, they will:
a) Reduce the cost of doing work
b) increase quality
c) make budgets and schedules more predictable
d) all of the above

7.The standards program is driven by management policies, but workers should develop their own standards and procedures.
a) False
b) True

8.The software engineer's role in tool selection is...
a) To identify, evaluate, and rank tools, and recommend tools to management
b) to determine what kind of tool is needed, then find it and buy it
c) to initiate the tool search and present a case to management
d) none of these

9.The highest level manager from each relevant group should be asked to join the standards committee
a) true
b) false

10.A standards program should:
a) Be able to enforce standards
b) roll out ad hoc committees to develop standards
c) both of these
d) neither of these

11.A valid risk to consider during tool selection is:
a) Difficult to use
b) requires excessive computer resources
c) lacks adequate documentation
d) all of the above

12.A _______ is the step-by-step method followed to ensure that standards are met
a) SDLC
b) Project Plan
c) Policy
d) Procedure

13.It is advisable to follow the QAI- recommended set of steps during tool selection because...
a) A methodical process will help avoid the pitfalls of "just picking one"
b) it assigns a toolsmith who can troubleshoot or tune the tool to the organization's needs
c) both of these
d) neither of these

14.A _______ is the emasure used to evaluate products and identify nonconformance.
a) Policy
b) standard
c) procedure
d) mission

15.The _______ should accept topics for standards, but the _________ should develop individual technical standards.
a) Standards committee, ad hoc committee
b) standards manager, ad hoc committee
c) standards committee, standards manager
d) standards manager, standards committee

16.The ________ defines quality as "meeting the requirements"
a) Producer
b) developer
c) consumer
d) tester

17.When developing ___________, it is important to ask these questions: - is every organizational function involved - are activities having a vested interest involved, such as authors
a) Developing standards
b) conducting walkthroughs
c) creating test cases
d) all of the above

18.A ________ is the managerial desires and intents concerning either process (intended objectives) or products (desired attributes)
a) Policy
b) procedure
c) standard
d) vision

19.When implementing a new tool, it is a good idea to assign one person full time to the tool's deployment.
a) True
b) False

20.When doing an informal tool acquisition, it is still necessary to write an RFP.
a) True
b) False

Test Management

2012-02-08T21:39:00.001-08:00

CSTE Questions-Test Management

1.Which is true of Suggestion Day?
a) It is a full staff offsite meeting to focus on quality improvement
b) all staff meets in one room to discuss all suggestions on the table
c) it uses the pare to principle to guide its agenda
d) It was proposed by Deming

2.Which of these is a "DON'T" when giving criticism?
a) Have the facts and be specific on expectations
b) be prepared to help them improve
c) do it in private
d) state the consequences if they do not improve

3.Which is not a good way to combat Groupthink?
a) Assign someone in the group to play Devil's advocate
b) use outside experts as resources
c) inform the group that the meeting will last until a unanimous decision is reached
d) break the team up into subgroups

4.When delivering an Oral System Proposal, you should emphasise your enthusiasm to do the project, but not emphasize the expertise of yourself and your staff.
a) True
b) False

5.The formalized method of brainstorming, having a question and answer period, ranking solutions, and then thinking critically about them is known as:
a) Suggestion day
b) nominal group technique
c) continuous process improvement
d) affinity diagramming

6.Getting on the customer's wavelength, getting the facts, taking notes, establishing an action program, and taking action are the recommended steps of...
a) Groupthink
b) requirements gathering
c) task force management
d) conflict resolution

7.The content of a System Proposal should include the people costs and the effects on other systems, as well as the standard cost benefit analysis.
a) True
b) False

8.It is acceptable to close the System Proposal without discussing everything on the agenda if the audience shows signs that they will approve the project.
a) False
b) True

9.Task forces should tackle more than one issue at a time.
a) False
b) True

10.The symptoms below refer to what phenomenon? - collective efforts to rationalize/discount negative info - tendency to ignore ethical or moral consequences to group decisions - stereotyped views of other groups - active pressure to change views
a) Loyalty
b) groupthink
c) an us vs them mentality
d) newspeak

11.Which one of these is NOT one of the three components of receiving information?
a) Responding to the speaker
b) attending to the speaker
c) hearing the speaker
d) understanding the speaker

12.The ideal size for a task force is:
a) 3-8 members
b) two people from each group that will be impacted by the decision
c) as many members as are interested in participating
d) 5 members

13.Therapeutic listening is:
a) Sympathetic, empathetic, and helps gain speaker's confidence
b) useful in conflict resolution
c) helpful in understanding the reasons why events occurred
d) all of the above

14.If a person says "Sure, we will make the deadline" but has a smirk on their face, which two information channels are out of sync, and which should you pay more attention to?
a) Graphic channel and information channel - information channel
b) body channel and verbal channel - body channel
c) verbal channel and graphic channel - verbal channel
d) information channel and body channel - body channel

15.When trying to piece together facts from several different people, _________ listening is important.
a) Therapeutic
b) comprehensive
c) critical
d) appreciative

16.Which type of listening is typically not needed during a verbal walkthrough (Unless Phyllis is on the call)?
a) Critical listening
b) Comprehensive listening
c) Discriminative listening
d) Appreciative listening

17.Which of these is NOT a good way to portray a successful image?
a) Being purposeful in body language, making eye contact
b) being analytical and decisive
c) being brief, specific, and direct in conversation
d) not engaging in casual conversation with management

18.It is a good idea to give management regular updates on the current status of task force activities.
a) No, because the only output of the task force should be the final report, a unanimous decision
b) yes, because they need to approve further funding
c) no, because they will take credit for the task force's work
d) yes, because they assigned you to the task force

19.____________ is selective listening to determine what you are looking to hear, weeding out the rest
a) Critical listening
b) Comprehensive listening
c) Discriminative listening
d) Appreciative listening

20.Which of these is NOT an important part of initiating an action program for conflict resolution?
a) Admitting the error if you are responsible
b) taking action immediately
c) reporting the conflict to governance bodies
d) stating the solution and getting agreement on it

21.When group members experience strong feelings of solidarity and loyalty, the desire for unanimity may override the motivation to logically and realistically evaluate alternative courses of action...
a) it is usually BAD and leads to bad decisions.
b) it is called groupthink
c) both of these
d) neither of these

22.In order to get the "whole" message with minimal distortion, _______ listening is necessary.
a) Discriminative
b) Therapeutic
c) Comprehensive
d) Critical

Test Case Design

2012-02-04T21:41:00.002-08:00

Test Design

1. A good test suite will include the following test(s)

a) Tests of normally occurring transactions
b) tests using invalid inputs
c) tests that violate established edit checks
d) A and B only
e) A, B, and C

2. Before performing volume testing, it is important to challenge each input and output data element, to determine potential limitations, and then document those limitations.

a) True
b) False

3. Before selecting which conditions you are going to include in your test suite, you should rank the test conditions according to risk.

a) Always true
b) True if there is a limited test budget
c) False

4. Analysis of test results should include...

a) System components affected
b) terminal and onscreen outputs
c) order of processing
d) compliance to specs
e) all of the above

5. Assuming you could reach 100% of any of the coverage types below, which one would leave the MOST potential for unexecuted code (and therefore, undiscovered errors)?

a) Modified decision coverage
b) global data coverage
c) statement coverage
d) branch coverage
e) decision/condition coverage

6. When evaluating whether a test suite is complete (eg, doing a peer review or inspection), Which of the following should NOT be considered?

a) Whether the scripts have appropriate sign on and setup procedures
b) Whether the scripts address all items on each (onscreen) menu
c) Whether the scripts include data setup and other prerequisites
d) Whether the scripts test single transactions, multiple transactions, or both
e) all should be considered

7. When performing volume testing, a small percentage of invalid data should be used.

a) True
b) False

8. A Pseudoconcurrency test is a test that validates...

a) Data security when two or more users access the same file at the same time
b) file integrity
c) volume testing
d) A and B only
e) A and C only

9. Which of these is not a good use of a code coverage analysis?

a) Simply to measure how well your test cases cover the code
b) analyze test coverage against system requirements
c) find "holes" in your testing and develop new test cases as supplements
d) start with black box testing, measure coverage, and use white box testing to test the remainder
e) All are good uses

10. Stop procedures are important in scripting because...

a) The person executing hte script needs to know what kinds of errors would invalidate hte rest of the script
b) the person running the script needs to know if they can pick up the script on a later step after logging a bug
c) both of these

11. Regardless of whether a script is manual or automated, it is important to consider:

a) Environmental constraints
b) think time
c) file states/contents
d) processing options
e) all of the above

12. When developing your test suite, you should NOT:

a) Use transactions with a wide range of valid and invalid input data
b) use all forms of documentation to guide test cases and the data associated with them
c) start by testing one data point at a time so you can isolate the cause of defects, then move on to combinatorial tests
d) attempt to test every possible combination of inputs
e) you should do all four of the above

Performing Tests

2012-02-04T21:41:00.001-08:00

Performing Tests

1. Maintainability tests should be performed by...

a) The application developer
b) independent groups
c) QA
d) all of the above

2. Root cause of a defect should be recorded because...

a) It helps guide where more testing needs to be done
b) it helps QA analyze which processes need to be improved
c) it helps management know where bugs are coming from
d) all of the above

3. At Testing phase entry and exit, audits should be performed to...

a) Ensure that testing complies with the organization's policies, procedures, standards, and guidelines
b) ensure that all test cases have been executed
c) ensure that all defects have been fixed
d) b and c only

4. Integration testing should begin...

a) Once two or more components have been unit tested and critical defects fixed
b) once all components have been unit tested and critical defects fixed
c) once all components have been unit tested
d) once two or more components have been unit tested

5. Testing "handshakes" and other communication points from system to system is part of...

a) Coupling tests
b) system tests
c) user acceptance tests
d) all of the above

6. System testing should begin...

a) Once the minimal components have been integration tested
b) when the environment is ready
c) when test data is conditioned
d) all three of the above must be complete

7. When reporting a defect, which of these should be included?

a) Expected versus actual results
b) potential causes
c) which pass/fail criteria failed
d) all of the above

8. Negative tests to trigger data validation rules during file processing (to make sure they are kicked out) are an example of _______ testing

a) Error guessing
b) file integrity
c) authorization
d) equivalence partitioning

9. What is a good way to tell it's time to stop system testing?

a) When the deadline is reached
b) when all testing hours are used up
c) when all scripts have been executed and all bugs have been fixed
d) when metrics such as MTTF, test coverage, and defect counts by severity reach acceptable levels

10. Which of these is not a typical way to test for the Reliability test factor?

a) Regression Testing
b) Compliance Testing
c) Functional Testing
d) Manual testing

11. When documenting the actual result of a test in a bug log, it is necessary to record the specific inputs and outputs used.

a) true
b) false

12. Which of these is NOT a significant concern surrounding the test phase?

a) Significant problems not uncovered during testing
b) too many meetings
c) inadequate time/resources - especially if project is late into testing
d) Software not ready for testing (too many showstopper bugs preventing test execution)

13. Trying to delete or overwrite controlled files, to make sure the files cannot be deleted or overwritten, are examples of what kind of test?

a) Functional tests
b) Error guessing
c) File integrity tests
d) Maintainability tests

14. When reporting a defect, it is especially important to document the effects of the bug, in terms of severity, because...

a) This will guide how much attention the defect gets, and when it will be fixed
b) only severe bugs will get fixed
c) it keeps the programmers in their place
d) none of the above

Defect Tracking

2012-02-04T21:41:00.000-08:00

Defect Tracking & Correction

1. The main steps in defect resolution are Prioritization, Scheduling, Fixing, Reporting

a) True
b) False

2. The scheduling of fixes should be based primarily on...

a) Defect counts
b) the overall project schedule
c) defect priority

3. Fixing a defect involves

a) The developers making and unit testing the fix
b) QA retesting the fix and validating it
c) regression testing surrounding the fix
d) QA reviewing scripts, test data, etc to see if updates need to be made
e) all of the above

4. Which of the following are ways to use the defect log to drive process improvement?

a) Go back to the process which originated the defect and find out what caused it
go back to the validation steps in that phase and find out why it wasn't caught earlier
b) think about what other kinds of things might have been missed, given that this bug "snuck through"
c) look at the fix history of the bug to find out if it could have been handled more
d) all of the above

5. The minimum requirements for a defect management process include all but which of these?

a) Defect to risk mapping
b) defect prevention measures
c) defect discovery, naming, and resolution
d) process improvement
e) deliverable baselining

6. Reducing the impact of a risk, should it occur, is an effective way to minimize risk.

a) True
b) False

7. Who should be involved in prioritizing fixes for valid defects found during system testing?

a) QA
b) the users
c) the project team
d) Developers

8. Which of the following techniques is not a common way to minimize expected risks?

a) Training and Education (both the workforce and the customers)
b) ranking risks using Pareto voting
c) Defensive Code
d) Defensive Design
e) Quality Assurance, Methodology and Standards

9. Which is cheaper, preventing defects or fixing them?

a) Preventing
b) fixing

10. Deliverable baselining is:

a) baselining at the end of each phase and keeping change control processes in place
b) not counting defects caught and fixed before your phase.
c) identifying key variables and defining standards for each
d) A and C only
e) A, B, and C

11. Which of these is not a "best practice" for defect managment?

a) Automate the capture and analysis of information wherever possible
b) strive to correct every reported defect before release
c) make defect management a risk-driven process
d) prevent defects or at least contain them within the phase they were discovered
e) use defect measurement to improve development

12. Which of these is not a valid purpose for reporting defects?

a) to correct the defect
b) to report the status of the application
c) to gather statistics to help develop expectations on future projects
d) to improve the development process
e) to show test coverage

13. A defect is "discovered" when

a) Development acknowledges a reported defect
b) none of the above
c) a tester observes a failure
d) development begins to work a reported defect
e) a tester reports a defect

14. ALE stands for

a) Annual Loss Expectation - a formula for judging risk
b) Acceptance Level Error - an error that was not caught until user acceptance testing
c) Audit Legal Effort - the amount of time billed to the project by the legal and audit staff
d) Assertion Loop Estimation - a measure of code complexity

15. Which of these refers to the "cost" of the risk?

a) Priority
b) severity

16. When reporting a defect it is important to...

a) Make sure it is reproducible, if possible
b) get it to the developer's attention promptly
c) attempt to analyze the cause of hte defect
d) B and C only
e) A, B, and C

17. To estimate a risk's expected impact, you should...

a) Estimate the expected frequency of the event and the amount of loss that would happen each time
b) try to put a dollar amount on it
c) confer with experts on the probability and severity of the risk
d) a and b only
e) all of the above

18. Along with a short title for the defect and what phase it was found in, what other data should be part of the defect's "name"

a) Priority, like Urgent, High, Medium, Low
b) severity, like Critical, High, Medium, Low
c) steps to reproduce the error
d) data used to reproduce the error
e) categorization, like Missing, Inaccurate, Incomplete, Inconsistent

test design

2012-02-04T21:40:00.003-08:00

test design-2

18. Which of these are examples of Requirements testing?

a) Creating a test matrix to prove that the documented requirements match what the user asked for
b) using a checklist prepared specifically for the application to verify the app's compliance to organizational policies and governmental regulations
c) Determining that the system meets the audit requirements
d) All of the above

19. A concise method of representing equivalence partitioning is:

a) a state machine
b) a complete data set
c) not possible
d) a decision table

20. Local extent, finite breadth and global extent, infinite breadth are two types of:

a) Static analysis
b) fault based testing
c) test results
d) statistical tests

21. Complexity measures, data flow analysis, and symbolic execution are all static testing methods known as:

a) Structural testing
b) structural analysis
c) branch testing
d) desk checks

22. Input Domain testing uses

a) Test data that covers the extremes of each input domain
b) test data that covers the midrange of each input domain
c) boundary analysis and equivalence partitioning
d) all of the above

23. A technique that produces a finite class of faults, but will crash the whole program, is known as:

a) local extent, finite breadth
b) global extent, infinite breadth
c) local extent, infinite breadth
d) Global extent, Finite breadth

24. Selecting test data on the basis of features of the function to be computed is called

a) Axiomatic analysis
b) error guessing
c) branch testing
d) special value testing

25. Coming up with tasks for the end user to do, and then watching them do it for the purposes of making sure their procedures are correct is:

a) Regression testing
b) intersystem testing
c) functional testing
d) manual support testing

26. When is it appropriate to use intersystem testing?

a) Coding phase
b) testing phase
c) implementation phase
d) all of the above

27. Output domain coverage is

a) a type of equivalence partitioning that ensures that all possible classes of outputs have been generated by the tests
b) ensuring that the output is readable
c) ensuring that the output is stored in the appropriate domain
d) none of the above

28. Which of the following can be used as test oracles?

a) An executable spec
b) an older version of the program
c) independently generated spreadsheets and prediction models
d) all of the above

29. Control testing is a broader term that includes

a) Error handling
b) functional analysis
c) axiomatic testing
d) all of the above

30. Functional analysis is a ______ testing technique, whereas functional testing is a _________ testing technique.

a) Static, dynamic
b) unit, integration
c) dynamic, static
d) integration, unit

31. Test stubs and harnesses are most often used during:

a) Unit testing
b) integration testing
c) system testing
d) all of the above

32. Comparing the old version of a program against a new one under test, in order to determine that the new system produces the correct results, is:

a) Parallel testing
b) regression testing
c) intersystem testing
d) state machines technique

33. All of the following are specification techniques EXCEPT

a) Algebraic
b) tractability matrix
c) axiomatic
d) decision tables

34. All of the following might be done during unit testing EXCEPT:

a) Desk check
b) manual support testing
c) walkthrough
d) compiler based testing

Test Techniques

2012-02-04T21:40:00.002-08:00

Test Techniques

1.    The testing method that uses statistical techniques to find out how faults in the program affect it's failure rate is:
a) cyclomatic complexity
b) fault estimation
c) error guessing
d) statistical testing

2.    Faults that cause an input to be associated with the wrong path domain are called
a) Process flow inconsistencies
b) domain faults
c) computation faults
d) path errors

3.    If you know that a developer tends to have extra errors in date-processing code, and decide to test dates harder than usual as a result, you are doing:
a) Risk based testing
b) static testing
c) error based testing
d) black box testing

4.    Which of these is NOT an example of stress testing?
a) Entering transactions to determine that sufficient disk space has been allocated to the application
b) Ensuring that the communication capacity is sufficient to handle the volume of work by attempting to overload the network with transactions
c) Inducing a failure on one of the systems such that the program terminates.
d) Testing system overflow conditions by entering more transactions than can be accommodated by tables, queues, internal storage facilities, and so on

5.    Fault seeding is instrumentation designed to
a) Populate an audit trail
b) estimate the number of bugs left in the code by measuring how many "bait" c) errors have not been found.
c) Measure how many branches have been tested
d) test error handling code

6.    _______ attempts to decide what constitutes a sufficient set of paths to test.
a) boolean analysis
b) cyclomatic complexity
c) fault based testing
d) perturbation testing

7.    Testing to determine whether the system can meet the specific performance criteria is referred to as:
a) Compliance testing
b) Stress testing
c) Execution testing
d) Criteria based testing

8.    Which type of testing gives you the best coverage?
a) Expression testing
b) branch testing
c) statement testing
d) condition testing

9.    Tests to determine the ability of the application to properly process incorrect transactions are:
a) Error handling testing
b) failure testing
c) compliance testing
d) security testing

10.    Crashing a server to ensure that backup data and processes are adequate is an example of:
a) Operations testing
b) Intersystem testing
c) Error Handling testing
d) Recovery testing

11.    Syntax testing evaluates the program's ability to handle:
a) Data outside the normal range
b) process flows
c) incorrectly formatted data
d) report generation

12.    Which of these is an objective of Operations testing?
a) Executing each function in the Requirements document
b) Making sure that the system can interact with other related systems
c) determining that user documentation has been prepared and documented
d) crashing a server to test recovery procedures

13.    Cost benefits analysis is particularly important during _________ testing, otherwise large amounts of effort can be expended with minimal payback.
a) Requirements
b) unit
c) regression
d) functional

14.    Code reviews and inspections to make sure programming standards are followed is known as:
a) Unit Testing
b) Desk Check
c) Compliance testing
d) Walkthrough

15.    Which of these are all types of structural testing?
a) Fault estimation, domain testing, regression testing, condition testing
b) regression testing, condition testing, manual support testing
c) statement testing, branch testing, conditional testing, expression testing, path testing
d) expression testing, path testing, control testing, security testing

16.    Which of these is a main objective of Security Testing?
a) Determining that application processing complies with the organization's policies and procedures
b) Determining that system test data and test conditions remain current.
c) Conducting redundant processing to ensure that the new version of hte aplication performs correctly
d) determining that a realistic definition and enforcement of access to the system has been implemented

17.    When testing a grade calculation system, a tester determines that all scores from 90 to 100 will yield a grade of A, but scores below 90 will not. This analysis is known as:
a) Equivalence partitioning
b) special value testing
c) axiomatic analysis
d) none of the above

Quality Assurance

2012-02-04T21:40:00.001-08:00

Quality Assurance or Quality Control?

1. A management activity, frequently performed by a staff function
a) Quality Assurance
b) Quality Control

2. Concerned with all of the products that will ever be produced by a process (not just one project)

a) Quality Assurance
b) Quality Control

3. The responsibility of the team/workers