Footnotes

Chapter 1

1. Note: For ease of reading, we use the male pronour, throughout this book where general references are made to persons. By no means is there any intention of gender bias or discrimination against women.

2. The new version of the ISTQB Advanced Level syllabus is currently under development and will presumably adopt and advance this module structure.

3. Regarding reviews see, for example, [Gilb 96].

4. Testing cannot prove that requirements are met 100% because it conducts only spot-check-like verifications.

Chapter 2

1. A more detailed introduction to the fundamental test process is given in [Spillner 07, section 2.2 and chapter 7] Readers familiar with its content may skip this chapter.

2. This check can already be done while developing the test strategy and may influence it if the documentation is already available at that time.

3. [URL: Tool-List] provides a list of useful links regarding tool information.

Chapter 3

1. Life cycle model and process model are also commonly used terms.

2. [IEEE 829] calls these documents “test documents.” [ISO 12207.1] defines the term more broadly as “life cycle data” (information item).

3. The “V-model” is tagged “general” to distinguish it from the “Lifecycle Process Model of the Federal Republic of Germany” (version 92 and 97), which in German publications is often also referred to as the “V-model”.

4. Now IBM.

5. The RUP chart is from [Kruchten 04].

6. A term also frequently used is “disciplines”.

7. See [URL: EP].

8. See [URL: EP].

9. Continuous integration (see figure 3-6) is performed, but there are no specific test cases to check on interfaces; instead, unit test cases are repeated.

10. However, there is a series of publications providing suggestions related to systematic test execution (e.g., [Crispin 02]).

Chapter 5

1. According to [URL:ISTQB], test plan is a synonym for test concept.

2. According to [URL:ISTQB], test level plan is a synonym for test step plan.

3. This refers to tests of a test level that were defined as an entry criterion for delivery of the test objects from development or a previous test level, but not customer acceptance tests.

4. For test strategy planning in more complex projects, [IEEE 1012] offers an alternative structure for a “verification and validation plan”.

5. Since an operational prototype has already been developed, later users are already familiar with the user interface Otherwise, an initial usability test at system test level would be very risky because the results of the test may cause considerable system changes.

6. Typically, the definition of and compliance with a standard skill profile is a feature of the SPICE Level 3-compliant test process.

7. Probability of a malfunction of the products weighted by the damage caused by the malfunction.

8. General observation that in many situations it is possible to achieve 80% of one’s objectives with 20% of the total effort.

9. It is assumed that the developers do not perform component testing themselves.

Chapter 6

1. The release plan defines when specific versions are released to the customer. Moreover, there are, in most cases, additional internal versions (builds) that are compiled for test purposes only, or there are so-called release candidates that cannot yet be released because of unsatisfactory test results. All these versions must be taken into account during planning and test control.

2. In the “fundamental test process” (compare figure 2-1) the creation of the test report is an independent process step. Since, essentially, the test report renders findings and results from test control, this is being discussed here in this chapter.

Chapter 7

1. TQM can also be considered a comparable concept.

2. The idea is rather less bureaucratic than the term “employee suggestion system” suggests.

3. In CMMI this is called an appraisal.

4. ISO/IEC 15504 (see section 7.2.2) part 2 defines the maturity level model; part 5 defines the assessment model. CMMI (see section 7.2.1) is an assessment model that can be used in lieu of part 5.

5. 1991 published as a pilot version 1.0, 1993 version 1.1.

6. Besides the CMMI model discussed here, there are other models (see [URL: CMMI-Models]).

7. All three techniques are described in more detail in Software Testing Foundations ([Spillner 07]).

8. See [URL: CMMI V1.2 Model], “Establish the validation environment”, page 486.

9. Extension of CMM specifically for telecommunications software.

10. For small organizations.

11. EU process improvement program; discontinued.

12. ENG.2 and ENG.3 also address test planning and preparation.

13. Since TMM is based on CMM, TMM is compared with CMM rather than CMMI.

14. Formerly IQUIP.

15. However, only Part 2 is normative, i.e., SPICE assessments results can generally not be compared.

16. Assessment results that serve as evidence for a particular maturity level; this may be interview statements, documents, data in tool databases, etc.

17. Describes a rather simplified and informal type of assessment.

Chapter 8

1. Several other terms are widely used for such systems, such as, e.g., “bug tracking system” and “problem database”.

Chapter 10

1. Overviews of tools and explanations of associated concepts can be found at [URL: Imaging] and [URL: Virtualization].

2. The term “tester” is also used as a generic term for all of the roles listed above.

3. A large number of concepts relating to team roles can be found in the literature—e.g., DISGModel [URL: DISG] or Myers-Briggs Type Indicator [URL: MBTI]. Belbin’s model is considered here in more detail as representative of such team role models.

4. None of the team roles should be considered positive or negative, despite the fact that some role descriptions, such as “pessimist,” may have negative connotations in everyday language.

5. The success of software development projects depends to a large extent on social, nontechnical factors. Worthwhile observations on this issue and the management of software development can be found in, e.g., [DeMarco 95] and [DeMarco 97].

6. [Belbin 93] originally considers management teams, i.e., teams made up of executives. His findings, however, can be applied to other forms of sophisticated teamwork.

Chapter 11

1. A relational system comprises the number of (measurement) values and associated allowed operations (see [Zuse 98]).

2. “Localization” is the process of adapting software to another language—for example, by translating user interfaces: adapting date formats, currencies, and measurement units: and even perhaps adapting the software to local legal requirements.

3. For legal reasons, employees must be informed about the collection and intended use of measurements regarding their work or productivity (see also section 6.6).

Glossary

1. Terms flagged with an asterisk are included in the [Spillner 07] glossary; the definitions can also be found on [URL: ISTQB Glossary].