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:
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:
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:
.
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:
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.
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:
.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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.
Don’t miss our future updates! Get Subscribed Today!
MEEGSKILLS Copyright @2023