Module 3 - Performance Testing Sample Question - Part 3B
Q31: what task is carried out during Analysis and Design in Sequential Development Models
Select One Option
A: Verify that performance requirements are defined and represent stakeholder needs correctly.
B: Verify that the system design reflects the performance requirements
C: Verify that system performance goals are defined as acceptance criteria for the project.
D: Verify that the code is efficient and reflects the requirements and design in terms of performance.
A: Verify that performance requirements are defined and represent stakeholder needs correctly.
1: Concept – Verify that system performance goals are defined as acceptance criteria for the project.
2:Requirements – Verify that performance requirements are defined and represent stakeholder needs correctly.
3:Analysis and Design – Verify that the system design reflects the performance requirements.
4:Coding/Implementation – Verify that the code is efficient and reflects the requirements and design in terms of performance.
5: Component Testing – Conduct component level performance testing.
6: Component Integration Testing – Conduct performance testing at the component integration level.
Q32: what task is carried out during Coding/Implementation in Sequential Development Models
Select One Option
A: Verify that performance requirements are defined and represent stakeholder needs correctly.
B: Conduct component level performance testing.
C: Conduct performance testing at the component integration level.
D: Verify that the code is efficient and reflects the requirements and design in terms of performance.
D: Verify that the code is efficient and reflects the requirements and design in terms of performance.
1: Concept – Verify that system performance goals are defined as acceptance criteria for the project.
2:Requirements – Verify that performance requirements are defined and represent stakeholder needs correctly.
3:Analysis and Design – Verify that the system design reflects the performance requirements.
4:Coding/Implementation – Verify that the code is efficient and reflects the requirements and design in terms of performance.
5: Component Testing – Conduct component level performance testing.
6: Component Integration Testing – Conduct performance testing at the component integration level.
Q33: what task is carried out during Component Integration Testing in Sequential Development Models
Select One Option
A: Verify that performance requirements are defined and represent stakeholder needs correctly.
B: Conduct component level performance testing.
C: Conduct performance testing at the component integration level.
D: Verify that the code is efficient and reflects the requirements and design in terms of performance.
C: Conduct performance testing at the component integration level.
1: Concept – Verify that system performance goals are defined as acceptance criteria for the project.
2:Requirements – Verify that performance requirements are defined and represent stakeholder needs correctly.
3:Analysis and Design – Verify that the system design reflects the performance requirements.
4:Coding/Implementation – Verify that the code is efficient and reflects the requirements and design in terms of performance.
5: Component Testing – Conduct component level performance testing.
6: Component Integration Testing – Conduct performance testing at the component integration level.
Q34: Performance testing can occur as part of the first iteration, or as an iteration dedicated entirely to performance testing
Select One Option
A: True
B: False
A: True
Iterative and Incremental Development Models
In these development models, such as Agile, performance testing is also seen as an iterative and incremental activity (see [ISTQB_FL_AT]).Performance testing can occur as part of the first iteration, or as an iteration dedicated entirely to performance testing.
Q35: However, with these lifecycle models, the execution of performance testing may be performed by a separate team tasked with performance testing.
Select One Option
A: True
B: False
A: True
Q36: However, with these lifecycle models, the execution of performance testing may be performed by a separate team tasked with performance testing.
Select One Option
A: True
B: False
A: True
However, with these lifecycle models, the execution of performance testing may be performed by a separate team tasked with performance testing.
Q37: What is Continuous Integration (CI)
A: It is used in System Testing
B: It is part of the use case in development testing
C: It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
D: It is used in Sequential development model
C: It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
In these development models, such as Agile, performance testing is also seen as an iterative and incremental activity (see [ISTQB_FL_AT]).Performance testing can occur as part of the first iteration, or as an iteration dedicated entirely to performance testing.
However, with these lifecycle models, the execution of performance testing may be performed by a separate team tasked with performance testing.
Q38: Continuous Integration (CI) ?
A: It is used in System Testing
B: It is part of the use case in development testing
C: It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
D: It is used in Sequential development model
C: It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
Q39: Where is Continuous Integration (CI) performed?
A: It is performed in System Testing.
B: It is performed in Sequential development model
C: It is performed in continuous development.
D:It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
C: It is commonly performed in iterative and incremental software development lifecycles, which facilitates a highly automated execution of tests.
Q40: What is the Objective of regression
A: Regression Testing
B: Unit Testing
C: Component Testing
D:System integration Testing
A: Regression Testing
The most common objective of testing in CI is to perform regression testing and ensure each build is stable. Performance testing can be part of the automated tests performed in CI if the tests are designed in such a way as to be executed at a build level.
Q41: What are additional concerns of Continuous Integration (CI)?
Select all Options
i: The setup of the performance test environment
ii: Set up and deploy System testing
iii Determining which performance tests to automate in CI –
iv: Creating the performance tests for CI
v: Executing performance tests on portions of an application or system
A: I, iii, iv, v
B: i, ii, iii, v
C: ii, iii, iv, v
D: i, ii, iv v
A: I, iii, iv, v
1: The setup of the performance test environment – This often requires a test environment that is available on demand, such as a cloud-based performance test environment.
2: Determining which performance tests to automate in CI – Due to the short timeframe available for CI tests, CI performance tests may be a subset of more extensive performance tests that are conducted by a specialist team at other times during an iteration.
3: Creating the performance tests for CI – The main objective of performance tests as part of CI is to ensure a change does not negatively impact performance. Depending on the changes made for any given build, new performance tests may be required.
4: Executing performance tests on portions of an application or system – This often requires the tools and test environments to be capable of rapid performance testing including the ability to select subsets of applicable tests.
Q42: What is the lifecycle the iterative and incremental software development lifecycles
i: User Story Creation
ii: Coding/Implementation
iii Release Planning
iv: Delivery
v: Design of performance tests
vi: Testing/Evaluation
vii: Iteration Planning
Select all Options
A: I, vii, i, v, ii, vii, iv
B: i, ii, iii, iv ,v, vi, vii
C: i, vii, iii, iv ,v, vi, ii
D: i, vii, iii, iv , ii, vi, v
A: I, vii, i, v, ii, vii, iv
Performance testing in the iterative and incremental software development lifecycles can also have its own lifecycle activities:
1: Release Planning – In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
2: Iteration Planning – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
3: User Story Creation – User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
4: Design of performance tests –performance requirements and criteria which are described in particular user stories are used for the design of tests (see section 4.2)
5: Coding/Implementation – During coding, performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
6: Testing/Evaluation – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
7: Delivery – Since delivery will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
Q43: What are the activities carried out during Release Planning?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
C: User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
D: Performance requirements and criteria which are described in particular user stories are used for the design of tests
A: Release Planning – In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
2: Iteration Planning – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
3: User Story Creation – User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
4: Design of performance tests –performance requirements and criteria which are described in particular user stories are used for the design of tests (see section 4.2)
5: Coding/Implementation – During coding, performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
6: Testing/Evaluation – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
7: Delivery – Since delivery will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
Q44: What are the activities carried out during Design of Performance tests?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
C: User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
D: Performance requirements and criteria which are described in particular user stories are used for the design of tests
D: Performance requirements and criteria which are described in particular user stories are used for the design of tests
1: Release Planning – In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
2: Iteration Planning – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
3: User Story Creation – User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
4: Design of performance tests –performance requirements and criteria which are described in particular user stories are used for the design of tests (see section
5: Coding/Implementation – During coding, performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
6: Testing/Evaluation – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
7: Delivery – Since delivery will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
Q45: What are the activities carried out during User Story Creation?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
C: This often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
D: Performance requirements and criteria which are described in particular user stories are used for the design of tests
C: This often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
User Story Creation – User stories often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.3
Q46: What are the activities carried out during User Iteration Planning?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
C: This often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
D: Performance requirements and criteria which are described in particular user stories are used for the design of tests
C: This often form the basis of performance requirements in Agile methodologies, with the specific performance criteria described in the associated acceptance criteria. These are referred to as “non-functional” user stories.
Iteration Planning – In the context of each iteration, performance testing may be performed within the iteration and as each iteration is completed. Performance risks are assessed in more detail for each user story.
Q47: What are the activities carried out during User Coding/Implementation?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
C: Since delivery will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
D: Performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
D: Performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
5: Coding/Implementation – During coding, performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
Q48: What are the activities carried out during Delivery?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
C: Since this will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
D: Performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
C: Since this will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
7: Delivery – Since delivery will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
Q49: What are the activities carried out during Testing/Evaluation?
A: In this activity, performance testing is considered from the perspective of all iterations in a release, from the first iteration to the final iteration. Performance risks are identified and assessed, and mitigation measures planned. This often includes planning of any final performance testing before the release of the application.
B: While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
C: Since this will introduce the application to the production environment, performance will need to be monitored to determine if the application achieves the desired levels of performance in actual usage.
D: Performance testing may be performed at a component level. An example of this would be the tuning of algorithms for optimum performance efficiency.
B: While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
6: Testing/Evaluation – While testing is typically performed in close proximity to development activities, performance testing may be performed as a separate activity, depending on the scope and objectives of performance testing during the iteration. For example, if the goal of performance testing is to test the performance of the iteration as a completed set of user stories, a wider scope of performance testing will be needed than that seen in performance testing a single user story. This may be scheduled in a dedicated iteration for performance testing.
Q50: What is Commercial Off-the-Shelf (COTS)?
A: Many organizations do not develop applications and systems themselves, but instead are in the position of acquiring software from vendor sources or from open-source projects.
B: It is used by company to develop new system.
C: It is software used in component Testing.
D: It is used in System Integration.
A: Many organizations do not develop applications and systems themselves, but instead are in the position of acquiring software from vendor sources or from open-source projects.
Commercial Off-the-Shelf (COTS) and other Supplier/Acquirer Models
Many organizations do not develop applications and systems themselves, but instead are in the position of acquiring software from vendor sources or from open-source projects.
ln such supplier/acquirer models, performance is an important consideration that requires testing from both the supplier (vendor/developer) and acquirer (customer) perspectives.
Q51: What is important when considering to buy COT Software?
A: Sales.
B: Training
C: Stakeholders
D: Performance
D: Performance.
Commercial Off-the-Shelf (COTS) and other Supplier/Acquirer Models
Many organizations do not develop applications and systems themselves, but instead are in the position of acquiring software from vendor sources or from open-source projects. ln such supplier/acquirer models, performance is an important consideration that requires testing from both the supplier (vendor/developer) and acquirer (customer) perspectives.
Q52: Whose responsibility is it to validate COTS software?
A: Customers
B: Sales People
C: Stakeholders
D: Testers.
A: Customers
Regardless of the source of the application, it is often the responsibility of the customer to validate that the performance meets their requirements. In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the customer has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
Q53: In the case of customized vendor-developed software, what should be done?
A: In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the customer has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
B: In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the Stakeholders has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
C: In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the Tester has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
D: In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the Developer has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
A: In the case of customized vendor-developed software, performance requirements and associated acceptance criteria which should be specified as part of the contract between the vendor and customer. In the case of COTS applications, the customer has sole responsibility to test the performance of the product in a realistic test environment prior to deployment.
Regardless of the source of the application, it is often the responsibility of the customer to validate that the performance meets their requirements.
Subscribe To Us
Don’t miss our future updates! Get Subscribed Today!
MEEGSKILLS Copyright @2023