1-2-4 Software Construction Process

[Activities of software construction process] (i) Software construction (ii) Evaluation of software code and test results

(i) Development of software units and databases

Each software unit and database are to be developed and documented. (ii) Development of test procedures and test data

Test procedures and test data for testing each software unit and database are to be developed and documented. (iii) Implementation of software unit and database testing

Each software unit and database is to be tested to confirm that it satisfies software requirements, and the results are to be documented in a software unit test report document. (iv) Updating user documentation

User documentation is to be updated as necessary. (v) Updating of test requirements for software integration

The test requirements and the schedule for software integration are to be updated.

• • Code auditor
  This is a tool to verify whether a program follows coding conventions. · 1 question
• • Source code editor
  This is dedicated software for creating programs (i.e., the source code). It offers functions, such as code completion which displays a menu when a portion of a command or a variable name is entered, so that an input item can be selected from the input candidates in the menu, and syntax highlighting which displays an instruction in a code in color according to the type or classification of the instruction.

• • White box test
  This is a test implemented with a focus on the internal specifications (e.g., algorithms, logic paths) of software units (i.e., modules). It is generally used only in the software unit test that is performed by developers.

• • Statement coverage
  This designs test cases that execute every statement in a unit (i.e., module) at least once.
• • Decision condition coverage (branch coverage)
  This designs test cases that execute TRUE/FALSE at least once for every “decision condition” (i.e., branch) in a unit (i.e., module). · 3 questions
• • Condition coverage
  This designs test cases that execute TRUE/FALSE at least once for every “condition” used as a decision condition.
• • Decision condition / condition coverage
  This designs test cases that fulfill both decision condition coverage (i.e., branch coverage) and condition coverage.
• • Multiple-condition coverage
  This designs test cases that include every combination of TRUE/FALSE for every condition. · 1 question

Enlarge original visual

Source visual description

A decision diamond reads Condition 1 and condition 2. Yes flows down through Process; No follows the right branch and rejoins beneath Process. The Truth value chart has columns Condition 1, Condition 2, Decision condition. Row I: TRUE, TRUE, TRUE. Row II: TRUE, FALSE, FALSE. Row III: FALSE, TRUE, FALSE. Row IV: FALSE, FALSE, FALSE.

Coverage criteria	Test cases that fulfill coverage criteria
Statement coverage	(I)
Decision condition coverage (branch coverage)	(I and II) or (I and III) or (I and IV)
Condition coverage	(I and IV) or (II and III)
Decision condition /condition coverage	(I and II and III) Note: Avoid (I and IV).
Multiple-condition coverage	(I and II and III and IV)

View original table · p. 261

Enlarge original table

Note: Verification of all test cases may be difficult when processing is complex. In such a case, coverage rate (i.e., test coverage), a metric that represents coverage rate of test cases (or of paths), is used. The idea is to set a test coverage target in consideration of the balance between productivity and reliability from perspectives of cost, delivery, and others; in other words, the test is completed when this target is cleared.

• • Black box test
  This is a test performed with a focus on the external specifications (i.e., functional specifications and input/output (interface) specifications) of software units (i.e., modules). It is used in all software testing, including software unit test.
• • Equivalence partitioning / boundary value analysis
  This is a method that partitions input data into several groups (i.e., classes), and test data is selected from each group. In general, input data is partitioned into a valid equivalence class (i.e., the group processed normally) and an invalid equivalence class (i.e., the group handled as an error), and then the valid equivalence class is further staged if necessary. From among these partitioned groups, representative values are used as test cases in the case of equivalence partitioning, and values at both ends of each class are used in the case of boundary value analysis. Example: For a unit processed normally when input data is between 10 and 30 · 1 question

Enlarge original visual

Source visual description

The numeric strip reads ..., 7, 8, 9, 10, 11, ..., 29, 30, 31, 32, 33, .... The middle shaded Valid equivalence class runs from 10 through 30; each side is an Invalid equivalence class. Dashed boundaries separate 9 from 10 and 30 from 31. Equivalence partitioning: {7, 21, 39}, one representative value from each class. Boundary value analysis: {9, 10, 30, 31}, all boundary values from each class.

• • Cause-effect graph method
  This method represents the cause-effect relationship of input (i.e., cause) and output (i.e., effect) as a graph (i.e., cause-effect graph) when class sorting of input data is difficult. It is a method that then creates a decision table based on the graph to sort out test data.

• • Error embedding method
  This is a method that embeds the known errors in software, and the number of inherent potential errors is estimated from the ratio of the number of discovered known errors to the number of inherent errors (i.e., number of errors not already known). · 1 question
• • Experimental design
  This is a method that selects test data efficiently through statistical analysis, when tests that use large volumes of data are required.
• • Metrics measurement

This is a method that collects and analyzes metrics for the size, complexity, and others of software on the basis of development information and others. Then, the possibility that errors or defects are present is investigated.

[Examples of test support tools]

• • Program static analysis tools
  These are tools that support the analysis of static testing (i.e., testing that does not execute the program), such as desktop debugging for confirming on the desktop that values have not been substituted in variables that are no longer used. · 1 question
• • Program dynamic analysis tools
  These are tools that support analysis using dynamic tests (i.e., tests that execute the program), such as assertion checking, which embed a logical expression that describes the conditions or the relationships among variables at a specific point in time and verify the validity of the program.

(i) Evaluation of software code and test results

Software code and test results are to be evaluated, with consideration given to the criteria of traceability to the requirements and design of the software configuration item, external consistency with the requirements and design of the software configuration item, internal consistency between requirements for software units, test coverage of software units, appropriateness of coding methods and standards used, feasibility of software integration and testing, and feasibility of operation and maintenance.

[Types of code review]

• • Peer code review
  This is a review performed by members of the development team, colleagues, and other people primarily for the purpose of eliminating defects in deliverables (i.e., code).
• • Code inspection
  This is a formal review performed by determining a moderator (i.e., the person responsible for implementation), primarily for the purpose of improving the quality of deliverables (i.e., code).

• • Bug curve (reliability growth curve)
  This is a graph that plots test results with the cumulative number of bugs or errors on the vertical axis and the elapsed time on the horizontal axis. It is used to quantitatively predict reliability. It can also be used for test progress management by additionally entering the number of finished test items (or the number of unfinished test items), the number of unresolved bugs, and others. When the bug curve has an inflection point and eventually converges to a logistic curve, the program can be assessed as having high reliability (i.e., high quality). · 2 questions

Enlarge original visual

Source visual description

The horizontal Time axis points right. The vertical Cumulative number of bugs axis points upward. An S-shaped curve rises from the origin and levels off beneath a dotted upper horizontal line; a dot on the rising middle part is labelled Inflection point.

For using in progress management, the progress status and quality of the program are to be comprehensively assessed, including not only the cumulative number of bugs but also the number of finished test items, number of unresolved bugs, and others. As an example, even if the cumulative number of bugs exceeds expectations, the progress of testing can be considered fast if the number of finished test items also exceeds expectations. However, if the number of finished test items is below expectations, then the quality of the program should be assessed as low.

• • Bug control chart
  This is used to understand test status, product quality, and others on the basis of bug curves. The actual bug curve is recorded onto a graph that already depicts the lower control limit line and the upper control limit line, which are predicted from past performance and such other factor, and is compared with these lines.