ISTQB Chapter 3

1. Which is not a type of review?

Walkthrough

Inspection

Informal review

Management approval

Management approval is not a type of review because it is not a process of evaluating or assessing something. Management approval refers to the authorization or endorsement given by the management for a particular decision, action, or project. It is not a systematic process of examining, analyzing, and providing feedback or recommendations on a product, document, or process, which is the purpose of reviews such as walkthroughs, inspections, and informal reviews.

Explanation

Management approval is not a type of review because it is not a process of evaluating or assessing something. Management approval refers to the authorization or endorsement given by the management for a particular decision, action, or project. It is not a systematic process of examining, analyzing, and providing feedback or recommendations on a product, document, or process, which is the purpose of reviews such as walkthroughs, inspections, and informal reviews.

2. Which of the following artifacts can be examined by using review techniques?

Software code

Requirements specification

Test designs

All of the above

Review techniques can be used to examine all of the artifacts mentioned, including software code, requirements specification, and test designs. Review techniques such as code review, document review, and peer review can help identify errors, improve quality, and ensure compliance with standards and specifications in all of these artifacts. By using review techniques, stakeholders can collaborate, provide feedback, and make improvements to these artifacts before they are finalized or implemented.

Explanation

Review techniques can be used to examine all of the artifacts mentioned, including software code, requirements specification, and test designs. Review techniques such as code review, document review, and peer review can help identify errors, improve quality, and ensure compliance with standards and specifications in all of these artifacts. By using review techniques, stakeholders can collaborate, provide feedback, and make improvements to these artifacts before they are finalized or implemented.

3. What is the main difference between a walkthrough and an inspection?

An inspection is led by the authors, whilst a walkthrough is led by a trained moderator.

An inspection has a trained leader, whilst a walkthrough has no leader.

Authors are not present during inspections, whilst they are during walkthroughs.

A walkthrough is led by the author, whilst an inspection is led by a trained moderator.

In a walkthrough, the author of the work being reviewed takes the lead and guides the participants through the process. On the other hand, an inspection is led by a trained moderator who is responsible for facilitating the review and ensuring that it is conducted effectively. Therefore, the main difference between a walkthrough and an inspection lies in who leads the review process.

Explanation

In a walkthrough, the author of the work being reviewed takes the lead and guides the participants through the process. On the other hand, an inspection is led by a trained moderator who is responsible for facilitating the review and ensuring that it is conducted effectively. Therefore, the main difference between a walkthrough and an inspection lies in who leads the review process.

4. What statement about static analysis is true?

With static analysis, defects can be found that are difficult to find with dynamic testing.

Compiling is not a form of static analysis.

When properly performed, static analysis makes functional testing redundant.

Static analysis finds all faults.

Static analysis is a technique used to analyze code without actually executing it. It can detect defects and vulnerabilities in the code that might be difficult to find through dynamic testing, which involves running the code. Static analysis can identify issues such as coding errors, security vulnerabilities, and performance bottlenecks. However, it is important to note that static analysis does not find all faults, as it has limitations and cannot detect runtime errors or issues that only occur during execution.

Explanation

Static analysis is a technique used to analyze code without actually executing it. It can detect defects and vulnerabilities in the code that might be difficult to find through dynamic testing, which involves running the code. Static analysis can identify issues such as coding errors, security vulnerabilities, and performance bottlenecks. However, it is important to note that static analysis does not find all faults, as it has limitations and cannot detect runtime errors or issues that only occur during execution.

5. Which statement about the function of a static analysis tool is true?

Gives quality information about the code without executing it.

Checks expected results against actual results.

Can detect memory leaks.

Gives information about what code has and has not been exercised.

A static analysis tool is designed to analyze code without actually executing it. It examines the code structure, syntax, and other characteristics to identify potential issues and provide information about the quality of the code. By analyzing the code statically, it can detect errors, vulnerabilities, and other code quality issues without the need for running the code. This allows developers to identify and fix problems early in the development process, improving the overall quality and reliability of the code.

Explanation

A static analysis tool is designed to analyze code without actually executing it. It examines the code structure, syntax, and other characteristics to identify potential issues and provide information about the quality of the code. By analyzing the code statically, it can detect errors, vulnerabilities, and other code quality issues without the need for running the code. This allows developers to identify and fix problems early in the development process, improving the overall quality and reliability of the code.

6. Which of the following statements about early test design are true and which are false? 1. Defects found during early test design are more expensive to fix. 2. Early test design can find defects. 3. Early test design can cause changes to the requirements. 4. Early test design takes more effort.

