Module 5 - Software Testing Sample Questions - 5B
Q1:This model also provides a way to differentiate and describe the types of tests to all? stakeholders, including developers, testers, and business representatives.

i: Stakeholders,

ii: Developers,

iii: Testers,

iv: Business representatives

V:  Employees and Employers

A: i, ii, iii, iv

B: i, iii, iv, v

C: i, ii, iv,

D: All of the Above

A: i, ii, iii, iv

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated.

 

Q2: In this model, tests can be business facing or technology facing.

A: True

B: False

A: True

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

 

 

 

Q3: Tests can also support:

i: The team (i.e., guide the development)

ii: Critique the product (i.e., measure its behavior against the expectations).

iii: The System Layer

iv: Work products

A: i, ii

B: iii, iv

C: i, iv,

D: All of the Above

A: True

A: True

A: i, ii

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

 

.

Q4: The combination of these two viewpoints determines the four quadrants:

i:   Quadrant Q1

ii:  Quadrant Q2

iii: Quadrant Q3

iv: Quadrant Q4

v:  Quadrant Q5

A: i, ii, iii, iv

B: i, iii, iv, v

C: i, ii, iii, v

D: All of the Above

A: i, ii, iii, iv

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

 The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

Q5: Which of the following describe Quadrant Q1

