SE401 · Testing throughout the SDLC · Annotated SlidesTesting throughout the Software Development Life Cycle
Original
Overview

Testing throughout the Software Development Life Cycle

Verification vs. validation, the V-model and iterative models, the test levels (component, integration, system, acceptance) with their objectives, test basis and typical defects, the test types (functional, non-functional, structural, change-related), and maintenance testing.

How to read this page

Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.

All 44 slides
  1. 1 Slide 1
  2. 2 • Software development models • Test Levels
  3. 3 • Testing is important in the software development life cycle • The life cycle model will determine how to organize the testing
  4. 4 • Verification
  5. 5 Waterfall model
  6. 6 The V-model
  7. 7 • Testing needs to begin as early as possible in the life cycle. • Testing can be integrated into each phase of the life cycle.
  8. 8 Iterative-incremental development model
  9. 9 • In any life cycle model, there are several characteristics of good testing:
  10. 10 Testing within a life cycle model
  11. 11 • Acceptance : is the responsibility of the customer – in general. The goal is to gain confidence in the system
  12. 12 • For each test level, please note:
  13. 13 • Verifying the functioning of software items (modules, methods, objects, classes etc.) that are separately testable
  14. 14 • All materials that are applicable for the component under test:
  15. 15 • Writing code to test the project code • Stubs, drivers and simulators may be used.
  16. 16 Component testing - example
  17. 17 • Component testing usually involves the programmer who wrote the code.
  18. 18 • Tests interfaces between components
  19. 19 • Software and system design • The system architecture
  20. 20 • The item under test includes
  21. 21 • Component integration
  22. 22 • Start integration with those components that are expected to cause most problems.
  23. 23 • Testing the behavior of the whole system as defined by the scope of the project.
  24. 24 • System requirements specification , both functional and non functional • Business processes
  25. 25 • The entire integrated system • User manuals
  26. 26 ee
  27. 27 • The questions to be answered:
  28. 28 • User requirements specification • Use cases
  29. 29 • User acceptance testing – validate the fitness for use of the system by users.
  30. 30 • Contract and regulation acceptance testing performed against a contract’s acceptance criteria (i.e. governmental, legal or safety
  31. 31 • Customers or users of a system • Stakeholders may be involved
  32. 32 Test Types
  33. 33 • Objectives
  34. 34 • Objectives
  35. 35 Software Product Quality
  36. 36 • Objectives
  37. 37 • Test basis
  38. 38 • Confirmation testing
  39. 39 • Objective
  40. 40 • Approach
  41. 41 • Objectives
  42. 42 • Modifications
  43. 43 • Scope
  44. 44 • Approach
Slide 1 / 44

Slide 1

Slide 1: Slide 1
Slide 2 / 44

• Software development models • Test Levels

Slide 2: • Software development models • Test Levels
Slide 3 / 44

• Testing is important in the software development life cycle • The life cycle model will determine how to organize the testing

Slide 3: • Testing is important in the software development life cycle • The life cycle model will determine how to organize the testing
Slide 4 / 44

• Verification

Slide 4: • Verification

Notes

  1. Verification: "Are we building the product RIGHT?" (meets its specification). Validation: "Are we building the RIGHT product?" (meets users’ needs).

  2. Tip Verification: "Are we building the product RIGHT?" (meets its specification). Validation: "Are we building the RIGHT product?" (meets users’ needs).

Exam angle

PredictionQ1

"Are we building the right product?" is:

Slide 5 / 44

Waterfall model

Slide 5: Waterfall model

Notes

  1. V-model: each development phase on the left has a matching test level on the right (requirements ↔ acceptance, design ↔ system/integration, code ↔ component).

Slide 6 / 44

The V-model

Slide 6: The V-model
Slide 7 / 44

• Testing needs to begin as early as possible in the life cycle. • Testing can be integrated into each phase of the life cycle.

Slide 7: • Testing needs to begin as early as possible in the life cycle. • Testing can be integrated into each phase of the life cycle.

Notes

  1. Testing should begin as early as possible: reviews of requirements and designs find defects when they are cheapest.

Slide 8 / 44

Iterative-incremental development model

Slide 8: Iterative-incremental development model
Slide 9 / 44

• In any life cycle model, there are several characteristics of good testing:

Slide 9: • In any life cycle model, there are several characteristics of good testing:
Slide 10 / 44

Testing within a life cycle model

Slide 10: Testing within a life cycle model
Slide 11 / 44

• Acceptance : is the responsibility of the customer – in general. The goal is to gain confidence in the system

Slide 11: • Acceptance : is the responsibility of the customer – in general. The goal is to gain confidence in the system
Slide 12 / 44

• For each test level, please note:

Slide 12: • For each test level, please note:
Slide 13 / 44

• Verifying the functioning of software items (modules, methods, objects, classes etc.) that are separately testable

Slide 13: • Verifying the functioning of software items (modules, methods, objects, classes etc.) that are separately testable

Notes

  1. Component (unit) testing: individual components in isolation, usually by developers, often with stubs and drivers.

Slide 14 / 44

• All materials that are applicable for the component under test:

Slide 14: • All materials that are applicable for the component under test:
Slide 15 / 44

• Writing code to test the project code • Stubs, drivers and simulators may be used.

Slide 15: • Writing code to test the project code • Stubs, drivers and simulators may be used.
Slide 16 / 44

Component testing - example

Slide 16: Component testing - example
Slide 17 / 44

• Component testing usually involves the programmer who wrote the code.

Slide 17: • Component testing usually involves the programmer who wrote the code.
Slide 18 / 44

• Tests interfaces between components

Slide 18: • Tests interfaces between components
Slide 19 / 44

• Software and system design • The system architecture

Slide 19: • Software and system design • The system architecture
Slide 20 / 44

• The item under test includes

Slide 20: • The item under test includes
Slide 21 / 44

• Component integration

Slide 21: • Component integration
Slide 22 / 44

• Start integration with those components that are expected to cause most problems.

Slide 22: • Start integration with those components that are expected to cause most problems.
Slide 23 / 44

• Testing the behavior of the whole system as defined by the scope of the project.

Slide 23: • Testing the behavior of the whole system as defined by the scope of the project.

Notes

  1. System testing: the behaviour of the whole system against the requirements, in an environment close to production.

Slide 24 / 44

• System requirements specification , both functional and non functional • Business processes

Slide 24: • System requirements specification , both functional and non functional • Business processes
Slide 25 / 44

• The entire integrated system • User manuals

Slide 25: • The entire integrated system • User manuals
Slide 26 / 44

ee

Slide 26: ee
Slide 27 / 44

• The questions to be answered:

Slide 27: • The questions to be answered:
Slide 28 / 44

• User requirements specification • Use cases

Slide 28: • User requirements specification • Use cases

Notes

  1. Acceptance testing: establish confidence that the system is fit for use: user acceptance, operational, contract and regulation, alpha and beta.

Exam angle

PredictionQ1

Testing against contract requirements before the customer signs off is:

Slide 29 / 44

• User acceptance testing – validate the fitness for use of the system by users.

Slide 29: • User acceptance testing – validate the fitness for use of the system by users.
Slide 30 / 44

• Contract and regulation acceptance testing performed against a contract’s acceptance criteria (i.e. governmental, legal or safety

Slide 30: • Contract and regulation acceptance testing performed against a contract’s acceptance criteria (i.e. governmental, legal or safety
Slide 31 / 44

• Customers or users of a system • Stakeholders may be involved

Slide 31: • Customers or users of a system • Stakeholders may be involved
Slide 32 / 44

Test Types

Slide 32: Test Types
Slide 33 / 44

• Objectives

Slide 33: • Objectives
Slide 34 / 44

• Objectives

Slide 34: • Objectives
Slide 35 / 44

Software Product Quality

Slide 35: Software Product Quality
Slide 36 / 44

• Objectives

Slide 36: • Objectives
Slide 37 / 44

• Test basis

Slide 37: • Test basis
Slide 38 / 44

• Confirmation testing

Slide 38: • Confirmation testing

Notes

  1. Confirmation testing (re-testing): check that a fixed defect is really fixed. Regression testing: check that the change broke nothing else.

  2. Trap Re-testing confirms the FIX; regression testing looks for SIDE EFFECTS.

Exam angle

PredictionQ1

Running the failed test again after a bug fix is:

Slide 39 / 44

• Objective

Slide 39: • Objective
Slide 40 / 44

• Approach

Slide 40: • Approach
Slide 41 / 44

• Objectives

Slide 41: • Objectives

Notes

  1. Maintenance testing: triggered by modifications, migration or retirement of a live system; includes impact analysis and regression testing.

Slide 42 / 44

• Modifications

Slide 42: • Modifications
Slide 43 / 44

• Scope

Slide 43: • Scope
Slide 44 / 44

• Approach

Slide 44: • Approach