ISTQB Foundation Level Notes: Chapter 2 – Lifecycles

In this short series, I outline the notes that I took while preparing for this foundation exam.

While the content may not have changed drastically in the time that I took the exam, there may have been small changes or additions that my notes don’t cover. So I would advise you that if you do use my notes to help you revise for the Foundation exam, that you use them as a supplement to the most recent edition of the book (this is an affiliate link) and go over your knowledge with practice exam papers.

Previous notes within this blog series:

Software Development Models

Waterfall Model

Waterfall model

Development cycles that facilitate the work-product early to evaluate: V-model and Cyclical (iterative) models

V-model (Sequential)

Requirement specification – capturing of user needs.

Functional specification – definition of functions required to meet user needs.

Technical specification – technical design of functions identified in the functional specification.

Program specification – detailed design of each module or unit to be built to meet required functionality.

Program specification reviewed to check the following:

  • Conformance to the previous work-product
  • That there is sufficient detail for the subsequent work-product to be built correctly
  • That it is testable

Iterative-incremental development models

A working version of the product is built in a series of iterations. Also, referred to as cyclical.

Iterative Incremental Development Model

Cycles referred to as time-boxes. After the time-box a decision is made on what extra functionality needs to be created for the next iteration.

Key feature:

  • Involvement of user representatives in the testing
  • Lack of formal documentation. Test-driven development is used to counter this.
  • Developers make any changes required without formally recording them.Changes may not be traced back. Traceability is reduced.
  • Another issue associated is the amount of regression testing required.

Forms:

  • Prototyping, RAD, Agile software development
  • A proprietary methodology is the Rational Unified Process (RUP)

Test Levels

Verification ensuring the work-products are being developed in the right way.

Validation  ensures the product meets the users needs

Characteristics of good testing across the development life cycle:

  • Early test design
  • Each work product is tested
  • Testers are involved in reviewing requirements before they are released

Unit (component) testing

Code is written before testing can start. It is written in units (also called programs, modules or components). Unit testing is intended to ensure that that code written for the unit meets its specification prior to integration with other units.

Unit testing would verify that all of the code that has been written for the unit can be executed.

Test bases for unit testing:

  • Component requirements
  • The detailed design
  • The code

Test objects:

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

Unit testing approach example: Test Driven Development

Test Driven Development

Test Driven Development is an iterative approach. Tested by the developer. Defects found and fixed during unit testing are often not recorded.

Integration Testing

To expose defects in the interfaces and in the interactions between integrated components or systems.

Common integration strategies:

Big-bang integration – when all units are linked at once

Top-down integration –  when systems is built in stages starting with components that call other components.

Components that call others are usually placed above those that are called.

Bottom-up integration – opposite of top-down integration and the components are integrated in a bottom-up order.

System Testing

Checking functionality from end-to-end perspective. Non-functional testing occurs have:

  • Installability
  • Maintainability
  • Performance
  • Load handling
  • Stress handling
  • Portability
  • Recovery
  • Reliability
  • Usability

All of these can be carried out by an independent team

Acceptance Testing

To provide end users with confidence that the system will function according to their expectations.

Carried out by customers or users of a system.

Typical forms of acceptance testing:

  • User acceptance testing
  • Operational acceptance testing
  • Contract and regulation acceptance testing
  • Alpha + beta testing

Test Types

Functional testing also called specification-based testing: testing against a specification.

Non-functional testing Is testing the behavioural aspects of the system. Black box techniques usually used.

Structural testing is used to measure how much testing has been carried out.

Retesting (Confirmation testing) Testing a fix from a defect after the system has changed.

Regression testing may also be involved to ensure the fix has not impacted on other aspects of the system.

Maintenance Testing

Testing which takes place on a system which is in operation in the live environment.

Type of testing that can be involved:

  • Retesting
  • Regression
  • Conversion

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top