ISTQB-FL.pptx

Welcome to:
ISTQB Foundation Level exam preparation
Course
https://arshadqa.com/

Objectives
 Any person who is interested in QA or wanted to learn about testing can enroll in this course.
 100% success guarantee
 16 sample ISTQB exam papers for practice
 By taking this course you can pass the ISTQB-FL exam in 1st attempt

Question Distribution Chapter Wise

What is Quality?
Synonyms of Quality
 Excellence
 Superiority
 Class
 Eminence
 Value
 Worth

Antonym of Quality
 Inferiority

Software Quality: Definition 1
 Low levels of defects when deployed, ideally approaching zero

 A majority of clients with high user-satisfaction when surveyed

 A structure that can minimize ―bad fixes‖ or insertion of new defects during
repairs

 Effective customer support when problems do occur

 Rapid repairs for defects, especially for high-severity defects

Beyond Absence of Defects
 Sense of beauty
• Sense of fitness for purpose
• Sense of elegance that goes beyond the simple absence of overt flaws
• Has well-formed requirements
• Robust

Why Software Quality?

Software Quality Assurance ?
 So the term software quality assurance would mean that the software guarantees
high quality

ISTQB Foundation New Syllabus

Introduction To ISTQB
 International Software Testing Qualification Board
 About ISTQB
 Certifications
 Local body conducting exam
 Who can appear?
 What is the cost?
 Validity

Introduction to ISTQB

Introduction To ISTQB
About Examination:
 Prerequisite
 Exam type – Objective
 Number of Questions
 Duration
 Schedule
 Location/Venue
 Passing Score
 Additional Info

ISTQB Foundation Syllabus
 Chapter 1: Fundamentals of Testing
 Chapter 2: Testing Throughout the Software Development Life Cycle
 Chapter 3: Static Testing
 Chapter 4: Test Techniques
 Chapter 5: Test Management
 Chapter 6: Tool Support for testing

1.1 What is testing?

Fundamentals of testing
Contents:
 1.1 What is testing?
 1.2 Why is testing necessary?
 1.3 Seven testing principles
 1.4 Test process
 1.5 The psychology of testing

What is testing? (K2)
 Common perception is testing is limited to
execution
 Test activities exist before and after test execution
as well
 Other activities throughout the development
Lifecyle
 Contributing to reviews

Test Process

Objectives of Testing
 Testing is all about
 Finding defects
 Gaining confidence about quality
 Providing information
 Preventing defects
 To evaluate work products
 To verify if all the requirements have been met
 To reduce the level of risk
 To comply which contractual, legal or regulatory
requirements and standards

What is testing? (Classification of Testing)

What is testing? (Classification of Testing)
 Types of reviews are informal reviews, walkthrough, technical review, inspection
 Level of testing are unit, integration, system, UAT and Non-functional testing

What is testing? (Debugging and Testing)
Testing
 Testing deal with finding the defects by
conducting failure on application or product.
This activity is performed by testers.
Debugging
 Debugging is a development activity which
deals with analyzing these defects, finding
the root cause and removes the cause of
defects. This activity is commonly performed
by developers.

1.2 Why testing is necessary?

1.2 Why is Testing Necessary?
 Having testers involved in requirements reviews or user story
refinement could detect defects in these work products.
 Having testers work closely with system designers while the
system is being designed can increase each party’s
understanding of the design and how to test it.

Why is Testing Necessary?
 Having testers work closely with developers while the code is under development can increase
each party’s understanding of the code and how to test it.
 Having testers verify and validate the software prior to release can detect failures that might
otherwise have been missed, and support the process of removing the defect that cause the
failures (I.e., debugging).

Quality Assurance & Quality Control
 While people often use the phrase quality
assurance (or Just QA) to refer to testing, quality
assurance and testing are not the same, but they
are related.
 Quality assurance is typically focused on
adherence to proper processes, in order to
provide confidence that the appropriate levels of
quality will be achieved. When processes are
generally of high quality, which contributes to
defect prevention.
 Quality control involves various activities,
including test activities, that support the
achievement of appropriate levels of quality. Test
activities are part of the overall software
development or maintenance process.

Error, Defect & Failure
Error(Mistake)
 A human action that produces an incorrect result
Fault(Defect, Bug)
 A manifestation of an error in software
 Also know as a defect or bug
 If executed, a fault may cause a failure
Failure:
Deviation of the software from its expected delivery or service

Causes of Software Defects
 Errors may occur for many reasons, such as:
 Time presser
 Human is error prone
 Inexperienced or insufficiently skilled project participants
 Miscommunication between project participants, including miscommunication
about requirements and design
 Complexity of the code, design, architecture, the underlying problem to be
solved, and/or the technologies used
 Misunderstandings about intra-system and inter-system interfaces, especially
when such intrasystem and inter-system interactions are large in number
 New, unfamiliar technologies

Fundamentals of Testing
 Contents:
 1.1 Why Testing Necessary?
 1.2 What is testing?
 1.3 Seven Testing Principles
 1.4 Fundamental Test Process
 1.5 The Psychology of Testing

1.3 Principles of Testing
Seven Testing Principles:
 Principle 1: Testing shows presence of defects
 Principle 2: Exhaustive testing is impossible
 Principle 3: Earlier Testing
 Principle 4: Defect clustering
 Principle 5: Pesticide paradox
 Principle 6: Testing is context dependent
 Principle 7: Absence-of-error fallacy

Principle 1:Testign Shows presence of
Defects
 Testing shows presence of defects, not there absence
 Testing can show that defects are present in a system software, but no matter
whatever count of defects we find, at any point of time we can’t say there no more
defects.
 Also to add to it, in case no defects are found, it’s not a proof of correctness.

Principle 2: Exhaustive testing is impossible
 Testing everything, which mean all possible
combination of inputs and preconditions is
generally not feasible to be conducted.
 As an alternative to exhaustive testing, risk analysis
and priorities should be used to focus on testing
efforts
 Example:
 One screen has 15 input fields each have 5
possible values, then to test all the valid input
value combinations, you would need 5^15 =
30517578125 tests

Principle 3: Early testing:
It saves time and money
 To find defects earlier or to prevents defects being introduced,
testers must be involved as early as possible in developments
life cycle. Testing activities must be coordinated with
corresponding development activities.
 Testers are good contributor in reviews and must participate.
This helps them understand the requirements earlier and
prepare test cases earlier in life cycle.

Principle 4: Defect Clustering
 Defects cluster together:
 It is possible that the more defects are clustered in smaller
modules compared to being distributed among bigger and
other modules.
 In this regards, a tester must consider and prepare
proportional test cases to test such system.

Principle 5: pesticide paradox
 If the same tests are prepared over and over
again, eventually the same set of test cases will
no longer help find new defects.
 To overcome this “Pesticide Paradox” test cases
need to be regularly reviewed and revised

Principle 6: Testing is Context dependent
 Testing is done differently in different context
 Two different software are testing with different strategy.

Principle 7: Absence-of-error fallacy
 Meeting the requirement is equally important. Finding and fixing defect doesn’t help
if the system built doesn’t fulfill the users’ need and expectations.

1.4 Test Process – part 1

 Contextual factors that influence the test process for an organization, include but are not
limited to:
 Software development lifecycle model and project methodologies being used.
 Test levels and test types being considered
 Product and project risks
 Business domain
 Operational constraints, (Budgets and resources, Timescales, complexity, contractual and
regulatory requirements)
 Organizational policies and practices
 Required internal and external standards

Test Process:
 Test process consists of following main activities:
 Test planning
 Test monitoring and control
 Test analysis
 Test design
 Test implementation
 Test execution
 Test completion

Test Planning
 Test planning consists of following main activities:
 Determining the scope and risks and identifying the objective
of testing
 Defining the overall approach of testing
 Scheduling test activities, assigning resources for the
