Module 2 - Software Testing Sample Questions - 2A
Q1:

A software development lifecycle (SDLC) model is an abstract, high-level representation of the software development process

A: True

B: False

A: True

A software development lifecycle (SDLC) model is an abstract, high-level representation of the software development process. A SDLC model defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically. Examples of SDLC models include: sequential development models (e.g., waterfall model, V-model), iterative development models (e.g., spiral model, prototyping), and incremental development models (e.g., Unified Process).

 

Q2: A SDLC model defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically

A: True

B: False

A: True

A software development lifecycle (SDLC) model is an abstract, high-level representation of the software development process. A SDLC model defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically. Examples of SDLC models include: sequential development models (e.g., waterfall model, V-model), iterative development models (e.g., spiral model, prototyping), and incremental development models (e.g., Unified Process).

 

Q3: Examples of SDLC models include: sequential development models (e.g., waterfall model, V-model), iterative development models (e.g., spiral model, prototyping), and incremental development models (e.g., Unified Process).

A: True

B: False

A:True

A software development lifecycle (SDLC) model is an abstract, high-level representation of the software development process. A SDLC model defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically. Examples of SDLC models include: sequential development models (e.g., waterfall model, V-model), iterative development models (e.g., spiral model, prototyping), and incremental development models (e.g., Unified Process).

Q4: Some activities within software development processes can also be described by more detailed software development methods and Agile practices?

Select One Option

A: True 

B: False 

A: True

Some activities within software development processes can also be described by more detailed software development methods and Agile practices. Examples include: acceptance test-driven development (ATDD), behavior-driven development (BDD), domain-driven design (DDD), extreme programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum, and test-driven development (TDD)

Q5: Some activities within software development processes can also be described by more detailed software development methods and Agile practices?

A: True

B: False

A:True

Some activities within software development processes can also be described by more detailed software development methods and Agile practices. Examples include: acceptance test-driven development (ATDD), behavior-driven development (BDD), domain-driven design (DDD), extreme programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum, and test-driven development (TDD)

Q6: Select all development methods and Agile practices from below:

i: Acceptance test-driven development (ATDD) Kanban, Lean IT, Scrum, and test-driven development (TDD)

ii:  Behavior-driven development (BDD)

iii: Domain-driven design (DDD)

iv: Extreme programming (XP)

v: Feature-driven development (FDD)

vi: Kanban, Lean IT, Scrum, and test-driven development (TDD)

A: i, ii, iii

B: i, ii, iv

C: All of the Above

D: iii, iv, vi

 

C: All of the Above

Some activities within software development processes can also be described by more detailed software development methods and Agile practices. Examples include: acceptance test-driven development (ATDD), behavior-driven development (BDD), domain-driven design (DDD), extreme programming (XP), feature-driven development (FDD), Kanban, Lean IT, Scrum, and test-driven development (TDD)

Q7: Testing must be adapted to the SDLC to succeed.

A: True

B: False

A:True

2.1.1. Impact of the Software Development Lifecycle on Testing

Testing must be adapted to the SDLC to succeed. The choice of the SDLC impacts on the:

  • Scope and timing of test activities (e.g., test levels and test types)
  • Level of detail of test documentation
  • Choice of test techniques and test approach
  • Extent of test automation
  • Role and responsibilities of a tester
Q8: The choice of the SDLC impacts on the:

i:   Scope and timing of test activities (e.g., test levels and test types)

ii:  Level of detail of test documentation

iii: Choice of test techniques and test approach

iv: Extent of test automation

v: Role and responsibilities of a tester

A: i, ii, iii

B: i, ii, iv

C: i, ii, v

D All of the Above

 

D All of the Above

Testing must be adapted to the SDLC to succeed. The choice of the SDLC impacts on the:

  • Scope and timing of test activities (e.g., test levels and test types)
  • Level of detail of test documentation
  • Choice of test techniques and test approach
  • Extent of test automation
  • Role and responsibilities of a tester