1 and 3 are true. 2 and 4 are false.

2 is true. 1, 3 and 4 are false.

2 and 3 are true. 1 and 4 are false.

2, 3 and 4 are true. 1 is false.

Defects found during early test design are more expensive to fix. (False): The earlier defects are identified in the development process, the less expensive they are to fix. This principle is the foundation of the cost-effectiveness of early testing.

Early test design can find defects. (True): Early test design involves creating test cases and scenarios before the actual development work begins. This proactive approach helps in identifying potential defects and issues at an early stage.

Early test design can cause changes to the requirements. (True): During the early stages of testing, when defects are discovered, it may lead to changes in the requirements to rectify and improve the system.

Early test design takes more effort. (False): Early test design is an efficient and proactive approach that involves creating test cases and scenarios early in the development process, which can save effort and resources in the long run by preventing and identifying defects early on.

Explanation

Defects found during early test design are more expensive to fix. (False): The earlier defects are identified in the development process, the less expensive they are to fix. This principle is the foundation of the cost-effectiveness of early testing.

Early test design can find defects. (True): Early test design involves creating test cases and scenarios before the actual development work begins. This proactive approach helps in identifying potential defects and issues at an early stage.

Early test design can cause changes to the requirements. (True): During the early stages of testing, when defects are discovered, it may lead to changes in the requirements to rectify and improve the system.

Early test design takes more effort. (False): Early test design is an efficient and proactive approach that involves creating test cases and scenarios early in the development process, which can save effort and resources in the long run by preventing and identifying defects early on.

7. What statement about reviews is true?

Inspections are led by a trained moderator, whereas technical reviews are not necessarily.

Technical reviews are led by a trained leader, inspections are not.

In a walkthrough, the author does not attend.

Participants for a walkthrough always need to be thoroughly trained.

The correct answer states that inspections are led by a trained moderator, whereas technical reviews are not necessarily. This means that during inspections, there is a designated moderator who is trained to lead the review process. On the other hand, technical reviews may or may not have a trained leader guiding the process. This highlights the difference in the level of expertise required for conducting inspections compared to technical reviews.

Explanation

The correct answer states that inspections are led by a trained moderator, whereas technical reviews are not necessarily. This means that during inspections, there is a designated moderator who is trained to lead the review process. On the other hand, technical reviews may or may not have a trained leader guiding the process. This highlights the difference in the level of expertise required for conducting inspections compared to technical reviews.

8. Which of the following characteristics and types of review processes belong together? 1. Led by the author 2. Undocumented 3. No management participation 4. Led by a trained moderator or leader 5. Uses entry and exit criteria s. Inspection t. Technical review u. Informal review v. Walkthrough

S = 4, t = 3, u = 2 and 5, v = 1

S = 4 and 5, t = 3, u = 2, v = 1

S = 1 and 5, t = 3, u = 2, v = 4

S = 5, t = 4, u = 3, v = 1 and 2

The correct answer is s = 4 and 5, t = 3, u = 2, v = 1. This is because characteristics 4 (led by a trained moderator or leader) and 5 (uses entry and exit criteria) are specific to the Inspection review process. Characteristic 3 (no management participation) belongs to the Technical review process. Characteristic 2 (undocumented) belongs to the Informal review process. Characteristic 1 (led by the author) belongs to the Walkthrough review process.

Explanation

The correct answer is s = 4 and 5, t = 3, u = 2, v = 1. This is because characteristics 4 (led by a trained moderator or leader) and 5 (uses entry and exit criteria) are specific to the Inspection review process. Characteristic 3 (no management participation) belongs to the Technical review process. Characteristic 2 (undocumented) belongs to the Informal review process. Characteristic 1 (led by the author) belongs to the Walkthrough review process.

9. Static code analysis typically identifies all but one of the following problems. Which is it?

Unreachable code

Undeclared variables

Faults in the requirements

Too few comments

Static code analysis is a technique used to identify potential issues in source code without actually executing the program. It can help detect problems such as unreachable code, undeclared variables, and lack of comments. However, static code analysis is not designed to identify faults in the requirements. This refers to issues or errors in the specifications or understanding of what the software is supposed to do. These faults are typically identified through requirements analysis and validation techniques, not static code analysis.

Explanation

Static code analysis is a technique used to identify potential issues in source code without actually executing the program. It can help detect problems such as unreachable code, undeclared variables, and lack of comments. However, static code analysis is not designed to identify faults in the requirements. This refers to issues or errors in the specifications or understanding of what the software is supposed to do. These faults are typically identified through requirements analysis and validation techniques, not static code analysis.