Testing Levels Relate To Software Activities — V Model — Tentamen Software Testing Blog

Image for post
Image for post
Image by foxxi1961 from Pixabay

TL;DR

In the previous post, we described the activities of the test engineers. When we talk about testing levels, that level should be related to something. Testing levels are related to software activities. We will introduce you to software testing based on the remarkable book, Introduction To Software Testing by Paul Ammann and Jeff Offutt.

The testing level is determined by software activities. Source code, design artifacts, requirements, and specifications are software activities. Do not forget that all requirements and specifications will not come from your client. Some requirements are implicit. For example, if a client wants a spreadsheet program, that you could compare its feature set with Google docs or Excel (HICCUPPS).

Testing Levels

Here are testing levels related to software activities:

  • Acceptance testing — assess (provide information) software related to requirements and specification
  • System testing — assess (provide information) software related to architecture
  • Integration testing — assess (provide information) software related to subsystem design
  • Module testing — assess (provide information) software related to detailed design
  • Unit testing — assess (provide information) software related to source code

When we align on left side testing levels, and on right side software activities, we get popular V testing model:

We can see that module design activity is related to unit testing, which means that it is missing a detail design testing level.

Goals

Acceptance testing must include clients because, with acceptance testing, we assess does program satisfies client needs.

The system test assesses program architectural design. An example is when a team needs to choose in web application between a single page architecture or Model-View-Controller architecture. Here we assess would software architecture be able to satisfy client requirements. The system is testes as a whole, and the assumption is that individual modules work correctly.

In Integration testing, we assess the interfaces between modules, and the assumption is that modules individually work correctly.

The detailed design phase produces module architecture and Module testing assess module design, where the module is a collection of units. The unit is an individual procedure with inputs and outputs. The module could be a package or class. We assess module interaction with other modules, units design, and data structures used in this module.

Unit testing assess source code. Here we write tests that exercise module implementation. Unit tests are a very important regression testing artifact, where we test changes in the codebase.

Remember that hard bugs are easy to make but hard to catch.

Originally published at https://blog.tentamen.eu on July 10, 2020.

Written by

Founder of Tentamen, software testing agency.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store