Q9: select all the development models from below

i:   In sequential development model

ii:  iterative and incremental development model

iii: Agile software development

A: i, ii,

B: All of the Above

C: i, iii

D ii, iii

B: All of the Above

 

In sequential development models, in the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC.

 

In some iterative and incremental development models, it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

 

Agile software development assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques (see Section 4.4) that do not require extensive prior test analysis and design.

Q10: Which one of the below defines Sequential Development Model

A In the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC.

B: it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

C: assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques (see Section 4.4) that do not require extensive prior test analysis 

In sequential development models, in the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC.

In some iterative and incremental development models, it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

Agile software development assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques (see Section 4.4) that do not require extensive prior test analysis and design.

Q11: Which one of the below defines iterative and incremental development models,

A ln the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in

B: it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

C: assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques (see Section 4.4) that do not require extensive prior test analysis and design

B: it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

In sequential development models, in the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC.

In some iterative and incremental development models, it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

Agile software development assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques (see Section 4.4) that do not require extensive prior test analysis and design.

Q12: Which one of the below defines Agile software development?

A  ln the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in

B: it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

C: assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques  that do not require extensive prior test analysis and design.

C: Assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques  that do not require extensive prior test analysis and design.

In sequential development models, in the initial phases testers typically participate in requirement reviews, test analysis, and test design. The executable code is usually created in the later phases, so typically dynamic testing cannot be performed early in the SDLC.

In some iterative and incremental development models, it is assumed that each iteration delivers a working prototype or product increment. This implies that in each iteration both static and dynamic testing may be performed at all test levels. Frequent delivery of increments requires fast feedback and extensive regression testing.

Agile software development assumes that change may occur throughout the project. Therefore, lightweight work product documentation and extensive test automation to make regression testing easier are favored in agile projects. Also, most of the manual testing tends to be done using experience-based test techniques  that do not require extensive prior test analysis and design.

Q13: Select all the Software Development Lifecycle and Good Testing Practices

i:   For every software development activity, there is a corresponding test activity, so that all development activities are subject to quality control.

ii:  Different test levels have specific and different test objectives, which allows for testing to be appropriately comprehensive while avoiding redundancy.

iii: Test analysis and design for a given test level begins during the corresponding development phase of the SDLC, so that testing can adhere to the principle of early testing

iv: Testers are involved in reviewing work products as soon as drafts of this documentation are available, so that this earlier testing and defect detection can support the shift-left strategy

A: All of the Above

B: iii, iv

C: i, iii

D ii, iii

A: All of the Above

2.1.2. Software Development Lifecycle and Good Testing Practices

Good testing practices, independent of the chosen SDLC model, include the following:

  • For every software development activity, there is a corresponding test activity, so that all development activities are subject to quality control.
  • Different test levels have specific and different test objectives, which allows for testing to be appropriately comprehensive while avoiding redundancy.
  • Test analysis and design for a given test level begins during the corresponding development phase of the SDLC, so that testing can adhere to the principle of early testing.
  • Testers are involved in reviewing work products as soon as drafts of this documentation are available, so that this earlier testing and defect detection can support the shift-left strategy

Q14: TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development.

A: True

B: False

A: True

Objectives of testing can vary, depending upon the context, which includes the work product being tested, the test level, risks, the software development lifecycle (SDLC) being followed, and factors related to the business context, e.g., corporate structure, competitive considerations, or time to market.

Q15: Each of these approaches implements the principle of early testing  and follows a shift-left approach, since the tests are defined before the code is written.

 

A: True

B: False

A:True

TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development.

Each of these approaches implements the principle of early testing (see section 1.3) and follows a shift-left approach , since the tests are defined before the code is written. They support an iterative development model.

Q16: They support an iterative development model

A: True

B: False

A:True

TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development.

