Chapter 10 - Testability

Question 1

what is testability

Answer 1

refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing

Question 2

what does it mean for a system to properly testable

Answer 2

it must be possible to control each of the components inputs and then to observe its outputs

Question 3

general scenario: 5 values for source

Answer 3

with manual or automatic testing tools:

• unit testers
• integration testers
• system testers
• acceptance testers
• end users

Question 4

general scenario: 4 values of stimulus

Answer 4

• a set of tests executed due to the completion of a coding increment
• completed integration of subsystem
• finished implementation
• deliver system to customer

Question 5

general scenario: 6 values for environment

Answer 5

• design time
• development time
• compile time
• integration time
• deployment time
• run time

Question 6

general scenario: 1 value for artifact

Answer 6

the portion of the system being tested

Question 7

general scenario: 3 values for response

Answer 7

• execution of test suite and capture results
• capture activity that resulted in the fault
• control and monitor the state of the system

Question 8

general scenario: 4 values for response measure

Answer 8

effort to find fault or class of faults

-effort to achieve a given percentage of state space coverage

probability of fault being revealed by the next test

-time to perform tests

Question 9

general scenario: 4 more values response measure

Answer 9

• effort to detect faults
• length of longest dependency chain
• length of time to prepare test environment
• reduction in risk exposure

Question 10

the main goal of testability tactics

Answer 10

to allow for easier testing when an increment of software development has completed

Question 11

2 categories of testability tactics

Answer 11

• control and observer system state

- limit complexity

Question 12

6 ways to control and observe the system state

Answer 12

• specialized interfaces
• record/playback
• localize state storage

abstract data sources

-sandbox

executable assertions

Question 13

meaning of “specialized interfaces”

Answer 13

to control or capture variable values for a component either through a test harness or through normal execution

Question 14

meaning of “record/playback”

Answer 14

capturing information crossing an interface and using it as input for further testing

Question 15

meaning of “local state storage”

Answer 15

to start a system, subsystem, or module in an arbitrary state for a test

Question 16

meaning of “abstract data sources”

Answer 16

abstracting interfaces lets you substitute data more easily

Question 17

meaning of “sandbox”

Answer 17

isolate the system from the real world to enable experimentation that is unconstrained by the worry about having to undo the consequences of the experiment

Question 18

meaning of “executable assertions”

Answer 18

assertions are hand coded and placed at desired locations to indicate when and where a program is in a faulty state

Question 19

2 methods to limit complexity

Answer 19

limit structural complexity

limit non-determinism

Question 20

meaning of “limit structural complexity (3 things)

Answer 20

• avoiding or resolving cyclic dependencies between components
• isolating and encapsulating dependencies on the external environment
• reducing dependencies between components in general

Question 21

meaning of “limit non-determinism”

Answer 21

finding all sources of non-determinism, such as unconstrained parallelism, and weeding them out

Question 22

3 factors for binding time

Answer 22

• ensure the components that are bound later than compile time can be tested in late-bound context
• ensure late bindings can be captured (logged)
• ensure full range of binding possibilities can be tested