Chapter 2: Testing Throughout the Software Development Lifecycle

Question 1

Impact of the Software Development Lifecycle on Testing

Answer 1

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

Question 2

in the initial phases testers typically participate in requirement
reviews, test analysis, and test design

Answer 2

sequential development models

Question 3

assumes that change may occur throughout the project

Answer 3

Agile software development

Question 4

it is assumed that each iteration delivers a
working prototype or product increment.

Answer 4

iterative and incremental development models

Question 5

Good Testing Practices

Answer 5

• For every software development activity, there is a corresponding test activity
• Different test levels have specific and different test objectives
• 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

Question 6

Directs the coding through test cases
Tests are written first, then the code is written to satisfy the tests

Answer 6

Test-Driven Development (TDD):

Question 7

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

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

Answer 7

Acceptance Test-Driven Development (ATDD)

Question 8

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.

Answer 8

Behavior-Driven Development (BDD):

Question 9

The principle of early testing

Answer 9

Shift-Left Approach

Question 10

Good practices for Shift-Left Approach

Answer 10

• Reviewing the specification from the perspective of testing -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
• 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.

Question 11

also known as “post-project meetings” and project retrospectives)

Answer 11

Retrospectives

Question 12

benefits of Retro for testing

Answer 12

• Increased test effectiveness / efficiency (e.g., by implementing suggestions for process improvement)
• Increased quality of testware (e.g., by jointly reviewing the test processes)
• Team bonding and learning (e.g., as a result of the opportunity to raise issues and propose improvement points)
• Improved quality of the test basis (e.g., as deficiencies in the extent and quality of the requirements could be addressed and solved)
• Better cooperation between development and testing (e.g., as collaboration is reviewed and optimized regularly)

Question 13

Test Levels

Answer 13

Component testing
Component integration testing
System testing
System integration testing
Acceptance testing

Question 14

(also known as unit testing) focuses on testing components in isolation. It often requires specific support, such as test harnesses or unit test frameworks.

Answer 14

Component testing is normally performed by developers in their development environments.

Question 15

(also known as unit integration testing) focuses on testing the
interfaces and interactions between components.

Answer 15

Component integration testing is heavily dependent on the integration strategy approaches like bottom-up, top-down or big-bang.

Question 16

focuses on the overall behavior and capabilities of an entire system or product

Answer 16

System testing may be performed by an independent test team, and is related to specifications for the system.

Question 17

focuses on testing the interfaces of the system under test and other
systems and external services .

Answer 17

System integration testing requires suitable test environments
preferably similar to the operational environment.

Question 18

focuses on validation and on demonstrating readiness for deployment, which means that the system fulfills the user’s business needs

Answer 18

Acceptance testing should be performed by the intended users.

The main forms of acceptance testing are: user acceptance
testing (UAT), operational acceptance testing, contractual and regulatory acceptance testing, alpha testing and beta testing.

Question 19

Test levels are distinguished by the following non-exhaustive list of attributes

Answer 19

• Test object
• Test objectives
• Test basis
• Defects and failures
• Approach and responsibilities

Question 20

evaluates the functions that a component or system should perform

Answer 20

Functional testing
The functions are “what” the test object should do.

The main objective of functional testing is checking the functional
completeness, functional correctness and functional appropriateness.

Question 21

evaluates attributes other than functional characteristics of a component or system.

Answer 21

Non-functional testing is the testing of “how well the system behaves”.

The main objective of nonfunctional testing is checking the non-functional software quality characteristics.

Question 22

classification of the non-functional software quality characteristics:

Answer 22

• Performance efficiency
• Compatibility
• Usability
• Reliability
• Security
• Maintainability
• Portability

Question 23

is specification-based and derives tests from documentation external
to the test object.

Answer 23

Black-box testing
The main objective of black-box testing is checking the system’s behavior against its specifications.

Question 24

is structure-based and derives tests from the system’s
implementation or internal structure (e.g., code, architecture, work flows, and data flows).

Answer 24

White-box testing
The main objective of white-box testing is to cover the underlying structure by the tests to the acceptable level.

Question 25

confirms that an original defect has been successfully fixed.

Answer 25

Confirmation testing

Question 26

Depending on the risk, one can test the fixed version of the software in several ways, including

Answer 26

• executing all test cases that previously have failed due to the defect
• adding new tests to cover any changes that were needed to fix the defect

Question 27

confirms that no adverse consequences have been caused by a change, including a fix that has already been confirmation tested.

Answer 27

Regression testing

Question 28

can involve planned releases/deployments and unplanned releases/deployments (hot fixes

Answer 28

maintenance

Question 29

scope of maintenance testing

Answer 29

• The degree of risk of the change
• The size of the existing system
• The size of the change

Question 30

The triggers for maintenance and maintenance testing can be classified as follows:

Answer 30

• Modifications, such as planned enhancements (i.e., release-based), corrective changes or hot fixes.
• Upgrades or migrations of the operational environment
• Retirement, such as when an application reaches the end of its life.