Training Sessions

• These study packs are intended as lessons directly in line

with the chapters in the ISTQB Foundation syllabus.
• There are 6 Main Modules
1. Fundamentals of Testing
2. Testing Throughout the Software Life Cycle
3. Static Techniques
4. Test Design Techniques
5. Test Management
6. Tool Support for Testing
Testing Throughout the Software Life Cycle

Module 2 of 6

2.1 Software Development Models

2.2 Test Levels

2.3 Test Types

2.4 Maintenance Testing

2
Covered in this lesson...

• 2.1 Software Development Models

• 2.2 Test Levels

• 2.3 Test Types

• 2.4 Maintenance Testing

2.1 Software Development Models

4
Software Development Models
• Testing does not exist in isolation
• Test activities are related to software development activities
• Each development activity should have a corresponding test activity
• Different development life cycle models need different approaches to
testing
Good testing can be done in all of these!

Waterfall

V
V-Model
Iterative
V-Model
(Sequential Development Model)
• Lots of variants of the V-model, but the ISTQB syllabus uses four test levels,
corresponding to four development levels:

1. Component (unit) Testing

2. Integration Testing
3. System Testing
But
But of
of course
course there
there can
can
4. Acceptance Testing be
be many
many more!
more!

…System Integration
…User Acceptance
…Operational Acceptance Testing
Verification Validation

• Requirements • Acceptance

V
Test

• HL Design • System Test

• LL Design • Integration Test

• Code • Component Test

Iterative-incremental Development Models

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.

• May be tested at several test levels during each iteration.

• An increment, added to others developed previously, forms a growing partial system, which
should also be
tested.

Regression testing is increasingly important on all iterations after the first one.

Verification and validation can be carried out on each increment.

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

• Test levels can be combined or re-organized depending on the nature of the

project or the system architecture.
Example of Multiple Test Levels:

• For the integration of a Commercial Off-The-Shelf (COTS) software product into a

system, the purchaser may perform integration testing at the system level (e.g.,
integration to the infrastructure and other systems, or system deployment) and
acceptance testing (functional and/or non-functional, and user and/or operational
testing).

• What test levels would you do for a SAP implementation?

• Unit testing on customisations, System testing, integration testing with other
systems, acceptance testing…
2.2 Test Levels

11
 Component Testing

Component Testing (Also known as Unit, Module or Program Testing) is the first test that a software
program/code has to go through before being linked with other areas of the system.

Why?: to check for defects and check functioning of an individual piece of code like program, object or
class.

When?: At the time of code development. Defect usually fixed straight away

How?: Dry run of code using stubs, drivers and Simulators, Test Driven Development (Test First
approach), unit test framework, debugging tool

Targets?: to check functionality and non functional aspects like robustness, memory leakage etc.

12
Component Testing

Test basis:
• Component requirements
• Detailed design
• Data Model
• Code

Typical test objects:

• Components
• Programs
• Data conversion / migration programs
• Database modules

Who?
• Developer who wrote the code
Integration Testing

Tests interfaces between components, interactions with different parts of a system, such as the operating
system, file system and hardware, and interfaces between systems.

Why?: to test communication of data and user/system actions across different systems, hardware,
software or environmental components. It also tests non-functional aspects.

When?: After iterative integration of modules, software and external components.

How?: Ideally this should be done incremental mode rather than a BIG BANG approach as it’s harder to
isolate failures

Targets?: to isolate defects and performance issues arising out of integration of various systems. Early
integration testing helps in reducing the risk and trouble shooting time associated with detection of
defects in later stages.

14
Integration Testing

• Software and system design

• Architecture
Test Basis: • Workflows
• Use cases

Typical Test • Sub-systems database implementation

• Infrastructure
Objects: • Interfaces

System • Configuration data

Configuration
Levels of Integration Testing

• There may be more than one level of integration testing and it may be carried out
on test objects of varying size as follows:

• 1. Component Integration Testing: tests the interactions between software components

and is done after component testing

• 2. System Integration Testing: tests the interactions between different systems or

between hardware and software and may be done after system testing. In this case, the
developing organization may control only one side of the interface. This might be
considered as a risk. Business processes implemented as workflows may involve a series
of systems. Cross-platform issues may be significant.
Integration Testing Strategies

