Chapter II

Testing throughout the

software development life
cycle
*Testing is an essential part of the software development process
*Testing can be performed at different stages of the software development lifecycle
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 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 involve ed in reviewing documents as soon as drafts(vers.preliminaire) are available in the
development life cycle.
Software Development Model

Sequential development model: describes the SD

process s a linear, sequential flow of activities. This
means that any phase in the development process
should begin when the previous phase is complete.

SDLC

Incremental and iterative development : the functionalities

of the software increase incrementally. The size of these
increments of functionalities varies, with some methods
having larger steps and others having smaller ones.
Waterfall :

 Development activities are carried out one after the other.

 In this model, testing activities only take place after all other
development activities are complete.
V-Model :

 Unlike the 'waterfall’ model, the V-Model embeds the testing process
throughout the development process, applying the principle of " Test
Early ".
Iterative development:
• Each iteration delivers working software that is an increasing subset of the overall feature set until final
software is delivered or development is halted.

Incremental development:
• Incremental development involves defining requirements, designing, developing and testing a system in
pieces, which means that software functionality increases incrementally
*Rational unified Process: iteration tends to be relatively long (e.g. two to three months), and feature increments are
proportionally large, on the order of two or three feature groups.

*Scrum: Each iteration tends to be relatively short, and feature increments are proportionally small, on the order of a few
improvements and/or two or three new features.

*Kanban: Implemented with iterations of fixed or non-fixed duration, which can either deliver a single improvement or
characteristic at the end, or group together groups of characteristics to
deliver them at once.

*spiral: (by prototyping): This is about creating experimental increments, some of which can be heavily reworked or even
dropped in further development work.
 Software development lifecycle models must be selected and adapted to the con text of project and product
characteristics. An appropriate software development lifecycle model should be selected and adapted based
on the project goal, the type of product being developed, business priorities (time to market), and identified
product and project risks.

 Software development lifecycle models themselves can be combined , for example, a Vmodel may b e used for
the development t and testing of the backend system s an d their integration

 Internet of things IoT : 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
Component Testing

 Component testing searches for defects in , and verifies the functioning of, software modules,
programms, objects, classes, ect, that are separately testable.

 Component testing is also known as UNIT, MODULE, program , structure, code testing.

 Component testing may be required to test core functionality and specific non –functional
characterstics, such as resource behavior.

 Typically conducted with access to the code in form of White Box Testing with support of
development en vironment.

Test Basis for Component testing: Typical Test Objectives :

• Components
• Component requirement
• Programs
• Detailed design
• Data conversion/migration program
• code
• Database Module
Integration Testing

 Integration Testing tests interfaces between components, interactions with different parts of the system
and interfaces between systems.

 They may b e more than one level of integration testing

 Component integration testing.

 System integration testing.

Test Basis for Integration testing Typical Test Objects

• Subsystems
• Software and system design
• Database implementations
• Architecture, workflow
• Infrastructure, interfaces
• Use cases
• System config and configuration data
System Testing
 System testing is concerned with the behavior of a whole system/product.

 In system testing, the test environment should correspond to the final target or production
environment to minimize the risk of environment-specific failure.

 Systems testing may include tests based on risk.

 Testers also need to deal with incomplete or un document ted requirements.

 System integration Testing can be performed after System Testing as well.

Test Basis for System testing Typical Test Objects

• System and Software requirement specs • System, user and operation manuals
• Functional specification • System configuration
• Use cases • Configuration data
• Risk analysis report
Acceptance Testing
 Acceptance testing is to establish confidence in the system , parts of the system or specific non-functional characteristics
of the system.

 Typical forms of acceptance testing include :

 User acceptance testing
 Operational (acceptance) testing
 Con tract and regulation acceptance testing

Test Basis for Acceptance testing Typical Test Objects

• User and Software requirements specs • Business process, operational process

• Business Process • User procedures
• Use cases • Forms, reports
• Risk analysis report • Configuration data
 Integration Testing Approaches, Strategies, Methodologies

Approach to Big Bang:

Here all the components are integrated together at once and then tested. Convenient for Small systems.

Bottom-up integration In the bottom-up approach , each module at the lower levels is tested with modules higher
until all modules are tested. Driver's help is
needed for testing. The location of breakdowns is easier. No wasted time waiting for all the modules are developed
unlike the big bang approach.

Top-down integration: In the Top down approach, testing takes place from top to bottom following the control flow
of the software system. Takes the help of stubs for testing. Fault finding is easier. Possibility of obtaining an early
prototype. Critical modules are tested first so that major design flaws could be found and fixed first.
 Testing Types
Testing of functions (functional testing)
 Functional testing is all about testing the core features of testing.

 The functions are “WHAT” the system does.

 The general levels like-unit testing, integration testing , system testing and acceptance testing are conducted as functional
level of testing.

Testing of Non-functions characteristics

 Non-Functional testing is about testing enhancing the quality characteristics of the system .

 The Non-functions are “HOW” the system works.

 The Non-Functional testing includes but not limited to , performance testing, stress testing, usability testing, maintainability
testing, reliability testing and probability testing.

White Box Testing (Testing of a Software Structure)

 White box tests are tests based on the internal structure or implementation of the system.
Change Related Testing

Confirmation : after a defect is detected and fixed , it should be re-tested to confirm that the defect reported is successfully
fixed, this is also clled Re-testing(confirmation Test)

Regression Testing : is the repeated testing of an already tested program, after modification to check if there are any dverse
affect on unchanged part due to changed part.

As regression doesn’t hav e a prim ary o bjec tiv e of fin din g defects it is considered as a good condidate for automatio n.

Regression testing is also conducted in the scen arios where :

• A live operational system’s environment changes.
• A new functionality or feature is included to a live operational system.ss
Maintenance testing
Once deployed, a software system is often in service for years, during this time the system , its configuration
data , or its environment are often corrected , changed or extended

Modification include planned enhanced changes, corrective and emergency changes and changes of
environment.

These include updates, upgrades, migration, and retirement.

Depending on the changes, maintenance testing (regression testing) may be don e at all test levels and for any
all test types.

Triggers for maintenance testing

*modification
*Migration
*retirement
Impact analysis
May be done before a change is made , to help decide if the change should be made, based on the potential
consequences in other areas of the system

Impact analysis can be difficult if :

 Specifications :business requirements, user stories.. are out of date or missing

 Test cases are not documented or out of date
 Bidirectional traceability between tests and the test basis has not been maintained
Thanks for your attention