COURSE IS NOW FULLY AVAILABLE AND LIVE HERE: https://goo.gl/gVukvc What you will learn in this second section Software Testing Methodologies. Waterfall, V-Model and Iterative What is unity or component system testing What is integration, system and acceptance means Differences between functional and non-functional testing What is a structural testing Change-related testing Maintenance testing Access my blog for much more material and the mock exams. www.rogeriodasilva.com

1. Testing Throughout the Software Life Cycle
Section 2
ISTQB Foundation

2. Summary
What you will learn in this second section
• Software Testing Methodologies. Waterfall, V-Model and Iterative
• What is unity or component system testing
• What is integration, system and acceptance means
• Differences between functional and non-functional testing
• What is a structural testing
• Change-related testing
• Maintenance testing

3. Life Cycle Models
Sequential Life Cycle Models
In sequential models the entire system is
built in a single sequence of activities that
successively define, build test and implement
the software.
Examples are waterfall, Structured System
Analysis and Design Method (SSADM), the
V-model and the W-model.
Iterative-Incremental (Agile) Life Cycle Models
In iterative-incremental development models, systems
are built in a series of short development cycles which
deliver working systems in a number of separate
increments that can later be integrated together.
Agile development is a term for several methodologies
including Scrum, Crystal Clear and many more.
Each has its specific approach but all share the common
vision and core values as continuous planning, testing,
integration, for the project and software. Is adaptable and
they all focus on empowering people to collaborate and
make decisions together quickly and effectively.

4. Life Cycle Models
Testing does not exist in isolation. Test activities are related to software development activities.
Different development life cycle models, methodologies, need different approaches to testing.
There are many system development life cycle models, which fall into two main categories:
Sequential
• Waterfall
• V-Model
Iterative-Incremental (Agile)
• Rapid Application Development (RAD)
• Rational Unified Process (PUP)
• Extreme Programming (XP)
• Scrum
• Dynamic Systems Development Method (DSDM) Atern

5. Waterfall Model
Life cycle through which a project goes. Sequential or linear design process.
Testing is carried out at the end.
Initiation
Analysis
Design
Build
Test
Deploy
This is the traditional approach to systems development.
Each stage is quite separate, carried out by specialists,
and each must complete before the next begins. Each
stage outputs a deliverable which is input to the next.
All testing is done at the end, after the code is developed.
Therefore this model does not allow for early testing, as
recommended in the principles earlier.

6. V-model
Although the similarities with the sequential method as
in waterfall, the V-model includes a number of different
test levels, each correspond to a development stage.
This allows testing activities to be fully integrated with
other tasks in the project life cycle.
Mini cycles show the purpose of each test level, and
show the importance of catching defects early.
The V-model also shows how static testing can be
carried out during the development stages, before the
code is written. Documents are identified which can be
reviewed to trap faults as early as possible.
Requirements Product Ready
Coding

7. V-model
Then goes on to describe two different integration
test levels, so in this demonstration, I’ll describe a
V-model with 5 levels of testing instead:
- Component testing
- Component integration testing
- System testing
- System integration testing
- Acceptance testing
There’s many variations of V-model, with slightly
different number and description of levels. The ISTQB
Foundation exam syllabus refers to a model with 4
test levels:
- Component testing
- Integration testing
- System testing
- Acceptance testing

8. ---------
--------------------
-------------------------------
-----------------------------------------------------
-------------------------------------------
V-model
Business
Requirements
Interface
Specifications
System
Specifications
Design
Specification
Component
Specification
Source
Code
Object
Code
Component
Testing
Component
Integration
Testing
System
Testing
System
Integration
Testing
Acceptance
Testing

9. Iterative-Incremental (Agile) Models
A software design model where the stages are ongoing opposite to the
waterfall method. Testing occurs as part of each sprint.
Agile development is an umbrella term for several iterative and incremental
software development methodologies.
Most popular agile methodologies are: Scrum, Crystal Clear, XP (Extreme
Programming), DSDM and FDD.
Typically, development teams work closely together with fewer formal
documents and more emphasis on face-to-face communication.
This minimises overall risk and allows the project to adapt to changes quickly.

10. Iterative-Incremental (Agile) Models
Reqts
Test
Code
Design Reqts
Test
Code
Design
Reqts
Test
Code
Design
Increment 1 Increment 2 Increment 3
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
timebox timebox timebox

11. Unity or Component Testing
Tests individual units or pieces of code for a system. The aim of component testing is to
determine whether an individual function works properly in isolation before integrate with the
system then combine it with other components.
Component testing is different from all later test stages as it is not done by testers but by the
developers of the code, in the developer’s environment using IDE, debugging tools and test
frameworks incorporating stubs and drivers.
As an example, in the V-model method Component Specification and Component Testing
level unity is where is located at.
Code Review
Component
Or
Subsystem
Component
test
Code Unit A
Code Unit B
Code Unit C

12. Integration Testing
Performed to ensure that two modules operate
together correctly. The aim is to test all major
interfaces and interactions between the individual
components, and to uncover communication
failures between components.
It should not test the functionality within the
component (by this time it has already been done
by component testing), only focusing how it
communicate with each other. It is normally
performed by developers in the development
environment.
V-model document: Design Specification and
Component A
Component CComponent B
Integration
Testing