activities
 Defining the amount, detail, template for documentation
 Selecting metrics for monitoring and controlling
 Defining entry and exit criteria
 Deciding about automation.

Test monitoring and control
 Test Monitoring:
 It is process of measuring the progress on project
 Test Metrics:
 These contain set of formulae which calculates any dimensions(test, defects, coverage, etc.)
of testing.
 Test Execution Rate:
(No of test cases executed/No of test cases planned for execution)*100
Test control:
Test control involves taking actions necessary to meet the objectives of the test.

Test Process
 Test process consists of following main activities:
 Test planning
 Test monitoring and control
 Test analysis
 Test design
 Test implementation
 Test execution
 Test completion

Test Analysis
 Test analysis includes following major activities:
 Analyzing the Test Basis
 The test basis is the information needed in order to start the test analysis and create
our Test Cases
 Evaluating the test basis and test items to identify defects of various types, such as
ambiguities, omissions, inconsistencies, inaccuracies, etc.
 Identifying features and sets of features to be tested.
 Defining and prioritizing test conditions for each feature based on analysis of the test basis.
 Considering functional, non-functional, and structural characteristics, other business and
technical factors, and level of risks.

Test Design
 Test design includes the following major activities:
 Designing and prioritizing test cases
 Identifying necessary test data to support the test conditions and test cases.
 Designing the test environment and identifying required infrastructure and tools.
 Creating bi-directional traceability between test basis and test cases

Test implementation
 Test implementation includes the following activities
 Developing and prioritizing test procedures and potentially, creating automated test scripts
 Creating test suites from the test procedures and (if any) automated test scripts
 Arranging the test suites within a test execution schedule in a way that results in efficient test
execution
 Building the test environment (including, potentially, test harness, service virtualization,
simulators, and other infrastructure items) and verifying the everything needed has been set
up correctly.
 Preparing test data and ensuring it is properly loaded in the test environment. Verifying and
updating bi-directional traceability between the test basis, test conditions, test cases, test
procedures and test suits.