Each of these approaches implements the principle of early testing (see section 1.3) and follows a shift-left approach , since the tests are defined before the code is written. They support an iterative development model.

Q17: Select Test-Driven Development (TDD) approaches from below:

i:   Derives tests from acceptance criteria as part of the system design process

ii:  Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

iii: Tests are written before the part of the application is developed to satisfy the tests

iv: Directs the coding through test cases (instead of extensive software design)

v: Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format.

vi: Test cases are then automatically translated into executable tests

A: i, ii

B: ii, iv

C: i, iii

D ii, iii

B: ii, iv

TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development. Each of these approaches implements the principle of early testing (see section 1.3) and follows a shift-left approach (see section 2.1.5), since the tests are defined before the code is written. They support an iterative development model. These approaches are characterized as follows:

Test-Driven Development (TDD):

  • Directs the coding through test cases (instead of extensive software design) (Beck 2003)
  • Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

 

Acceptance Test-Driven Development (ATDD) (see section 4.5.3):

  • Derives tests from acceptance criteria as part of the system design process (Gärtner 2011)
    • Tests are written before the part of the application is developed to satisfy the tests

 

Behavior-Driven Development (BDD):

  • Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format. (Chelimsky 2010)
  • Test cases are then automatically translated into executable tests

 

For all the above approaches, tests may persist as automated tests to ensure the code quality in future adaptions / refactoring.

 

Q18: Select Acceptance Test-Driven Development (ATDD) approaches from below:

i:   Derives tests from acceptance criteria as part of the system design process

ii:  Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

iii: Tests are written before the part of the application is developed to satisfy the tests

iv: Directs the coding through test cases (instead of extensive software design)

v: Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format.

vi: Test cases are then automatically translated into executable tests

A: iii, vi

B: v,vi

C: i, iii

D ii, iii

C: i, iii

2.1.3. Testing as a Driver for Software Development

TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development. Each of these approaches implements the principle of early testing (see section 1.3) and follows a shift-left approach (see section 2.1.5), since the tests are defined before the code is written. They support an iterative development model. These approaches are characterized as follows:

Test-Driven Development (TDD):

  • Directs the coding through test cases (instead of extensive software design) (Beck 2003)
  • Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

 

Acceptance Test-Driven Development (ATDD) (see section 4.5.3):

  • Derives tests from acceptance criteria as part of the system design process (Gärtner 2011)
    • Tests are written before the part of the application is developed to satisfy the tests

 

Behavior-Driven Development (BDD):

  • Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format. (Chelimsky 2010)
  • Test cases are then automatically translated into executable tests

For all the above approaches, tests may persist as automated tests to ensure the code quality in future adaptions / refactoring.

Q19: Select Behavior-Driven Development (BDD) approaches from below:

i:   Derives tests from acceptance criteria as part of the system design process

ii:  Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

iii: Tests are written before the part of the application is developed to satisfy the tests

iv: Directs the coding through test cases (instead of extensive software design)

v: Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format.

vi: Test cases are then automatically translated into executable tests

B: v, vi

1.3. Testing as a Driver for Software Development

TDD, ATDD and BDD are similar development approaches, where tests are defined as a means of directing development. Each of these approaches implements the principle of early testing (see section 1.3) and follows a shift-left approach (see section 2.1.5), since the tests are defined before the code is written. They support an iterative development model. These approaches are characterized as follows:

Test-Driven Development (TDD):

  • Directs the coding through test cases (instead of extensive software design) (Beck 2003)
  • Tests are written first, then the code is written to satisfy the tests, and then the tests and code are refactored

 

Acceptance Test-Driven Development (ATDD) (see section 4.5.3):

  • Derives tests from acceptance criteria as part of the system design process (Gärtner 2011)
    • Tests are written before the part of the application is developed to satisfy the tests

 

Behavior-Driven Development (BDD):

  • Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format. (Chelimsky 2010)
  • Test cases are then automatically translated into executable tests

 

