Test effort

In software development, test effort refers to the expenses for (still to come) tests. There is a relation with test costs and failure costs (direct, indirect, costs for fault correction). Some factors which influence test effort are: maturity of the software development process, quality and testability of the testobject, test infrastructure, skills of staff members, quality goals and test strategy.

Methods for estimation of the test effort

To analyse all factors is difficult, because most of the factors influence each other. Following approaches can be used for the estimation: top-down estimation and bottom-up estimation. The top-down techniques are formula based and they are relative to the expenses for development: Function Point Analysis (FPA) and Test Point Analysis (TPA) amongst others. Bottom-up techniques are based on detailed information and involve often experts. The following techniques belong here: Work Breakdown Structure (WBS) and Wide Band Delphi (WBD).

We can also use the following techniques for estimating the test effort:

  • Conversion of software size into person hours of effort directly using a conversion factor. For example, we assign 2 person hours of testing effort per one Function Point of software size or 4 person hours of testing effort per one use case point or 3 person hours of testing effort per one Software Size Unit
  • Conversion of software size into testing project size such as Test Points or Software Test Units using a conversion factor and then convert testing project size into effort
  • Compute testing project size using Test Points of Software Test Units. Methodology for deriving the testing project size in Test Points is not well documented. However, methodology for deriving Software Test Units is defined in a paper by Murali
  • We can also derive software testing project size and effort using Delphi Technique or Analogy Based Estimation technique.

Test efforts from literature

In literature test efforts relative to total costs are between 20% and 70%. These values are amongst others dependent from the project specific conditions. When looking for the test effort in the single phases of the test process, these are diversely distributed: with about 40% for test specification and test execution each.

gollark: Stupid eyes.
gollark: My eyes apparently don't like focusing on far away things, and I see weird blobs if I'm outside/looking at bright things sometimes.
gollark: Apparently, talking/singing/whatever *is* quite bad for spreading COVID-19.
gollark: The UK has actually opened up shops again. This seems like it might be a bad idea, but oh well.
gollark: Oh dear. That sounds painful.

References
  • Andreas Spillner, Tilo Linz, Hans Schäfer. (2006). Software Testing Foundations - A Study Guide for the Certified Tester Exam - Foundation Level - ISTQB compliant, 1st print. dpunkt.verlag GmbH, Heidelberg, Germany. ISBN 3-89864-363-8.
  • Erik van Veenendaal (Hrsg. und Mitautor): The Testing Practitioner. 3. Auflage. UTN Publishers, CN Den Bosch, Niederlande 2005, ISBN 90-72194-65-9.
  • Thomas Müller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson and Erik van Veendendal. (2005). Certified Tester - Foundation Level Syllabus - Version 2005, International Software Testing Qualifications Board (ISTQB), Möhrendorf, Germany. (PDF; 0,424 MB).
  • Andreas Spillner, Tilo Linz, Thomas Roßner, Mario Winter: Praxiswissen Softwaretest - Testmanagement: Aus- und Weiterbildung zum Certified Tester: Advanced Level nach ISTQB-Standard. 1. Auflage. dpunkt.verlag GmbH, Heidelberg 2006, ISBN 3-89864-275-5.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.