Testing Throughout the Software Life Cycle Section 2ISTQB Foundation

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

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.

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

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.

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

Static

Dyna

mic

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

---------

--------------------

-------------------------------

-----------------------------------------------------

-------------------------------------------

V-model

BusinessRequirements

Static

Dyn

amic

Interface Specifications

SystemSpecifications

DesignSpecification

ComponentSpecification

SourceCode

ObjectCode

ComponentTesting

ComponentIntegrationTesting

SystemTesting

SystemIntegrationTesting

AcceptanceTesting

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.

Iterative-Incremental (Agile) Models

Reqts

Test

Code

Design Reqts

Test

Code

DesignReqts

Test

Code

Design

Increment 1 Increment 2 Increment 3

----------------------------------------------------------------------

----------------------------------------------------------------------

----------------------------------------------------------------------

---------------------------------------------------------------------- timebox timebox timebox

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

ComponentOr

SubsystemComponent

test

Code Unit A

Code Unit B

Code Unit C

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 Integration Testing.

Component A

Component CComponent B

Integration

Testing

Integration Testing

Inte

grat

ion

Test

ing

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.

V-model document: System Specification and System Testing.

System Testing

Requirements

Events

Inpu

ts

Outcom

e

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 testingis complete by independent system testers in anear live environment.

When testing links with external systems, testersmay 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.

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

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.

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 TestingNon-functional testing includes:• Performance• Load• Stress• Usability• Accessibility• Maintainability• Reliability• Portability

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 TestingWhite 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.

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.

• 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 keyfunctionality

New Changes

?

?

?

Assessimpact ofchanges

onrest ofsystem

Live System

RegressionTest Pack

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

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 2ISTQB Foundation

Thank You