Test Execution
 Test execution includes the following major activities
 Recording the IDs and versions of the test item(s) or test object, test tool(s) and testware.
 Executing tests either manually or by using test execution tools
 Comparing actual results with expected results
 Analyzing anomalies to establish their likely causes (e.g., failures my occur due to defects in
code, but false positives also may occur.
 Reporting defects based on the failures observed
 Logging the outcome of test execution (e.g., pass, fail, blocked)
 Repeating test activities either as a result of action taken for an anomaly, or as part of the
planned testing(e.g., execution of a corrected test, confirmation testing and /or regression
testing)

Test Completion
 Test completion includes following major activities :
 Checking whether all defects reports are closed, entering change requests or product
backlog items for any defects that remain unresolved at the end of test execution.
 Creating test summary report to be communicated to stakeholders
 Finalizing and archiving the test environment, the test data, the test infrastructure and other
testware for later reuse.
 Handing over the testware to the maintenance teams, other project teams, and /or other
stakeholders who could benefit from it’s use.
 Analyzing lessons learned from the completed test activities to determine changes needed
for future iterations, releases and projects.
 Using the information gathered to improve test process maturity.

Test work products
 Test planning work products:
 Test planning work products typically include one or more test plans. The test plan
includes information about the test basis, to which the other test work products
will be related via traceability information.

Test Work Products:
 Test Monitoring and control work products:
 Test monitoring and control work products typically include various types of test
reports, including test progress reports and test summary.
 Test monitoring and control work products should also address project
management concerns, such as task completion, resource allocation and usage and
effort.

Test Work Products:
 Test analysis work products
 Test analysis work products include defined and prioritized test conditions, each of
which is ideally bi-directional traceability to the specific element(s) of the test basis
it covers.
 For exploratory testing, test analysis may involve the creation of test charters.

Test Work Products:
 Test Design Work Products:
 Test design results in test cases and sets of test cases to exercise the test conditions defined
in test analysis.
 Test design also results in the design and/or identification of the necessary test data, the
design of the test environment, and the identification of infrastructure and tools, though the
extent to which these results are documented varies significantly.

Test Work Products:
 Test implementation work products:
 Test implementation work product include:
 Test procedures and the sequencing of those test procedures
 Test suites
 A test execution schedule
 Test implementation also may result in the creation and verification of test data and the test
environment.

Test Work Products:
 Test execution work products include:
 Documentation of the status of individual test cases or test procedures(e.g., ready
to run, pass, fail, blocked, deliberately skipped etc.
 Defect reports
 Documentation about which test item(s), test object(s), test tool, and testware were
involved in the testing.

Test Work Products:
 Test completion work products:
 Test completion work products include test summary reports, action items for improvement
of subsequent projects or iterations(e.g., following a project agile retrospective), change
requests product backlog items, and finalized testware.

Traceability between the test basis and test
work products
 In addition to the evaluation of test coverage, good traceability supports:
 Analyzing the impact of changes
 Making testing auditable
 Meeting IT governance criteria
 Improving the understanding of test progress reports and test summary reports to include
the status of elements of the test basis(e.g., requirements that passed their tests,
requirements that failed their tests, and requirements that have pending tests)
 Relating the technical aspects of testing to stakeholders in terms that they can understand.
 Proving information to assess product quality, process capability, and project progress
against business goals.

1.5 Psychology of testing

Human psychology and testing
 Identifying defects during a static test such as a requirements
review or user story refinement session, or identifying failures
during dynamic test execution, may be perceived as criticism of
the product and of its author.
 Since developers expect their code to be correct, they have a
confirmation bias that makes it difficult to accept that the code
is incorrect
 Information produced by testing often contains bad news. it is
a common human trait to blame the bearer of bad news

 As a result of these psychological factors, some people
may perceive testing as a destructive activity, even though
it contributes greatly to project progress and product
quality.
 Information about defects and failures should be
communicated in a constructive way
 This way, tensions between the testers and the analysts,
product owners, designers, and developers can be
reduced.

 Testers and test managers need to have good interpersonal
skills to be able to communicate effectively and to build
positive relationships with colleagues.
 Ways to communicate well include the following examples,
let’s discuss few of them one by one

Ways to communicate well
 Start with collaboration rather than battles. Remind everyone of
the common goal of better quality systems.
 Emphasize the benefits of testing.
 Communicate test results and other findings in a neutral, fact-
focused way without criticizing the person who created the
defective item.
 Write objective and factual defect reports and review findings.
 Try to understand how the other person feels and the reasons
they may react negatively to the information.
 Confirm that the other person has understood what has been
said and vice versa.

1.5.2 Tester’s and Developer’s Mindsets
 Developers and testers often think differently.
 A mindset reflects an individual’s assumptions and preferred
methods for decision making and problem solving.
 A tester’s mindset should include curiosity, professional
pessimism, a critical eye, attention to detail, and a motivation for
good and positive communications and relationships
 A tester’s mindset tends to grow and mature as the tester gains
experience.

A developer’s mindset
 A developer’s mindset may include some of the elements of a tester’s mindset.
 Successful developers are often more interested in designing and building
solutions than in contemplating what might be wrong with those solutions.
 Confirmation bias makes it difficult to find mistakes in their own work.
 With the right mindset, developers are able to test their own cod

Independent Testing
 Having some of the test activities done by independent testers increases defect
detection effectiveness.
 Independent testers bring a perspective which is different than that of the work
product authors.
 Independent tasters or third party testers have different cognitive biases from the
authors.

Levels of Independent Testers
 Tests designed by the person who wrote the software under test
 Tests designed by another person
 Tests designed by a person from a different organizational group or test specialists.
 Tests designed by a person from a different organization or company.

Chapter: 02
Testing throughout the software life cycle

2. Testing throughout the software life
cycle

Testing throughout the software life cycle
 Contents:
 2.1 Software development models
 2.2 Test levels
 2.3 Test Types
 2.4 Maintenance Testing

2.1 Software development models
 V-Model (Sequential Development Model)

Testing within a life cycle model
 In any software development lifecycle model, there are several characteristics of good
testing:
 For every development activity, there is a corresponding test activity
 Each test level has test objectives specific to that level
 Test analysis and design for a given test level begin during the corresponding development
activity
 Testers participate in discussions to define and refine requirements and design, and are
involved in reviewing work products

Software Development Model
 A sequential development model describes the software development process as a linear,
sequential flow of activities
 Incremental development involves establishing requirements, designing, building, and
testing a system in pieces, which means that the software’s features grow incrementally
 Iterative development occurs when groups of features are specified, designed, built, and
tested together in a series of cycles, often of a fixed duration

Iterative Development Model Examples
 Rational Unified Process: Each iteration tends to be relatively long (e.g., two to three
months).
 Scrum: Each iteration tends to be relatively short (e.g., hours, days, or a few weeks), and the
feature increments are correspondingly small, such as a few enhancements and/or two or
three new features
 Kanban: Implemented with or without fixed-length iterations.
 Spiral (or prototyping): Involves creating experimental increments

Agile

Software Development Lifecycle Models in
Context
 Software development lifecycle models must be selected and adapted to the context of project
and product characteristics
 Software development lifecycle models themselves may be combined
 Internet of Things (IoT) systems, which consist of many different objects, such as devices,
products, and services, typically apply separate software development lifecycle models for each
object. This presents a particular challenge for the development of Internet of Things system
versions

Test Levels
 Test levels are groups of test activities that are organized and managed together
 The test levels used in this syllabus are:
 Component testing
 Integration testing
 System testing
 Acceptance testing

Test Levels
 Test levels are characterized by the following attributes:
 Specific objectives
 Test basis, referenced to derive test cases
 Test object (i.e., what is being tested)
 Typical defects and failures
 Specific approaches and responsibilities

2.2.1 Component Testing
 Component testing (also known as unit or module testing) focuses on components that are
separately testable
 Objectives of component testing include
 Reducing risk
 Verifying whether the functional and non-functional behaviors of the component are as
designed and specified
 Building confidence in the component’s quality
 Finding defects in the component
 Preventing defects from escaping to higher test levels

2.2.1 Component Testing
 Test basis Examples of work products that can be used as a test basis for component
testing include:
 Detailed design
 Code
 Data model
 Test objects Typical test objects for component testing include:
 Components, units or modules
 Code and data structures
 Classes
 Database modules

2.2.2 Integration Testing
 Integration testing focuses on interactions between
components or systems. Objectives of integration testing
include:
 Reducing risk
 Verifying whether the functional and non-functional behaviors
of the interfaces are as designed and specified
 Building confidence in the quality of the interfaces
 Finding defects (which may be in the interfaces themselves or
within the components or systems)
 Preventing defects from escaping to higher test levels

Test basis
 Test basis Examples of work products that can be used as a test basis for integration testing
include:
 Software and system design
 Sequence diagrams
 Interface and communication protocol specifications
 Use cases
 Architecture at component or system level
 Workflows
 External interface definitions

Test objects
 Typical test objects for integration testing include:
 Subsystems
 Databases
 Infrastructure
 Interfaces
 APIs
 Microservices

2.2.3 System Testing
 System testing focuses on the behavior and capabilities of
a whole system or product
 System testing often produces information that is used by
stakeholders to make release decisions.
 System testing may also satisfy legal or regulatory
requirements or standards.
 Independent testers typically carry out system testing

Test basis
 Examples of work products that can be used as a test basis for system testing include:
 System and software requirement specifications (functional and non-functional)
 Risk analysis reports
 Use cases
 Epics and user stories
 Models of system behavior
 State diagrams
 System and user manuals

Test objects
 Typical test objects for system testing include:
 Applications
 Hardware/software systems
 Operating systems
 System under test (SUT)
 System configuration and configuration data

2.2.4 Acceptance Testing
 Acceptance testing, like system testing, typically focuses on
the behavior and capabilities of a whole system or product.
 Objectives of acceptance testing include:
 Establishing confidence in the quality of the system as a
whole
 Validating that the system is complete and will work as
expected
 Verifying that functional and non-functional behaviors of
the system are as specified

2.2.4 Acceptance Testing
 Common forms of acceptance testing include the following:
 User acceptance testing
 Operational acceptance testing
 Contractual and regulatory acceptance testing
 Alpha and beta testing

Specific approaches and responsibilities
 Acceptance testing is often the responsibility of the
customers, business users, product owners, or
operators of a system, and other stakeholders may be
involved as well
 Acceptance testing of a COTS software product may
occur when it is installed or integrated
 Acceptance testing of a new functional enhancement
may occur before system testing

Test basis
 Examples of work products that can be used as a test basis for any form of acceptance
testing include:
 Business processes
 User or business requirements
 Regulations, legal contracts and standards
 Use cases
 System requirements
 System or user documentation
 Installation procedures
 Risk analysis reports

test objects
 Typical test objects for any form of acceptance testing include:
 System under test
 System configuration and configuration data
 Business processes for a fully integrated system
 Recovery systems and hot sites (for business continuity and disaster recovery testing)
 Operational and maintenance processes
 Forms
 Reports
 Existing and converted production data

2.3 Test Types
 A test type is a group of test activities aimed at testing specific characteristics of a software system.
 Objectives
 Evaluating functional quality characteristics, such as completeness, correctness, and appropriateness
 Evaluating non-functional quality characteristics, such as reliability, performance efficiency, security,
compatibility, and usability

2.3 Test Types

Test Types Objectives
 Evaluating whether the structure or architecture of the component or system is correct,
complete, and as specified
 Evaluating the effects of changes, such as confirming that defects have been fixed
(confirmation testing) and looking for unintended changes in behavior resulting from
software or environment changes (regression testing)

2.3.1 Functional Testing
 Functional testing of a system involves tests that evaluate
functions that the system should perform
 The functions are “what” the system should do.
 Functional tests should be performed at all test levels
 Functional test design and execution may involve special skills or
knowledge

2.3.2 Non-functional Testing
 Non-functional testing of a system evaluates characteristics of
systems and software such as usability, performance efficiency
or security
 Non-functional testing can and often should be performed at
all test levels, and done as early as possible
 Non-functional test design and execution may involve special
skills or knowledge, such as knowledge of the inherent
weaknesses of a design or technology

2.3.3 White-box Testing
 White-box testing derives tests based on the system’s internal structure or implementation
 White-box test design and execution may involve special skills or knowledge, such as the way the code is built

2.3.4 Change-related Testing
 When changes are made to a system, either to correct a
defect or because of new or changing functionality, testing
should be done
 Confirmation testing: After a defect is fixed
 Regression testing: It is possible that a change made in one
part of the code, whether a fix or another type of change,
may accidentally affect the behavior of other parts of the
code

2.3.5 Test Types and Test Levels
 It is possible to perform any of the test types mentioned above at any test level
 Functional, non-functional, white-box, and change-related tests will be given across all test
levels which is
 Component testing
 Integration testing
 System testing
 Acceptance testing

2.4 Maintenance Testing

2.4 Maintenance Testing
 Once deployed to production environments, software and systems need to be maintained
 When any changes are made as part of maintenance, maintenance testing should be performed
 A maintenance release may require maintenance testing at multiple test levels using various test
types, based on its scope

The scope of maintenance testing
 The degree of risk of the change, for example, the degree to which the changed
area of software communicates with other components or systems
 The size of the existing system
 The size of the change

2.4.1 Triggers for Maintenance
 There are several reasons why software maintenance, and thus maintenance testing, takes place,
both for planned and unplanned changes.
 Modification, such as planned and unplanned enhancements
 Migration, such as from one platform to another being maintained
 Retirement, such as when an application reaches the end of its life

2.4.1 Triggers for Maintenance
 For Internet of Things systems, maintenance testing may be
triggered by the introduction of completely new or modified
things, such as hardware devices and software services, into the
overall system. The maintenance testing for such systems places
particular emphasis on integration testing at different levels (e.g.,
network level, application level) and on security aspects, in
particular those relating to personal data.

2.4.2 Impact Analysis for Maintenance
 Impact analysis evaluates the changes that were made for a maintenance release to identify the
intended consequences as well as expected and possible side effects of a change
 The side effects and affected areas in the system need to be tested for regressions
 Impact analysis may be done before a change is made

2.4.2 Impact Analysis for Maintenance
 Impact analysis can be difficult if:
 Specifications (e.g., business requirements, user stories, architecture) are out of
date or missing
 Test cases are not documented or are out of date
 Bi-directional traceability between tests and the test basis has not been
maintained
 Tool support is weak or non-existent
 The people involved do not have domain and/or system knowledge
 Insufficient attention has been paid to the software's maintainability during
development

3 Static Testing

3.1 Static Testing Basics
 In contrast to dynamic testing, which requires the execution of the software being
tested
 Static analysis is important for safety-critical computer systems (e.g., aviation,
medical, or nuclear software)
 Static analysis is also often incorporated into automated build and delivery
systems, for example in Agile development, continuous delivery, and continuous
deployment

3.1.1 Work Products that Can Be Examined
by Static Testing
 Almost any work product can be examined using static testing (reviews
and/or static analysis), for example:
 Specifications, including business requirements, functional requirements,
and security requirements
 Epics, user stories, and acceptance criteria
 Architecture and design specifications
 Code
 Testware, including test plans, test cases, test procedures, and automated
test scripts


3.1.1 Work Products that Can Be Examined
by Static Testing
 User guides
 Web pages
 Contracts, project plans, schedules, and budgets
 Models, such as activity diagrams

3.1.2 Benefits of Static Testing
 Static testing techniques provide a variety of benefits
 When applied early in the software development lifecycle, static testing enables
the early detection of defects before dynamic testing is performed
 Using static testing techniques to find defects and then fixing those defects
promptly is almost always much cheaper for the organization than using dynamic
testing

3.1.2 Benefits of Static Testing
 Detecting and correcting defects more efficiently, and prior to dynamic test execution
 Identifying defects which are not easily found by dynamic testing
 Preventing defects
 Increasing development productivity (e.g., due to improved design, more maintainable code)
 Reducing development cost and time
 Reducing testing cost and time
 Reducing total cost of quality over the software’s lifetime, due to fewer failures later in the
lifecycle or after delivery into operation
 Improving communication between team members in the course of participating in reviews

3.1.3 Differences between Static and
Dynamic Testing
 Static and dynamic testing complement each other by finding different types of
defects.
 One main distinction is that static testing finds defects in work products directly
rather than identifying failures caused by defects when the software is run
 Another distinction is that static testing can be used to improve the consistency
and internal quality of work products
 Dynamic testing typically focuses on externally visible behaviors.

typical defects
 Requirement defects (e.g., inconsistencies, ambiguities, contradictions,
omissions, inaccuracies, and redundancies)
 Design defects
 Coding defects
 Deviations from standards
 Incorrect interface specifications (e.g., different units of measurement used
by the calling system than by the called system)
 Security vulnerabilities (e.g., susceptibility to buffer overflows)
 Gaps or inaccuracies in test basis traceability or coverage (e.g., missing
tests for an acceptance criterion)

3.2 Review Process

3.2 Review Process
 Reviews vary from informal to formal
 Informal reviews are characterized by not following a defined process and not having formal
documented output
 The focus of a review depends on the agreed objectives of the review (e.g., finding defects,
gaining understanding, educating participants such as testers and new team members, or
discussing and deciding by consensus).
 ISO standard (ISO/IEC 20246) contains more in-depth descriptions of the review process for
work products, including roles and review techniques

3.2.1 Work Product Review Process
 The review process comprises the following main activities
 Planning
 Initiate review
 Individual review (i.e., individual preparation)
 Issue communication and analysis
 Fixing and reporting

Review Planning
 Defining the scope, which includes the purpose of the review, what documents or parts of
documents to review, and the quality characteristics to be evaluated
 Estimating effort and timeframe
 Identifying review characteristics such as the review type with roles, activities, and checklists
 Selecting the people to participate in the review and allocating roles
 Defining the entry and exit criteria for more formal review types (e.g., inspections)
 Checking that entry criteria are met (for more formal review types)

Initiate review
 Distributing the work product (physically or by electronic means) and other
material, such as issue log forms, checklists, and related work products
 Explaining the scope, objectives, process, roles, and work products to the
participants
 Answering any questions that participants may have about the review

Individual review
 Reviewing all or part of the work product
 Noting potential defects, recommendations, and question

Issue communication and analysis
 Communicating identified potential defects (e.g., in a review meeting)
 Analyzing potential defects, assigning ownership and status to them
 Evaluating and documenting quality characteristics
 Evaluating the review findings against the exit criteria to make a review decision (reject; major changes
needed; accept, possibly with minor changes)

Fixing and reporting
 Creating defect reports for those findings that require changes
 Fixing defects found (typically done by the author) in the work product reviewed
 Communicating defects to the appropriate person or team (when found in a work product
related to the work product reviewed)
 Recording updated status of defects (in formal reviews), potentially including the agreement
of the comment originator
 Gathering metrics (for more formal review types)
 Checking that exit criteria are met (for more formal review types)
 Accepting the work product when the exit criteria are reached

3.2.2 Roles and responsibilities in a formal
review
 A typical formal review will include the roles below:
 order)

Author
 Creates the work product under review
 Fixes defects in the work product under review (if necessary)

Management
 Is responsible for review planning
 Decides on the execution of reviews
 Assigns staff, budget, and time
 Monitors ongoing cost-effectiveness
 Executes control decisions in the event of inadequate outcomes

moderator
 Ensures effective running of review meetings (when held)
 Mediates, if necessary, between the various points of view
 Is often the person upon whom the success of the review depends

Review leader
 Takes overall responsibility for the review
 Decides who will be involved and organizes when and where
it will take place


Reviewers
 May be subject matter experts, persons working on the project, stakeholders with
an interest in the work product, and/or individuals with specific technical or
business backgrounds
 Identify potential defects in the work product under review
 May represent different perspectives (e.g., tester, programmer, user, operator,
business analyst, usability expert, etc.)

Scribe (or recorder)
 Collates potential defects found during the individual
review activity
 Records new potential defects, open points, and
decisions from the review meeting (when held)

3.2.3 Review Types
 One of the main objective of review is to uncover defects

Informal review
 Main purpose: detecting potential defects
 Possible additional purposes: generating new ideas or solutions, quickly solving
minor problems
 Not based on a formal (documented) process
 May not involve a review meeting

Informal review
 May be performed by a colleague of the author (buddy check) or by more people
 Results may be documented
 Varies in usefulness depending on the reviewers
 Use of checklists is optional
 Very commonly used in Agile development

Walkthrough
 Main purposes: find defects, improve the software product, consider alternative
implementations, evaluate conformance to standards and specifications
 Possible additional purposes: exchanging ideas about techniques or style variations, training
of participants, achieving consensus
 Individual preparation before the review meeting is optional
 Review meeting is typically led by the author of the work product

Walkthrough
 Scribe is mandatory
 May take the form of scenarios, dry runs, or simulations
 Potential defect logs and review reports may be produced
 May vary in practice from quite informal to very formal

Technical review
 Main purposes: gaining consensus, detecting potential defects
 Possible further purposes: evaluating quality and building confidence in the work product,
generating new ideas, motivating and enabling authors to improve future work products,
considering alternative implementations
 Reviewers should be technical peers of the author, and technical experts in the same or
other disciplines

Technical review
 Individual preparation before the review meeting is required
 Review meeting is optional, ideally led by a trained facilitator (typically not the
author)
 Scribe is mandatory, ideally not the author
 Potential defect logs and review reports are typically produced

Inspection
 Main purposes: detecting potential defects, evaluating quality and
building confidence in the work product, preventing future similar
defects through author learning and root cause analysis
 Possible further purposes: motivating and enabling authors to improve
future work products and the software development process, achieving
consensus
 Follows a defined process with formal documented outputs, based on
rules and checklists

Inspection
 Uses clearly defined roles, such as those specified in section 3.2.2 which are
mandatory, and may include a dedicated reader (who reads the work product
aloud during the review meeting)
 Individual preparation before the review meeting is required
 Reviewers are either peers of the author or experts in other disciplines that are
relevant to the work product

Inspection
 Specified entry and exit criteria are used
 Scribe is mandatory
 Review meeting is led by a trained facilitator (not the author)
 Author cannot act as the review leader, reader, or scribe
 Potential defect logs and review report are produced
 Metrics are collected and used to improve the entire software development process,
including the inspection process

3.2.4 Applying Review Techniques
 There are a number of review techniques that can be applied during the individual review
 Ad hoc
 Checklist-based
 Scenarios and dry runs
 Role-based
 Perspective-based

3.2.5 Success Factors for Reviews
 There are a number of factors that will affect the outcome of the review
 Each review has clear objectives, defined during review planning, and used as measurable exit criteria
 Review types are applied which are suitable to achieve the objectives and are appropriate to the type
and level of software work products and participants
 Any review techniques used, such as checklist-based or role-based reviewing, are suitable for effective
defect identification in the work product to be reviewed

3.2.5 Success Factors for Reviews
 Any checklists used address the main risks and are up to date
 Large documents are written and reviewed in small chunks, so that quality control is
exercised by providing authors early and frequent feedback on defects
 Participants have adequate time to prepare
 Reviews are scheduled with adequate notice
 Management supports the review process (e.g., by incorporating adequate time for review
activities in project schedules)

People-related success factors for reviews
 The right people are involved to meet the review objectives.
 Testers are seen as valued reviewers who contribute to the review and learn
about the work product, which enables them to prepare more effective
tests, and to prepare those tests earlier
 Participants dedicate adequate time and attention to detail
 Reviews are conducted on small chunks, so that reviewers do not lose
concentration during individual review and/or the review meeting (when
held)

People-related success factors for reviews
 Defects found are acknowledged, appreciated, and handled objectively
 The meeting is well-managed, so that participants consider it a valuable use of their time
 The review is conducted in an atmosphere of trust; the outcome will not be used for the
evaluation of the participants
 Participants avoid body language and behaviors that might indicate boredom, exasperation,
or hostility to other participants
 Adequate training is provided, especially for more formal review types such as inspections
 A culture of learning and process improvement is promoted

4 Test Techniques

4.1 Categories of Test Techniques
 Black Box Test Techniques
 White Box
 Experience base

Black Box Test Techniques
 Test conditions, test cases, and test data are derived from a test basis that may include
software requirements, specifications, use cases, and user stories
 Test cases may be used to detect gaps between the requirements and the implementation of
the requirements, as well as deviations from the requirements
 Coverage is measured based on the items tested in the test basis and the technique applied
to the test basis

White Box
 Test conditions, test cases, and test data are derived from a test basis that may include code,
software architecture, detailed design, or any other source of information regarding the
structure of the software
 Coverage is measured based on the items tested within a selected structure (e.g., the code
or interfaces)
 Specifications are often used as an additional source of information to determine the
expected outcome of test cases

Experience base
 Common characteristics of experience-based test techniques include the following:
 Test conditions, test cases, and test data are derived from a test basis that may include
knowledge and experience of testers, developers, users and other stakeholders
 This knowledge and experience includes expected use of the software, its environment, likely
defects, and the distribution of those defects
 The international standard (ISO/IEC/IEEE 29119-4) contains descriptions of test techniques
and their corresponding coverage measures

4.1.1 Choosing Test Techniques
 When creating test cases, testers generally use a combination of test techniques to achieve the best
results from the test effort
 Some techniques are more applicable to certain situations and test levels; others are applicable to all
test levels
 The appropriate level of formality depends on the context of testing, including the maturity of test
and development processes, time constraints, safety or regulatory requirements, the knowledge and
skills of the people involved, and the software development lifecycle model being followed.

 The choice of which test techniques to use depends on a number of factors, including
the following
 Type of component or system
 Component or system complexity
 Regulatory standards
 Customer or contractual requirements
 Risk levels
 Risk types
 Test objectives

 Available documentation
 Tester knowledge and skills
 Available tools
 Time and budget
 Software development lifecycle model
 Expected use of the software
 Previous experience with using the test techniques on the component or system to be tested
 The types of defects expected in the component or system

4.2 Black-box Test Techniques

4.2.1 Equivalence Partitioning
Equivalence partitioning or equivalence class partitioning (ECP) is a software testing
technique that divides the input data of a software unit into partitions of equivalent data from
which test cases can be derived. In principle, test cases are designed to cover each partition at
least once.

 Equivalence partitioning divides data into partitions
 Valid values are values that should be accepted by the component or system
 Invalid values are values that should be rejected by the component or system
 Each value must belong to one and only one equivalence partition
 To achieve 100% coverage with this technique, test cases must cover all identified
partitions

 An integer field shall contain values between and including 1 to 15. By applying
equivalence partition what is the minimum number of test cases required for
maximum coverage?
 2
 3
 1
 4

 An integer field shall contain values between and including 1 to 15. By applying EP which of
the following is a valid collection of equivalence classes for a given scenario.
 Less than 1, 1 through 15, more than 15
 Negative number, 1 through 15, above 15
 Less than 1, 1 through 14, more than 15
 Less than 0, 1 through 14, 15 and more 3

4.2.2 Boundary Value Analysis
 Boundary value analysis (BVA) is an extension of equivalence partitioning
 Boundary value analysis can be applied at all test level
 This technique is generally used to test requirements that call for a range of numbers
(including dates and times).

 A text field in a application accepts inputs as the age of user. Here, the values allowed to be
accepted by the field is between 18 to 30 years, inclusive of both the values. By applying BVA
what is the minimum number of test cases require for maximum coverage
 2
 3
 1
 4

accepted by the field is between 18 to 30 years, inclusive of both the values. Based on
Boundary value analysis which is the given option consist of valid collection of boundary
values.
 16, 17, 19, 30
 17, 18, 19, 31
 17, 18, 30, 31
 18, 19, 20, 31

accepted by the field is between 18 to 30 years, inclusive of both the values. By applying EP
and BVA which of the given option consist of valid boundary values and valid equivalence
values.
 17, 18, 20
 18, 30, 25
 18, 30, 31
 19, 20, 31

4.2.3 Decision Table Testing

 Decision tables are a good way to record complex business rules that a system must
implement
 When creating decision tables, the tester identifies conditions (often inputs) and the
resulting actions (often outputs) of the system
 It may be applied to all situations in which the behavior of the software depends on a
combination of conditions, at any test level.
 It also helps in finding any gaps in the requirements
 Decision table captures system requirements that contain logical condition.

 What is the expected result for each of the following test cases?
 A. Citibank card member, holding a sliver room
 B. Non Citibank member, holding a platinum room

 A- Don’t offer any upgrade, B- Don’t offer any upgrade.
 A-Don’t offer any upgrade, B- Offer upgrade to Gold
 A-Offer upgrade to silver, B-Offer upgrade to silver
 A-Offer upgrade to Gold, B-Don’t offer any upgrade.

 Given the following decision table: Which of the following test cases and expected results is
VALID?
 23 year old in insurance class A Premium is 90 and access is 2,500.
 51 year old in insurance class C Premium is 100 and access is 500.
 31 year old in insurance class B Premium is 70 and access is 2,500.
 43 year old in insurance class C Premium is 100 and access is 1,000.

4.2.4 State Transition Testing

 State transition testing is used for menu-based applications and is widely used within the
embedded software industry.
 The technique is also suitable for modeling a business scenario having specific states or for
testing screen navigation.
 The concept of a state is abstract – it may represent a few lines of code or an entire business
process

guard condition
 If the same event can result in two or more different transitions from the same state, that event
may be qualified by a guard condition.

 State transition diagram for water

 Based on the given state transition diagram of a switch which of the following test case in
INVALID?
 Off to On
 On to Off
 FAULT to On
 On to FAULT

ISTQB FOUNDATION LEVEL EXAM
PREPARATION

4.2.5 Use Case Testing

 Each use case specifies some behavior that a subject can perform in collaboration with one or
more actors
 Interactions may be represented graphically by work flows, activity diagrams, or business process
models.
 Coverage can be measured by the percentage of use case behaviors tested divided by the total
number of use case behaviors, normally expressed as a percentage

 Which of the following statements about the benefits of deriving test cases from use cases
are true and which are false?
 A. Driving test cases from use cases is helpful for system and acceptance testing
 B. Driving test cases from use cases is helpful only for automated testing.
 C. Driving test cases from use cases is helpful for component testing.
 D. Driving test cases from use cases is helpful for integration testing.
Answer set:
A. A and D are true; B and C are false
B. A is true; B, C, an D are false.
C. B and D are true; A and C are false
D. A, C and D are true; B is false

4.3 White-box Test Techniques
4.3.1 Statement Testing and Coverage

 Statement testing exercises the executable statements in the code.
 Coverage is measured as the number of statements executed by the tests divided
by the total number of executable statements in the test object, normally expressed
as a percentage

 Statement Testing or statement coverage tests the statement for a given fragment of code.
 Whereas decision testing or decision coverage tests the decisions made within a given
fragment of code.
 Decision testing is also know as branch testing or branch coverage.
 Decision testing is stranger than statement testing.
 100% decision coverage guarantee 100% statement coverage but not vice versa.

 Read A
 Read B
 If A>B then
 Print “ A is Bigger”
ELSE
 Print “ B is Bigger”
End If
Statement coverage: 2
Tip : number of else +1

 Read A
 Read B
 If A>B then
ELSE
End If
 What is the minimum number of test cases require for 100% test coverage?

 Read A
 If A>0 then
 If A=21then
 Print “Key”
 End If
End If
Statement coverage: 1
Tip for unnested condition: number of else

 Read A
 Read B
 If A>0 then
 If B=0 then
 Print “No values”
 Else
 Print B
 If A>21 then
 Print A
 End If
 End If
End If
Nested condition:
 Statement coverage= 2
 Tip: number of else +1

 Read A
 Read B
 If A<0 then
 Print “ A negative”
 Else
 Print “A Positive”
 End if
 If B<0 then
 Print “B negative”
 Else
 Print “B Positive”
 End If
Tip: Unnested condition: number of else
Statement coverage = 2

 Tip for un-nested conditions
 Statement coverage = number of else
 Tip for nested conditions:
 Statement coverage = number of else +1

 For the given fragment of code following paths/test cases have been executed . What
statement coverage is achieved?
 Test 1-A,B,C
 Test 2-A,B,D,G,H
 A. 50%
 B. 75%
 C. 90%
 D. 100%

 Statement Coverage =
Number of statement executed
/Total number of statements
=(6/8)*100=75%

4.3 White-box Test Techniques
4.3.2 Decision Testing and Coverage

 Decision testing or decision coverage tests the decisions made within a given
fragment of code.
 Decision testing is also know as branch testing or branch coverage.
 Decision testing is stranger than statement testing.
 100% decision coverage guarantee 100% statement coverage but not vice versa.

 Read A
 Read B
 If A>B then
ELSE
End If
Decision Coverage = 2

 Read A
 Read B
 If A>B then
ELSE
End If
 What is the minimum number of test cases require for 100% decision coverage?

 Read A
 If A>0 then
 If A=21then
 Print “Key”
 End If
End If
 Decision Coverage = 3
Tip for nested conditions
 Decision coverage = number of ifs +1

 Read A
 Read B
 If A>0 then
 If B=0 then
 Print “No values”
 Else
 Print B
 If A>21 then
 Print A
 End If
 End If
End If
Decision Coverage = 4

 Read A
 Read B
 If A<0 then
 Print “ A negative”
 Else
 Print “A Positive”
 End if
 If B<0 then
 Print “B negative”
 Else
 Print “B Positive”
 End If
Decision coverage = 2
Tip for un-nested conditions
 Decision coverage = 2 (regardless of number of ifs ) https://arshadqa.com/

Tip for un-nested conditions
 Decision coverage = 2 (regardless of number of ifs )

 For the given fragment of code following paths/test cases have been executed . What
decision coverage is achieved?
 Test 1-A,B,C
 Test 2-A,B,D,G,H
 A. 62%
 B. 75%
 C. 90%
 D. 100%

 Decision Coverage =
Number of branch executed
/Total number of branches
=(5/8)*100=62%

4.4 Experience-based Test Techniques

4.4 Experience-based Test Techniques
 4.4.1 Error Guessing
 4.4.2 Exploratory Testing
 4.4.3 Checklist-based Testing

4.4.1 Error Guessing
 Error guessing is a technique used to anticipate the occurrence of mistakes, defects, and
failures, based on the tester’s knowledge, including:
 How the application has worked in the past
 What types of mistakes the developers tend to make
 Failures that have occurred in other applications
 A methodical approach to the error guessing technique is to create a list of possible
mistakes, defects, and failures, and design tests that will expose those failures and the
defects that caused them

4.4.2 Exploratory Testing
 Exploratory testing is sometimes conducted using session-based testing to
structure the activity
 Exploratory testing is most useful when there are few or inadequate
specifications or significant time pressure on testing.
 Exploratory testing is also useful to complement other more formal testing
techniques.

4.4.3 Checklist-based Testing
 Such checklists can be built based on experience, knowledge about what is important for the
user, or an understanding of why and how software fails.
 Checklists can be created to support various test types, including functional and non-functional
testing
 In checklist-based testing, testers design, implement, and execute tests to cover test conditions
found in a checklist

5 Test Management

5.1 Test Organization
 5.1.1 Independent Testing
 5.1.2 Tasks of a Test Manager and Tester

5.1.1 Independent Testing
 Degrees of independence in testing include the following (from low level of independence to
high level):
 No independent testers; the only form of testing available is developers testing their own
code
 Independent developers or testers within the development teams or the project team; this
could be developers testing their colleagues’ products

5.1.1 Independent Testing
 Independent test team or group within the organization, reporting to project management or
executive management
 Independent testers from the business organization or user community, or with specializations
in specific test types such as usability, security, performance, regulatory/compliance, or
portability
 Independent testers external to the organization, either working on-site (insourcing) or off-site
(outsourcing)

Potential benefits of test independence
 Independent testers are likely to recognize different kinds of failures compared to developers
because of their different backgrounds, technical perspectives, and biases
 An independent tester can verify, challenge, or disprove assumptions made by stakeholders
during specification and implementation of the system

Potential drawbacks of test independence
include:
 Isolation from the development team, leading to a lack of collaboration, delays in providing
feedback to the development team, or an adversarial relationship with the development
team
 Developers may lose a sense of responsibility for quality
 Independent testers may be seen as a bottleneck or blamed for delays in release
 Independent testers may lack some important information (e.g., about the test object)

5.1.2 Tasks of a Test Manager and Tester
 In this syllabus, two test roles are covered, test managers and testers. The activities and tasks
performed by these two roles depend on the project and product context, the skills of the
people in the roles, and the organization.

Test Manager Tasks
 Develop or review a test policy and test strategy for the organization
 Plan the test activities by considering the context, and understanding
the test objectives and risks. This may include selecting test
approaches, estimating test time, effort and cost, acquiring resources,
defining test levels and test cycles, and planning defect management
 Write and update the test plan(s)
 Coordinate the test plan(s) with project managers, product owners,
and others
 Share testing perspectives with other project activities, such as
integration planning
t

Test Manager Tasks
 Initiate the analysis, design, implementation, and execution of tests, monitor test progress
and results, and check the status of exit criteria (or definition of done)
 Prepare and deliver test progress reports and test summary reports based on the
information gathered
 Adapt planning based on test results and progress (sometimes documented in test progress
reports, and/or in test summary reports for other testing already completed on the project)
and take any actions necessary for test control
 Support setting up the defect management system and adequate configuration
management of testware

Test Manager Tasks
 Introduce suitable metrics for measuring test progress and evaluating the quality of the
testing and the product
 Support the selection and implementation of tools to support the test process, including
recommending the budget for tool selection (and possibly purchase and/or support),
allocating time and effort for pilot projects, and providing continuing support in the use of
the tool(s)
 Decide about the implementation of test environment(s)
 Promote and advocate the testers, the test team, and the test profession within the
organization
 Develop the skills and careers of testers (e.g., through training plans, performance
evaluations, coaching, etc.)

tester tasks
 Review and contribute to test plans
 Analyze, review, and assess requirements, user stories and acceptance
criteria, specifications, and models for testability (i.e., the test basis)
 Identify and document test conditions, and capture traceability between
test cases, test conditions, and the test basis

tester tasks
 Design, set up, and verify test environment(s), often coordinating with system
administration and network management
 Design and implement test cases and test procedures
 Prepare and acquire test data
 Create the detailed test execution schedule

tester tasks
 Execute tests, evaluate the results, and document deviations from expected results
 Use appropriate tools to facilitate the test process
 Automate tests as needed (may be supported by a developer or a test automation expert)
 Evaluate non-functional characteristics such as performance efficiency, reliability, usability,
security, compatibility, and portability
 Review tests developed by others

5.2 Test Planning and Estimation

Test Plan
 Determining the scope, objectives, and risks of testing
 Defining the overall approach of testing
 Integrating and coordinating the test activities into the software lifecycle activities
 Making decisions about what to test, the people and other resources required to perform the
various test activities, and how test activities will be carried out

Test Plan
 Scheduling of test analysis, design, implementation, execution, and evaluation activities, either
on particular dates (e.g., in sequential development) or in the context of each iteration (e.g., in
iterative development)
 Selecting metrics for test monitoring and control
 Budgeting for the test activities
 Determining the level of detail and structure for test documentation (e.g., by providing
templates or example documents)

Test Strategy
 A test strategy provides a generalized description of the test process.
 Analytical:
 Model-Based
 Methodical
 Process-compliant
 Directed
 Regression-averse
 Reactive

Entry Criteria
 Typical entry criteria include:
 Availability of testable requirements, user stories, and/or models (e.g., when following a
model based testing strategy)
 Availability of test items that have met the exit criteria for any prior test levels
 Availability of test environment
 Availability of necessary test tools
 Availability of test data and other necessary resources

Exit criteria
 Typical exit criteria include:
 Planned tests have been executed
 A defined level of coverage (e.g., of requirements, user stories, acceptance criteria, risks,
code) has been achieved
 The number of unresolved defects is within an agreed limit
 The number of estimated remaining defects is sufficiently low
 The evaluated levels of reliability, performance efficiency, usability, security, and other
relevant quality characteristics are sufficient

Test Execution Schedule
 The test suites can be arranged in a test execution schedule that defines the order in which
they are to be run.
 The test execution schedule should take into account such factors as prioritization,
dependencies, confirmation tests, regression tests, and the most efficient sequence for
executing the tests.

Factors Influencing the Test Effort
 Factors influencing the test effort may include characteristics of
the product, characteristics of the development process,
characteristics of the people, and the test results.

Product characteristics
 The risks associated with the product
 The quality of the test basis
 The size of the product
 The complexity of the product domain
 The requirements for quality characteristics (e.g., security, reliability)
 The required level of detail for test documentation
 Requirements for legal and regulatory compliance

Development process characteristics
 The stability and maturity of the organization
 The development model in use
 The test approach
 The tools used
 The test process
 Time pressure

People characteristics
 The skills and experience of the people involved, especially with
similar projects and products (e.g., domain knowledge)
 Team cohesion and leadership

Test results
 The number and severity of defects found
 The amount of rework required

Test Estimation Techniques
 There are a number of estimation techniques used to determine
the effort required for adequate testing.
 The metrics-based technique: estimating the test effort based on
metrics of former similar projects, or based on typical values
 The expert-based technique: estimating the test effort based on
the experience of the owners of the testing tasks or by experts

5.3 Test Monitoring and Control

 The purpose of test monitoring is to gather information and
provide feedback and visibility about test activities
 Information to be monitored may be collected manually or
automatically
 Test control describes any guiding or corrective actions taken as a
result of information and metrics gathered and (possibly)
reported

 Examples of test control actions include:
 Re-prioritizing tests when an identified risk occurs (e.g., software
delivered late)
 Changing the test schedule due to availability or unavailability of a
test environment or other resources
 Re-evaluating whether a test item meets an entry or exit criterion
due to rework

5.3.1 Metrics Used in Testing
 Metrics can be collected during and at the end of test activities in order to assess:
 Progress against the planned schedule and budget
 Current quality of the test object
 Adequacy of the test approach
 Effectiveness of the test activities with respect to the objectives

Common test metrics include:
 Percentage of planned work done in test case preparation (or percentage
of planned test cases implemented)
 Percentage of planned work done in test environment preparation
 Test case execution (e.g., number of test cases run/not run, test cases
passed/failed, and/or test conditions passed/failed)

Common test metrics include:
 Defect information (e.g., defect density, defects found and fixed, failure rate, and
confirmation test results)
 Test coverage of requirements, user stories, acceptance criteria, risks, or code
 Task completion, resource allocation and usage, and effort
 Cost of testing, including the cost compared to the benefit of finding the next
defect or the cost compared to the benefit of running the next test

5.3.2 Purposes, Contents, and Audiences
for Test Reports
 The purpose of test reporting is to summarize and communicate test
activity information
 During test monitoring and control, the test manager regularly issues
test progress reports for stakeholders

Typical test progress reports and test
summary reports may include
 Summary of testing performed
 Information on what occurred during a test period
 Deviations from plan, including deviations in schedule, duration, or effort of test
activities
 Status of testing and product quality with respect to the exit criteria or definition of
done

Typical test progress reports and test
summary reports may include
 Factors that have blocked or continue to block progress
 Metrics of defects, test cases, test coverage, activity progress, and resource consumption.
 Residual risks
 Reusable test work products produced

5.4 Configuration Management

5.4 Configuration Management
 The purpose of configuration management is to establish and maintain the
integrity of the component or system
 During test planning, configuration management procedures and infrastructure
(tools) should be identified and implemented

configuration management may involve
ensuring the following
 All test items are uniquely identified, version controlled, tracked for changes, and related to
each other
 All identified documents and software items are referenced unambiguously in test
documentation

5.5 Risks and Testing

5.5 Risks and Testing
 Risk involves the possibility of an event in the future which has negative consequences.
 The level of risk is determined by the likelihood of the event and the impact from that event.

5.5.2 Product and Project Risks
 Product risk involves the possibility that a work product (e.g., a specification, component,
system, or test) may fail to satisfy the legitimate needs of its users and/or stakeholders
 Project risk involves situations that, should they occur, may have a negative effect on a project's
ability to achieve its objectives

Product Risks
 Software might not perform its intended functions according to the
specification
 Software might not perform its intended functions according to user, customer,
and/or stakeholder needs
 A system architecture may not adequately support some non-functional
requirement(s)
 A particular computation may be performed incorrectly in some circumstances
 A loop control structure may be coded incorrectly

Product Risks
 Response-times may be inadequate for a high-performance transaction processing
system
 User experience (UX) feedback might not meet product expectations

Project risk
 Delays may occur in delivery, task completion, or satisfaction of exit criteria or definition of
done
 Inaccurate estimates, reallocation of funds to higher priority projects
 Late changes may result in substantial re-work
 Skills, training, and staff may not be sufficient
 Personnel issues may cause conflict and problems
 Users, business staff, or subject matter experts may not be available due to conflicting
business priorities

Project risk
 Testers may not communicate their needs and/or the test results adequately
 Developers and/or testers may fail to follow up on information found in testing and reviews
 There may be an improper attitude toward, or expectations of, testing (e.g., not appreciating
the value of finding defects during testing)

Project risk
 Requirements may not be defined well enough
 The requirements may not be met, given existing constraints
 The test environment may not be ready on time
 Data conversion, migration planning, and their tool support may be late
 Weaknesses in the development process may impact the consistency or quality of project
work products
 Poor defect management and similar problems may result in accumulated defects and other
technical debt

5.5.3 Risk-based Testing and Product Quality
 A risk-based approach to testing provides proactive opportunities to reduce the levels of
product risk
 Risk-based testing draws on the collective knowledge and insight of the project stakeholders to
carry out product risk analysis
 To ensure that the likelihood of a product failure is minimized, risk management activities
provide a disciplined approach to

5.5.3 Risk-based Testing and Product Quality
 Analyze (and re-evaluate on a regular basis) what can go wrong (risks)
 Determine which risks are important to deal with
 Implement actions to mitigate those risks
 Make contingency plans to deal with the risks should they become actual events

5.6 Defect Management

 Since one of the objectives of testing is to find defects, defects found during testing should be
logged
 Any defects identified should be investigated and should be tracked from discovery and
classification to their resolution
 In order to manage all defects to resolution, an organization should establish a defect
management process which includes a workflow and rules for classification

 Defects may be reported during coding, static analysis, reviews, dynamic testing, or use of a
software product
 In order to have an effective and efficient defect management process, organizations may
define standards for the attributes, classification, and workflow of defects.

 Typical defect reports have the following objectives:
 Provide developers and other parties with information about any adverse event
that occurred.
 Provide test managers a means of tracking the quality of the work product and the
impact on the testing
 Provide ideas for development and test process improvement

Chapter 6
 6 Tool Support for Testing

6.1 Test Tool Considerations

6.1 Test Tool Considerations
 Test tools can be used to support one or more testing activities. Such tools
include:
 Tools that are directly used in testing, such as test execution tools and test
data preparation tools
 Tools that help to manage requirements, test cases, test procedures,
automated test scripts, test results, test data, and defects, and for reporting
and monitoring test execution
 Tools that are used for investigation and evaluation
 Any tool that assists in testing (a spreadsheet is also a test tool in this
meaning)

6.1.1 Test Tool Classification
 Test tools can have one or more of the following purposes depending on the context:
 Improve the efficiency of test activities by automating repetitive tasks or tasks that require
significant resources when done manually (e.g., test execution, regression testing)
 Improve the quality of test activities by allowing for more consistent testing and a higher
level of defect reproducibility
 Automate activities that cannot be executed manually (e.g., large scale performance testing)
 Increase reliability of testing (e.g., by automating large data comparisons or simulating
behavior)

Tool support for management
 Test management tools and application lifecycle management tools (ALM)
 Requirements management tools (e.g., traceability to test objects)
 Defect management tools
 Configuration management tools
 Continuous integration tools (D)

Tool support for static testing
 Tools that support reviews
 Static analysis tools (D)

Tool support for test design and
implementation
 Test design tools
 Model-Based testing tools
 Test data preparation tools
 Acceptance test driven development (ATDD) and behavior driven development (BDD) tools
 Test driven development (TDD) tools (D)

Tool support for test execution and
logging
 Test execution tools (e.g., to run regression tests)
 Coverage tools (e.g., requirements coverage, code coverage (D))
 Test harnesses (D)
 Unit test framework tools (D)

Tool support for performance
measurement and dynamic analysis
 Performance testing tools
 Monitoring tools
 Dynamic analysis tools (D)

Tool support for specialized testing needs
 Data quality assessment
 Data conversion and migration
 Usability testing
 Accessibility testing
 Localization testing
 Security testing
 Portability testing (e.g., testing software across multiple supported platforms)

6.1.2 Benefits and Risks of Test Automation
 Simply acquiring a tool does not guarantee success.
 Each new tool introduced into an organization will require effort to achieve real and lasting
benefits

Potential benefits of using tools to support
test execution include
 Reduction in repetitive manual work (e.g., running regression tests, environment set up/tear
down tasks, re-entering the same test data, and checking against coding standards), thus
saving time
 Greater consistency and repeatability
 More objective assessment (e.g., static measures, coverage)
 Easier access to information about testing (e.g., statistics and graphs about test progress,
defect rates and performance)

Potential risks of using tools to support
testing include
 Expectations for the tool may be unrealistic (including functionality and ease of
use)
 The time, cost and effort for the initial introduction of a tool may be under-
estimated (including training and external expertise)
 The time and effort needed to achieve significant and continuing benefits from the
tool may be under-estimated

testing include
 The effort required to maintain the test assets generated by the tool may be under-
estimated
 The tool may be relied on too much
 Version control of test assets may be neglected

testing include
 The tool vendor may go out of business, retire the tool, or sell the tool to a different vendor
 The vendor may provide a poor response for support, upgrades, and defect fixes
 An open source project may be suspended
 A new platform or technology may not be supported by the tool
 There may be no clear ownership of the tool (e.g., for mentoring, updates, etc.)

6.2 Effective Use of Tools

6.2.1 Main Principles for Tool Selection
 Assessment of the maturity of the organization, its strengths and
weaknesses
 Identification of opportunities for an improved test process
supported by tools
 Understanding of the technologies used by the test object(s), in
order to select a tool that is compatible with that technology
 The build and continuous integration tools already in use within
the organization, in order to ensure tool compatibility and
integration

 Evaluation of the tool against clear requirements and objective criteria
 Consideration of whether or not the tool is available for a free trial period (and for how long)
 Evaluation of the vendor (including training, support and commercial aspects) or support
for noncommercial (e.g., open source) tools
 Identification of internal requirements for coaching and mentoring in the use of the tool

 Evaluation of training needs, considering the testing (and test automation) skills of
those who will be working directly with the tool(s)
 Consideration of pros and cons of various licensing models (e.g., commercial or
open source)
 Estimation of a cost-benefit ratio based on a concrete business case (if required)

6.2.2 Pilot Projects
 Gaining in-depth knowledge about the tool, understanding both its strengths and
weaknesses
 Evaluating how the tool fits with existing processes and practices, and determining what
would need to change
 Deciding on standard ways of using, managing, storing, and maintaining the tool
 Assessing whether the benefits will be achieved at reasonable cost
 Understanding the metrics that you wish the tool to collect and report

6.2.3 Success Factors for Tools
 Success factors for evaluation, implementation, deployment, and on-going support of tools
within an organization include:
 Rolling out the tool to the rest of the organization incrementally
 Adapting and improving processes to fit with the use of the tool

6.2.3 Success Factors for Tools
 Providing training, coaching, and mentoring for tool users
 Defining guidelines for the use of the tool (e.g., internal standards for automation)
 Implementing a way to gather usage information from the actual use of the tool
 Monitoring tool use and benefits
 Providing support to the users of a given tool
 Gathering lessons learned from all users

Thanks

ISTQB-FL.pptx

More Related Content

What's hot (20)

Similar to ISTQB-FL.pptx (20)

More from Arshad QA (20)

Recently uploaded (20)

ISTQB-FL.pptx