Purpose:
According to Trumler and Paulish (2016), “The transformation of requirements into working software is a highly creative process. To focus and guide the creativity of a development team into the right direction is important in order to avoid technical debt in form of wrong architectural or design decisions as well as defects found in late project phases like system test because of early missed boundary or exceptional cases during requirements engineering.“
Therefore, this technology is the combination of three practices commonly adopted in software development as a strategy to avoid the accumulation of technical debt. It is a result of an industrial experience report providing information about the adopted practices.
How this tecnology can be used?
This technology is the combination of:
- (1) Specification by Example [13] to ensure that the features are clearly and unambiguously understood by the development team;
- (2) integration tests on component level, based on Cucumber [15] and SpecFlow [16], directly derived from the acceptance criteria, and
- (3) extensive unit testing on class level.
Detailed instructions for adopting this practices can be found in the Trumler and Paulish’s study. Detailed instructions for adopting these practices can be found in Trumler and Paulish’s study.
Prerequisite for use it:
- A Cucumber-based plugin for Visual Studio, to write down the specification and the acceptance criteria in the Gherkin Given-When-Then notation.
Supported TD type(s): Architectural, Build, Code, Design, Requirement, Service.
Supported TDM activity (ies): Prevention.
Source/Input Artifact(s): Testing phase artifacts and source codes.
Project Context, Programming Language or Domain Application: These practices are independent of project context, programming language, and domain application.
Evidence Type(s): Source(s): Case Study.
Reference: