Review (software test)

from Wikipedia, the free encyclopedia
This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.

With the review , work results of the software development are checked manually. Each work result can be reviewed by another person. The review is a static test method and belongs to the category of analytical quality assurance measures.

Based on the IEEE standard IEEE-730 , the review is a more or less formally planned and structured analysis and evaluation process in which project results are presented to a team of reviewers and commented on or approved by them.

The examined subject of a review can be different. A distinction is made primarily between a code review ( source text ) and an architecture review ( software architecture , especially design documents). Technical documents such as readmes , installation instructions or operating instructions, but also programs or scripts that are needed for an installation, as well as documents with information and instructions to other, similarly qualified developers, are assigned to these areas in order to enable them to translate the sources to be successfully reproduced at a later point in time, e.g. for bug fixing (error correction) or further development.

During the code review, a program section is proofread by one or more reviewers after or during development in order to find possible errors, simplifications or test cases. The reviewer himself can be a software developer . For inexperienced developers, the code review by an experienced programmer offers a good opportunity to train themselves quickly and in a practice-oriented manner.

Use of reviews

The use of reviews leads to a significant reduction in errors. According to Capers Jones' studies of around 12,000 projects, requirements reviews lead to a reduction in expected errors by 20% to 50%, top-level design reviews between 30% and 60%, and detailed functional design reviews between 30% and 65% detailed logical design reviews between 35% and 75%. This roughly corresponds to the effectiveness of system tests (25% to 65% of all errors). Errors that are found in the review can often be corrected much more cost-effectively than if they were only found during the test.

Various quality processes take place:

  • The programmer himself discovers a possibility for improvement.
  • The reviewer asks comprehension questions and the programmer can change the code in such a way (for example by appropriate naming or documentation ) that these questions are answered and thus the comprehensibility is improved.
  • The reviewer discovers opportunities for improvement and recommends them to the programmer.

Typical weaknesses that can be discovered through reviews include:

The results of code reviews are, in addition to the errors found, an improved code quality . This in turn prevents future errors and increases efficiency ; Robustness ; Maintainability, e.g. B. through improved code comments .

Reviews and inspections can thus reduce software development costs by up to 30%.

Review process

A typical review consists of the following main phases:

planning
  • Selection of the people involved and filling of the roles
  • Determination of the pre- and post-conditions
Kick off
  • Distribution of documents
  • Explanation of the goals and the process
  • Check the preconditions
Individual preparation
  • Notification of potential errors, questions and comments
Review meeting
  • Discussion and recording of the results
  • Make recommendations or make decisions about mistakes
Revision (rework)
  • Correcting the errors found, typically by the author
Post-processing (follow up)
  • Review of the revision
  • Examination of test end criteria

Review types

Reviews vary between very informal (unstructured) and very formal (i.e. deeply structured and regulated). The way in which a review is carried out depends on the defined objectives of the review (e.g. finding errors, gaining understanding or a discussion with a decision by consensus ).

According to the IEEE 1028 standard, there are the following four review types:

Technical review
  • Technical examination of an essential document (e.g. architectural draft ) for compliance with the specification
  • Purpose: Discussion, making decisions, evaluating alternatives, finding bugs, solving technical problems
Informal review
  • Corresponds to the content of the technical review, but it is supposed to save time and therefore it is carried out as a non-formal process.
  • The informal review is not included in the IEEE standard for software reviews.
  • Structured logging / documentation is possible. In practice, a report is usually only created in a simpler form or sometimes completely omitted.
  • It is a simple type of review that mostly involves “proofreading among colleagues”.
  • In terms of content, the following, practice-related review types can be assigned to this type (terms differ depending on the company culture ):
    • Desk test (program author mentally runs through the code using simple test cases .)
    • Peer Rating (opinion that is anonymously created by equal programmers about a program.)
    • Commentary procedure (author distributes work results to selected reviewers for assessment.)
Walkthrough
  • Discussion of scenarios, test runs and alternatives in a group of equal employees with the least possible effort
  • Purpose: to learn, understand and find mistakes
inspection
  • Most formal review technique with a documented procedure according to IEEE 1028 .
  • Purpose: Visual inspection of documents to find deficiencies (e.g. non-compliance with development standards, non-compliance with specifications , etc.).

Success factors

For reviews to be carried out successfully, various conditions must be met:

  • Definition of clear goals
  • Selection of suitable people
  • Constructive criticism (errors found are brought up objectively and received positively)
  • Psychological aspects (especially ensuring a positive experience for the author)
  • Selection of the appropriate review technique
  • Management support for the review process
  • Existence of a culture of learning and process improvement

Requirements for reviewers:

  • He must not have written the code himself.
  • He has to have tact : Code reviews can be uncomfortable for the programmer, as he could get the impression that his own code is being criticized . If the reviewer does not act tactfully, resistance and disapproval of the source code will be built.

Reviews as a philosophy

Continuous inspection of the source code as with pair programming is also one of the methods of extreme programming . The pair programming used in Extreme Programming (XP) is also referred to as a “code review during development”.

A public review is also a motivation for the open source software.

Online software repositories such as CVS allow groups of individuals to collectively conduct code reviews and thus improve the security and quality of the program code.

Individual evidence

  1. ↑ a b Capers Jones, Chief Scientist Emeritus: Software Quality in 2002: A Survey of the State of the Art. (Pdf; 234 kB) Software Productivity Research an Artemis company, 23 July 2002, p. 56 , accessed on 15. October 2013 (English).
  2. ↑ 1028-2008 - IEEE Standard for Software Reviews and Audits. Retrieved February 2, 2013 .

literature