13. System Testing
Tests the various parts of the applications work
together within a system work. This test the behaviour
of an end-to-end integrated system as defined by the
scope of a development project. It is usually conducted
by independent testers.
System testing may include tests based on risks,
requirements, business processes, use cases or high
level text descriptions, models or system behaviour,
interactions with the operating system and system
resources.
The test environment should be as close to the
production environment as possible in order to
minimise the risk of environment-specific failures not
being found in testing.
System Testing
Requirements
Events
Inputs
Outcome

14. System Integration Testing
Most computer system will link with other systems, either internally to the organisation of
externally.
The purpose of system integration testing is to expose defects in the interfaces and
interactions between systems and between hardware and software.
System Under Test
Internet
Other current
systems
Legacy systems
Central databaseExternal systems or databases
It is normally carried out once system testing
is complete by independent system testers in a
near live environment.
When testing links with external systems, testers
may control only their own side of the interface,
which might be considered as a risk, as their test
system may be linked to an external production
system.
Workflow implementation of business processes
may involve a series of systems, where cross
platform issues may be significant.

15. To determine whether the product indeed satisfies its specifications and user story
requirements.
The purpose of acceptance testing is to establish confidence and main focus is ensuring
is fit for purpose, not finding defects.
Acceptance can be carried out by real business users or by independent testers
representing users.
Acceptance testing is normally the final stage of testing before deployment.
V-model document: Business requirement and Acceptance testing.
Can also be
called as
UAT (User
Acceptance
Testing)
Acceptance Testing
DEV QA UAT PROD

16. Functional Testing
Testing what the system does, based on analysis of specified requirements.
Functional testing is concerned with WHAT the system must do to achieve its objectives,
as defined in business requirements, functional specifications, use cases, business
process models, etc.
It considers the external behaviour of the software, hence is black-box testing.
Black
box
Input Output
Black Box TestingFunctional testing is usually associated with
data manipulation, such as input, validation,
processing, storage and output.

17. Non-Functional Testing
Testing how well the system meets the required software characteristics such as
performance and usability.
It tests the attributes of a system that do not relate to functionality. It is concerned with how
well a system works.
It considers constraints on the functionality on how, how often, who or where a function can
take place.
Black
box
Input Output
Black Box Testing
Non-functional testing includes:
• Performance
• Load
• Stress
• Usability
• Accessibility
• Maintainability
• Reliability
• Portability

18. Structural Testing
Testing that takes into account the internal mechanism [structure] of a system or
component. Types include branch testing, path testing, statement testing.
Input Output
White Box Testing
White box
Coverage measurement applies at all levels, as any aspect of a system which can be
represented in a structural diagram can be used as the basis for structural testing.
• Program code design: coverage of statement, decisions, paths
• Component hierarchy diagram: coverage of component interfaces
• Web pages structure: coverage of page navigation
Structural testing, it is sometimes called glass box,
usually follows specification-based tests to ensure
thoroughness of coverage. Full structured testing
is very thorough but time-consuming, and is often
mandated in safety-critical system such as life
support machines.

19. Remember Password
Regression testing of a previously tested program following
modification to ensure that defects have not been introduced or
uncovered in unchanged areas of the software as a result of the
changes made. An estimated 20% to 50% of changes introduce
new defects.
It may be performed at all test levels and types, including functional,
non-functional and structural testing. Regression should take place
at all stages of testing after a functional improvement or repair.
Change-related Testing
Testing a system following modifications or corrections; includes re-testing and regression testing. This is
testing following a change or fix to the software or environment. This should involve two types of test:
Re-testing or confirmation testing, that reruns test cases that
previously failed in order to verify the success of corrective actions.
Username
Password
Remember me
Sign In
Regression
RetestingAutomation testing, this is an advanced level for new be testers,
make sure you follow my blog for other courses specifically on automation.
Retesting and regression should be repeatable, so they can re-run every time there is a change or fix.
Its essential to automate both re-testing and regression tests.
Automation is not a full substitute to manual testing as not 100% automation testing can be achieved and it shouldn’t.

20. • Planned enhancements or upgrades to business systems
• Corrective and emergency changes
• Changes to the operating environment such as system upgrades
• Upgrade of commercial-off-the-shelf software
• Migration of applications from one platform to another
• Retirement of legacy software systems
Maintenance Testing
Once deployed, as software system is often in service for years or decades. During this time the
operational system, its configuration data or its environment are often corrected, changed or extended.
The testing of these changes is called maintenance testing, and is
triggered by:
Select key
functionality
New
Changes
?
?
?
Assess
impact of
changes
on
rest of
system
Live System
Regression
Test Pack

21. Review
This is what you have learned so far...
• Waterfall Model
• V-Model
• Iterative Model
• Unity or Component testing
• Integration testing
• System testing
• Acceptance testing
• Functional testing
• Non-Functional testing
• Structural testing
• Change-related Testing
• Maintenance Testing

22. End of Section
2
Do the Quiz (attached) for Section
2
Questions?
Comments?
Thumbs up and Share it if you like
this.
Testing Throughout the Software
Life Cycle – Section 2
ISTQB Foundation
Thank You