For all the above approaches, tests may persist as automated tests to ensure the code quality in future adaptions / refactoring.

Q20: DevOps is an organizational approach aiming to create synergy by getting development (including testing) and operations to work together to achieve a set of common goals.

A: True

B: False

A: True

DevOps is an organizational approach aiming to create synergy by getting development (including testing) and operations to work together to achieve a set of common goals. DevOps requires a cultural shift within an organization to bridge the gaps between development (including testing) and operations while treating their functions with equal value. DevOps promotes team autonomy, fast feedback, integrated toolchains, and technical practices like continuous integration (CI) and continuous delivery (CD). This enables the teams to build, test and release high-quality code faster through a DevOps delivery pipeline (Kim 2016).

Q21: DevOps requires a cultural shift within an organization to bridge the gaps between development (including testing) and operations while treating their functions with equal value.

A: True

B: False

A: True

DevOps is an organizational approach aiming to create synergy by getting development (including testing) and operations to work together to achieve a set of common goals. DevOps requires a cultural shift within an organization to bridge the gaps between development (including testing) and operations while treating their functions with equal value. DevOps promotes team autonomy, fast feedback, integrated toolchains, and technical practices like continuous integration (CI) and continuous delivery (CD). This enables the teams to build, test and release high-quality code faster through a DevOps delivery pipeline (Kim 2016).

Q22: DevOps promotes team autonomy, fast feedback, integrated toolchains, and technical practices like continuous integration (CI) and continuous delivery (CD)

A: True

B: False

A: True

DevOps is an organizational approach aiming to create synergy by getting development (including testing) and operations to work together to achieve a set of common goals. DevOps requires a cultural shift within an organization to bridge the gaps between development (including testing) and operations while treating their functions with equal value. DevOps promotes team autonomy, fast feedback, integrated toolchains, and technical practices like continuous integration (CI) and continuous delivery (CD). This enables the teams to build, test and release high-quality code faster through a DevOps delivery pipeline (Kim 2016).

 

Q23: This enables the teams to build, test and release high-quality code faster through a DevOps delivery pipeline.

A: True

B: False

 

A: True

2.1.4. DevOps and Testing

DevOps is an organizational approach aiming to create synergy by getting development (including testing) and operations to work together to achieve a set of common goals. DevOps requires a cultural shift within an organization to bridge the gaps between development (including testing) and operations while treating their functions with equal value. DevOps promotes team autonomy, fast feedback, integrated toolchains, and technical practices like continuous integration (CI) and continuous delivery (CD). This enables the teams to build, test and release high-quality code faster through a DevOps delivery pipeline (Kim 2016).

Q24: From the testing perspective, some of the benefits of DevOps are:

i:   Fast feedback on the code quality, and whether changes adversely affect existing code

ii:  CI promotes a shift-left approach in testing (see section 2.1.5) by encouraging developers to submit high quality code accompanied by component tests and static analysis

iii: Promotes automated processes like CI/CD that facilitate establishing stable test environments

iv: Increases the view on non-functional quality characteristics (e.g., performance, reliability)

v: Automation through a delivery pipeline reduces the need for repetitive manual testing

vi: The risk in regression is minimized due to the scale and range of automated regression tests

A: i, iii

B: All of the Above

C: i, iii

D ii, iii

B: All of the Above

From the testing perspective, some of the benefits of DevOps are:

  • Fast feedback on the code quality, and whether changes adversely affect existing code
  • CI promotes a shift-left approach in testing (see section 2.1.5) by encouraging developers to submit high quality code accompanied by component tests and static analysis
  • Promotes automated processes like CI/CD that facilitate establishing stable test environments
  • Increases the view on non-functional quality characteristics (e.g., performance, reliability)
  • Automation through a delivery pipeline reduces the need for repetitive manual testing
  • The risk in regression is minimized due to the scale and range of automated regression tests