• Integration Strategies
• System Architecture (Top down, Bottom-up)
• Functional Tasks
• Transaction processing sequences
• Or other aspects or components

• Focus on Integration
• Eg. Module A with Module B (not functionality within the individual
module)
Integration Test Strategies

• What strategies can you think of for testing the following:

A B

C D E

F G

I H J
Integration Planning
• Ideally testers should understand architecture and influence integration planning
• Eg. Instead developing modules in sequence
1, 2, 3,…10, if there is a known critical interaction between 2 and 7 then suggest module
development sequence of 1, 2, 7, 3, …
if feasible
System Testing
System testing is concerned with the behavior of a whole system/product. System as a whole is
tested against requirement specifications, business processes and use cases.

Why?: to minimize the risk of environment-specific failures not being found in testing.

When?: test environment should correspond to the final target or production

environment as much as possible.

How?: by using the most appropriate specification-based (black-box) techniques for the
functionality of the system to be tested. For example a decision table for combinations of
business rules. And white-box techniques like Structure-based to assess thoroughness of
testing.

Targets?: investigate functional and non-functional requirements of the system, and data quality
characteristics. Testers also need to deal with incomplete or undocumented requirements.

20
System Testing
• Test Basis:
• System and software requirement specification
• Use cases
• Functional specification
• Risk analysis reports

• Typical Test Objects:

• System, user and operation manuals
• System configuration
• Configuration data

System Testing is usually done by an independent test team.

Acceptance Testing
Acceptance Testing is performed by end users/stakeholders to ensure system meets functional and
non-functional requirements.

Why?: to establish confidence in the system, parts of the system or

specific non-functional characteristics of the system. May assess the system’s readiness for
deployment and use. Defect detection is secondary.

When?: it is generally the last stage of testing but in larger systems, it may be a predecessor of a
large scale SIT.

How?: usually performed by end users and other stakeholders against the business process of the
function where the software is to be deployed.

Targets?: investigate functional and non-functional requirements of the system, and data quality
characteristics. Testers also need to deal with incomplete or undocumented requirements.

22
Acceptance Testing

Test basis: Typical test objects:

• User requirements • Business processes on fully
• System requirements integrated system
• Use cases • Operational and
• Business processes maintenance processes
• Risk analysis reports • User procedures
• Forms
• Reports
• Configuration data
Types of Acceptance Testing

• User acceptance testing

• Typically verifies the fitness for use of the system by business users.

• Operational (acceptance) testing

• The acceptance of the system by the system administrators, including:
• Testing of backup/restore
• Disaster recovery
• User management
• Maintenance tasks
• Data load and migration tasks
• Periodic checks of security vulnerabilities
Types of Acceptance Testing Continued…

• 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 parties agree to the
contract. Regulation acceptance testing is performed against any
regulations that must be adhered to, such as government, legal or safety
regulations.

• Alpha and Beta (or field) Testing

• Developers of market, or COTS, software often want to get feedback
from potential or existing customers in their market before the software
product is put up for sale commercially.
• Alpha testing is performed at the developing organization’s site but not
by the developing team.
• Beta testing, or field-testing, is performed by customers or potential
customers at their own locations.
Types of Acceptance Testing Continued…

Note: Organizations may use other terms as well, such as factory

acceptance testing and site acceptance testing for systems that are tested
before and after being moved to a customer’s site.
2.3 Test Types

27
Test Types
A test type is focused on a particular test objective, which could be any of the following:
• A function to be performed by the software
• A non-functional quality characteristic, such as reliability or usability
• The structure or architecture of the software or system
Change related, i.e. confirming that defects have been fixed (confirmation testing) and looking
for unintended changes (regression testing)

Based on above criteria, broad categories of

testing are:
1. Functional Testing
2. Non-Functional Testing
3. Structural Testing
4. Regression Testing

28
1. Functional Testing
The functions are “what” the system does.

Functional testing is aimed at testing the functionality as described in work products such as
requirements specification, use cases, or they may be undocumented.

Specification-based techniques may be used to derive test conditions and test cases. Functional
Testing concerns the external behavior of the system (Black box testing).

Also includes security testing – investigates the functions (e.g. a firewall) relating to detection of
threats, such as viruses.