A: (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.

B: (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.

C: (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

A: (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

.

Q6: Which of the following describe Quadrant Q4

A: (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.

B: (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.

C: (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

Q7: Which of the following describe Quadrant Q2

A: (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.

B: (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.

C: (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

B: (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

 

 

Q8: Which of the following describe Quadrant Q3

A: (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.

B: (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.

C: (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

D: (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

The testing quadrants, defined by Brian Marick (Marick 2003, Crispin 2008), group the test levels with the appropriate test types, activities, test techniques and work products in the Agile software development.

The model supports test management in visualizing these to ensure that all appropriate test types and test levels are included in the SDLC and in understanding that some test types are more relevant to certain test levels than others.

This model also provides a way to differentiate and describe the types of tests to all stakeholders, including developers, testers, and business representatives.

In this model, tests can be business facing or technology facing.

Tests can also support the team (i.e., guide the development) or critique the product (i.e., measure its behavior against the expectations).

The combination of these two viewpoints determines the four quadrants:

  • Quadrant Q1 (technology facing, support the team). This quadrant contains component and component integration tests. These tests should be automated and included in the CI process.
  • Quadrant Q2 (business facing, support the team). This quadrant contains functional tests, examples, user story tests, user experience prototypes, API testing, and simulations. These tests check the acceptance criteria and can be manual or automated.
  • Quadrant Q3 (business facing, critique the product). This quadrant contains exploratory testing, usability testing, user acceptance testing. These tests are user-oriented and often manual.
  • Quadrant Q4 (technology facing, critique the product). This quadrant contains smoke tests and non-functional tests (except usability tests). These tests are often automated

Q9: Organizations face many internal and external factors that make it uncertain whether and when they will achieve their objectives (ISO 31000). Risk management allows the organizations to increase the likelihood of achieving objectives, improve the quality of their products and increase the stakeholders’ confidence and trust.

A: True

B: False

 

A: True

Organizations face many internal and external factors that make it uncertain whether and when they will achieve their objectives (ISO 31000). Risk management allows the organizations to increase the likelihood of achieving objectives, improve the quality of their products and increase the stakeholders’ confidence and trust.

The main risk management activities are:

  • Risk analysis (consisting of risk identification and risk assessment; see section 5.2.3)
  • Risk control (consisting of risk mitigation and risk monitoring; see section 5.2.4)

The test approach, in which test activities are selected, prioritized, and managed based on risk analysis and risk control, is called risk-based testing.

Organizations face many internal and external factors that make it uncertain whether and when they will achieve their objectives (ISO 31000). Risk management allows the organizations to increase the likelihood of achieving objectives, improve the quality of their products and increase the stakeholders’ confidence and trust.

The main risk management activities are:

  • Risk analysis (consisting of risk identification and risk assessment; see section 5.2.3)
  • Risk control (consisting of risk mitigation and risk monitoring; see section 5.2.4)

The test approach, in which test activities are selected, prioritized, and managed based on risk analysis and risk control, is called risk-based testing.

Q10: The main risk management activities are:

 i: Risk Analysis – consisting of risk identification and risk assessment

ii: Test Analysis – consisting of risk identification and risk assessment

iii: Risk control – consisting of risk mitigation and risk monitoring

iv: System Analysis – consisting of risk mitigation and risk monitoring

Answer:

A: i, ii

B: ii, iii

C: i, iii

D: iii, iv

C: i, iii

The main risk management activities are:

  • Risk analysis (consisting of risk identification and risk assessment; see section 5.2.3)
  • Risk control (consisting of risk mitigation and risk monitoring; see section 5.2.4)

The test approach, in which test activities are selected, prioritized, and managed based on risk analysis and risk control, is called risk-based testing.

Q11: The test approach, in which test activities are selected, prioritized, and managed based on risk analysis and risk control, is called risk-based testing.

A: True

B: False

A: True

The main risk management activities are:

  • Risk analysis (consisting of risk identification and risk assessment; see section 5.2.3)
  • Risk control (consisting of risk mitigation and risk monitoring; see section 5.2.4)

The test approach, in which test activities are selected, prioritized, and managed based on risk analysis and risk control, is called risk-based testing.

Q12: What is a Risk:

A: Risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect

B: Risk is a potential software that does not work when deploy to system

C: Risk is a potential event, hazard, threat, or situation whose occurrence causes an no effect

D: Risk is a potential event, no hazard, no threat, or situation whose occurrence causes an no effect

A: Risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect

5.2.1. Risk Definition and Risk Attributes

Risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect. A risk can be characterized by two factors:

  • Risk likelihood – the probability of the risk occurrence (greater than zero and less than one)
  • Risk impact (harm) – the consequences of this occurrence

These two factors express the risk level, which is a measure for the risk. The higher the risk level, the more important is its treatment.

Q13: A risk can be characterized by two factors:

i: Risk in System

ii: Risk Application

iii: C: Risk likelihood – the probability of the risk occurrence (greater than zero and less than one)

iv: Risk impact (harm) – the consequences of this occurrence

Answer:

A: i, ii

B: i, iii

C: iii, iv

D: ii, iii

C: iii, iv

5.2.1. Risk Definition and Risk Attributes

Risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect. A risk can be characterized by two factors:

  • Risk likelihood – the probability of the risk occurrence (greater than zero and less than one)
  • Risk impact (harm) – the consequences of this occurrence

These two factors express the risk level, which is a measure for the risk. The higher the risk level, the more important is its treatment.

.

Q14: These two factors express the risk level, which is a measure for the risk. The higher the risk level, the more important is its treatment.

A: True

B: False

A: True

These two factors express the risk level, which is a measure for the risk. The higher the risk level, the more important is its treatment.

5.2.1. Risk Definition and Risk Attributes

Risk is a potential event, hazard, threat, or situation whose occurrence causes an adverse effect. A risk can be characterized by two factors:

  • Risk likelihood – the probability of the risk occurrence (greater than zero and less than one)
  • Risk impact (harm) – the consequences of this occurrence

These two factors express the risk level, which is a measure for the risk. The higher the risk level, the more important is its treatment.

 

Q15: In software testing one is generally concerned with two types of risks

i: Project risks

ii: Project program

iii: Product risks.

iv: Product management

A: i, iii

B: i, iii

C: iii, iv

D: All of the Above

B: i, iii

5.2.2. Project Risks and Product Risks

In software testing one is generally concerned with two types of risks: project risks and product risks. Project risks are related to the management and control of the project. Project risks include:

  • Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)
  • People issues (e.g., insufficient skills, conflicts, communication problems, shortage of staff)
  • Technical issues (e.g., scope creep, poor tool support)
  • Supplier issues (e.g., third-party delivery failure, bankruptcy of the supporting company)

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

Q16: Project risks are related to the management and control of the project.

A: True

B: False

A: True

5.2.2. Project Risks and Product Risks

In software testing one is generally concerned with two types of risks: project risks and product risks. Project risks are related to the management and control of the project. Project risks include:

  • Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)
  • People issues (e.g., insufficient skills, conflicts, communication problems, shortage of staff)
  • Technical issues (e.g., scope creep, poor tool support)
  • Supplier issues (e.g., third-party delivery failure, bankruptcy of the supporting company)

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

 

Q17: Project risks include:

i: Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)

ii: People issues (e.g., insufficient skills, conflicts, communication problems, shortage of staff)

iii: Technical issues (e.g., scope creep, poor tool support)

iv: Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)

A: i, ii, iii

B: i, iii, iv

C: ii,  iii, iv

D: All of the Above

D: All of the Above

5.2.2. Project Risks and Product Risks

In software testing one is generally concerned with two types of risks: project risks and product risks. Project risks are related to the management and control of the project. Project risks include:

  • Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)
  • People issues (e.g., insufficient skills, conflicts, communication problems, shortage of staff)
  • Technical issues (e.g., scope creep, poor tool support)
  • Supplier issues (e.g., third-party delivery failure, bankruptcy of the supporting company)

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

 

Q18: Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

A: True

B: False

A: True

In software testing one is generally concerned with two types of risks: project risks and product risks. Project risks are related to the management and control of the project. Project risks include:

  • Organizational issues (e.g., delays in work products deliveries, inaccurate estimates, cost-cutting)
  • People issues (e.g., insufficient skills, conflicts, communication problems, shortage of staff)
  • Technical issues (e.g., scope creep, poor tool support)
  • Supplier issues (e.g., third-party delivery failure, bankruptcy of the supporting company)

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

Q19: Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model).

A: True

B: False

A: True

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

Q20: Examples of product risks include:

Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities.

i: Missing or wrong functionality

ii: Incorrect calculations

iii: Runtime errors

iv: Poor architecture

v: Security vulnerabilities.

A: All of the Above

B: i, iii, iv, v

C: ii,  iii, iv, v

D: i, ii, iii, iv

D: All of the Above

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

 

Q21: Product risks, when they occur, may result in various negative consequences, including:

i: User dissatisfaction

ii: In extreme cases, physical damage, injuries or even death

iii: Damage to third parties

iv: Loss of revenue, trust, reputation

 

v: High maintenance costs, overload of the helpdesk

vi: Criminal Penalties

A: ii,  iii, iv, v

B: i, iii, iv, v

C: All of the Above

D: i, ii, iii, iv

C: All of the Above

Project risks, when they occur, may have an impact on the project schedule, budget or scope, which affects the project’s ability to achieve its objectives.

Product risks are related to the product quality characteristics (e.g., described in the ISO 25010 quality model). Examples of product risks include: missing or wrong functionality, incorrect calculations, runtime errors, poor architecture, inefficient algorithms, inadequate response time, poor user experience, security vulnerabilities. Product risks, when they occur, may result in various negative consequences, including:

  • User dissatisfaction
  • Loss of revenue, trust, reputation
  • Damage to third parties
  • High maintenance costs, overload of the helpdesk
  • Criminal penalties
  • In extreme cases, physical damage, injuries or even death

Q22: From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

A: True

B: False

A: True

5.2.3. Product Risk Analysis

From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks. Stakeholders can identify risks by using various techniques and tools, e.g., brainstorming, workshops, interviews, or cause-effect diagrams. Risk assessment involves: categorization of identified risks, determining their risk likelihood, risk impact and level, prioritizing, and proposing ways to handle them. Categorization helps in assigning mitigation actions, because usually risks falling into the same category can be mitigated using a similar approach.

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. In the qualitative approach the risk level can be determined using a risk matrix.

Q23: Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks.

i: Brainstorming

ii: Workshops

iii: lnterviews

iv: cause-effect diagrams.

A: ii,  iii, iv

B: i, iii, iv

C: i, ii, iii

D: All of the Above

D: All of the Above

5.2.3. Product Risk Analysis

From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

 Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks. Stakeholders can identify risks by using various techniques and tools, e.g., brainstorming, workshops, interviews, or cause-effect diagrams. Risk assessment involves: categorization of identified risks, determining their risk likelihood, risk impact and level, prioritizing, and proposing ways to handle them. Categorization helps in assigning mitigation actions, because usually risks falling into the same category can be mitigated using a similar approach.

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. In the qualitative approach the risk level can be determined using a risk matrix.

 

Q24:

Risk assessment involves:

i: Categorization of identified risks

ii: Determining their risk likelihood

iii: Risk impact and level

iv: Prioritizing, and proposing ways to handle them.

A: ii,  iii, iv

B: All of the Above

C: i, ii, iii

D: i, iii, iv

B: All of the Above

5.2.3. Product Risk Analysis

From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

 Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks. Stakeholders can identify risks by using various techniques and tools, e.g., brainstorming, workshops, interviews, or cause-effect diagrams. Risk assessment involves: categorization of identified risks, determining their risk likelihood, risk impact and level, prioritizing, and proposing ways to handle them. Categorization helps in assigning mitigation actions, because usually risks falling into the same category can be mitigated using a similar approach.

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. In the qualitative approach the risk level can be determined using a risk matrix.

 

Q25: Static testing may more easily detect defects that lay on paths through the code that are rarely executed or hard to reach using dynamic testing.

A: True

B: False

A: True

5.2.3. Product Risk Analysis

From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

 Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks. Stakeholders can identify risks by using various techniques and tools, e.g., brainstorming, workshops, interviews, or cause-effect diagrams. Risk assessment involves: categorization of identified risks, determining their risk likelihood, risk impact and level, prioritizing, and proposing ways to handle them. Categorization helps in assigning mitigation actions, because usually risks falling into the same category can be mitigated using a similar approach.

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. In the qualitative approach the risk level can be determined using a risk matrix.

Q26: Static testing can be applied to non-executable work products, while dynamic testing can only be applied to executable work products.

A: True

B: False

 

A: True

5.2.3. Product Risk Analysis

From a testing perspective, the goal of product risk analysis is to provide an awareness of product risk in order to focus the testing effort in a way that minimizes the residual level of product risk. Ideally, product risk analysis begins early in the SDLC.

 Product risk analysis consists of risk identification and risk assessment. Risk identification is about generating a comprehensive list of risks. Stakeholders can identify risks by using various techniques and tools, e.g., brainstorming, workshops, interviews, or cause-effect diagrams. Risk assessment involves: categorization of identified risks, determining their risk likelihood, risk impact and level, prioritizing, and proposing ways to handle them. Categorization helps in assigning mitigation actions, because usually risks falling into the same category can be mitigated using a similar approach.

Risk assessment can use a quantitative or qualitative approach, or a mix of them. In the quantitative approach the risk level is calculated as the multiplication of risk likelihood and risk impact. In the qualitative approach the risk level can be determined using a risk matrix.

Q27: Product risk analysis may influence the thoroughness and scope of testing. Its results are used to:

i: Determine the scope of testing to be carried out

ii: Determine the particular test levels and propose test types to be performed

iii: Determine the test techniques to be employed and the coverage to be achieved

iv: Estimate the test effort required for each task

v: Prioritize testing in an attempt to find the critical defects as early as possible

vi: Determine whether any activities in addition to testing could be employed to reduce risk

A: ii,  iii, iv, v

B: i, ii, iii, iv

C: All of the Above

D: i, iii, iv, v

C: All of the Above

Product risk analysis may influence the thoroughness and scope of testing. Its results are used to:

  • Determine the scope of testing to be carried out
  • Determine the particular test levels and propose test types to be performed
  • Determine the test techniques to be employed and the coverage to be achieved
  • Estimate the test effort required for each task
  • Prioritize testing in an attempt to find the critical defects as early as possible
  • Determine whether any activities in addition to testing could be employed to reduce risk

 

Q28: Product risk control comprises all measures that are taken in response to identified and assessed product risks. Product risk control consists of risk mitigation and risk monitoring.

A: True

B: False

A: True

5.2.4. Product Risk Control

Product risk control comprises all measures that are taken in response to identified and assessed product risks. Product risk control consists of risk mitigation and risk monitoring.

Risk mitigation involves implementing the actions proposed in risk assessment to reduce the risk level.

The aim of risk monitoring is to ensure that the mitigation actions are effective, to obtain further information to improve risk assessment, and to identify emerging risks.

Q29: Risk Mitigation involves implementing the actions proposed in risk assessment to reduce the risk level.

A: True

B: False

A: True

5.2.4. Product Risk Control

Product risk control comprises all measures that are taken in response to identified and assessed product risks. Product risk control consists of risk mitigation and risk monitoring.

Risk mitigation involves implementing the actions proposed in risk assessment to reduce the risk level.

The aim of risk monitoring is to ensure that the mitigation actions are effective, to obtain further information to improve risk assessment, and to identify emerging risks.

Q30: The aim of risk monitoring is to ensure that the mitigation actions are effective, to obtain further information to improve risk assessment, and to identify emerging risks.

A: True

B: False

A: True

5.2.4. Product Risk Control

Product risk control comprises all measures that are taken in response to identified and assessed product risks. Product risk control consists of risk mitigation and risk monitoring.

Risk mitigation involves implementing the actions proposed in risk assessment to reduce the risk level.

The aim of risk monitoring is to ensure that the mitigation actions are effective, to obtain further information to improve risk assessment, and to identify emerging risks.

Subscribe To Us

Don’t miss our future updates! Get Subscribed Today!

 MEEGSKILLS Copyright @2023