Q25:  DevOps is not without its risks and challenges, which include:

i:  The DevOps delivery pipeline must be defined and established

ii:  CI / CD tools must be introduced and maintained

iii: Test automation requires additional resources and may be difficult to establish and maintain

A: i, ii

B: I, iii

C: All of the Above

D ii, iii

C: All of the Above

DevOps is not without its risks and challenges, which include:

  • The DevOps delivery pipeline must be defined and established
  • CI / CD tools must be introduced and maintained
  • Test automation requires additional resources and may be difficult to establish and maintain

 

Q26: Although DevOps comes with a high level of automated testing, manual testing – especially from the user’s perspective – will still be needed.

A: True

B: False

 

A: True

Although DevOps comes with a high level of automated testing, manual testing – especially from the user’s perspective – will still be needed.

 

Q27: The principle of early testing is sometimes referred to as shift-left because it is an approach where testing is performed earlier in the SDLC. Shift-left normally suggests that testing should be done earlier (e.g., not waiting for code to be implemented or for components to be integrated), but it does not mean that testing later in the SDLC should be neglected.

 A: True

B: False

A: True

Q28: A shift-left approach might result in extra training, effort and/or costs earlier in the process but is expected to save efforts and/or costs later in the process.

A: True

B: False

A: True

A shift-left approach might result in extra training, effort and/or costs earlier in the process but is expected to save efforts and/or costs later in the process.

For the shift-left approach it is important that stakeholders are convinced and bought into this concept.

Q29: For the shift-left approach it is important that stakeholders are convinced and bought into this concept.

A: True

B: False

 

A: True

A shift-left approach might result in extra training, effort and/or costs earlier in the process but is expected to save efforts and/or costs later in the process.

For the shift-left approach it is important that stakeholders are convinced and bought into this concept.

 

Q30: There are some good practices that illustrate how to achieve a “shift-left” in testing, which include:

i: Reviewing the specification from the perspective of testing. These review activities on specifications often find potential defects, such as ambiguities, incompleteness, and inconsistencies

ii:  Writing test cases before the code is written and have the code run in a test harness during code implementation

iii: Using CI and even better CD as it comes with fast feedback and automated component tests to accompany source code when it is submitted to the code repository

iv: Completing static analysis of source code prior to dynamic testing, or as part of an automated process

v:  Performing non-functional testing starting at the component test level, where possible. This is a form of shift-left as these non-functional test types tend to be performed later in the SDLC when a complete system and a representative test environment are available

A: i, ii, iii

B: i, ii, iv

C: i, ii, v

D All of the Above

 

D All of the Above

 

 

 

2.1.5. Shift-Left Approach

 

The principle of early testing (see section 1.3) is sometimes referred to as shift-left because it is an approach where testing is performed earlier in the SDLC. Shift-left normally suggests that testing should be done earlier (e.g., not waiting for code to be implemented or for components to be integrated), but it does not mean that testing later in the SDLC should be neglected.

 

There are some good practices that illustrate how to achieve a “shift-left” in testing, which include:

 

  • Reviewing the specification from the perspective of testing. These review activities on specifications often find potential defects, such as ambiguities, incompleteness, and inconsistencies
  • Writing test cases before the code is written and have the code run in a test harness during code implementation
  • Using CI and even better CD as it comes with fast feedback and automated component tests to accompany source code when it is submitted to the code repository
  • Completing static analysis of source code prior to dynamic testing, or as part of an automated process
  • Performing non-functional testing starting at the component test level, where possible. This is a form of shift-left as these non-functional test types tend to be performed later in the SDLC when a complete system and a representative test environment are available

 

 

A shift-left approach might result in extra training, effort and/or costs earlier in the process but is expected to save efforts and/or costs later in the process.

 

For the shift-left approach it is important that stakeholders are convinced and bought into this concept

 

Subscribe To Us

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

 MEEGSKILLS Copyright @2023