Another type of functional testing is interoperability testing, evaluates the capability of the
software product to interact with one or more specified components or systems.

29
2. Non-Functional Testing

Non-functional testing is the testing of “how” the system works.

Includes, but is not limited to, performance testing, load testing, stress
testing, usability testing, maintainability testing, reliability testing and portability testing.

Non Functional testing addresses the quality of software in areas which may not be
directly visible but have a lot of impact on overall quality of software as a whole. External
behavior using specification based techniques can

Types of Non Functional Testing are:

• Usability Testing
• Performance Testing
• Maintainability Testing

ISO-9126
ISO-9126 Software
Software Product
Product Quality
Quality
Characteristics
Characteristics

30
3. Structural Testing
• White-box
• Applicable to all test levels
• Best after specification-based techniques
• Measures thoroughness through assessment of coverage

Coverage is the extent that a structure has been exercised by a test suite,
expressed as a % of the items being covered. If coverage is not 100%, then
more tests may be designed to test those items that were missed to
increase coverage.

Coverage measurement is usually done by a tool.

Structural testing approaches can also be applied at the system level based
on architecture and hierarchy.
For example, based on menu structures.

31
4. Re-Testing and Regression Testing

Confirmation testing is testing a defect fix to

confirm that the original defect has been
successfully removed.

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). These defects may be either in
the software being tested, or in another
related or unrelated software component. It
is performed when the software, or its
environment, is changed.

32
4. Re-Testing and Regression Testing

The extent of regression testing is based on the risk of not finding defects in
software that was working previously - Preform impact analysis.

Tests should be repeatable if they are to be used for confirmation testing and to
assist regression testing.

Regression testing may be performed at all test levels, and includes functional,
non-functional and structural testing. Regression test suites are run many times
and generally evolve slowly, so regression testing is a strong candidate for
automation.

33
 How do you determine how much testing?
• Perform Impact analysis
• What depth of testing into the “fix” or “change” will you decide to test?
• What breadth of testing around the “fix” or “change” will you decide to
test?

Example: A corporate website makes changes to the template

used for all pages.
a. Do you test the change on every page?
b. Do you test every feature on every page?
i.e. Forms, images, help features
2.4 Maintenance Testing

35
Maintenance Testing
Once deployed, a software system is often in service for years or decades. During this time the
system, its configuration data, or its environment are often corrected, changed or extended.
The planning of releases in advance is crucial for successful maintenance testing. A distinction
has to be made between planned releases and hot fixes. Maintenance testing is done on an
existing operational system, and is triggered by modifications, migration, or retirement of the
software or system.
Maintenance Testing Continued…

• Includes:

• Planned enhancement changes

• Corrective and emergency changes

• Operating System

• Database upgrades

• Planned upgrade of COTS software

• Patches

• Migration (from one platform to another)

• Should include operational testing of environment and software

• Conversion testing when migrating data from one system to another

• Testing for the retirement of a system may be needed to test data migration or archiving if data
retention is required
• Involves extensive regression testing and may be done at all test levels

37
End of Module 2

Questions?
End of Module Learning Check - 1

1. What are the characteristics of good testing?

Test early, each development activity has a corresponding testing
activity, focus on objectives, involve testers in reviews

2. What are the test levels?

Component, Integration, System, Acceptance

3. What are the test types?

Functional, Non-functional, Structural and change related

4. What are the common reasons for maintenance testing?

Modification, migration and retirement
 End of Module Learning Check - 2
5. Which test type relates to coverage?
Structural testing

6. Which test type relates to quality characteristics

Non-functional

7. Which test type includes security testing for vulnerabilities?

Functional Testing

8. Which test level can structural testing be performed?

All – component, integration, system and acceptance

ZenQ is a leading provider of ipure-play software quality assurance and testing services to clients across the
globe. We offer a comprehensive range of value-added outsourcing solutions that are of the highest quality
that our customers build quality products on.
 
The contents of this presentation are confidential and intended solely for the use of the individual or entity to
whom they are addressed. The company accepts no liability for any damage caused by using the content of
this presentation.
ISTQB Certified Tester
Foundation Level
• Module 2: Testing Throughout the
Software Lifecycle

February, 2017