Chapter 4 - Test Analysis and Design

Question 1

Describe Black-Box test techniques ?

Answer 1

(also known as specification-based techniques) are based on an analysis of the specified behavior of the test object without reference to its internal structure. Therefore, the test cases are independent of how the software is implemented. If the implementation changes, but the required behavior stays the same, then the test cases are still useful.
Commonly used Black-box Test Techniques:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Table Testing
- State Transition Testing

Question 2

Describe White-box test techniques ?

Answer 2

(also known as structure-based techniques) are based on an analysis of the test object’s internal structure and processing. As the test cases are dependent on how the software is designed, they can only be created after the design or implementation of the test object.
code-related white-box techniques:
- Statement testing
- Branch testing

Question 3

Describe Experience-based test techniques ?

Answer 3

They effectively use the knowledge and experience of testers for the design and implementation of test cases. The effectiveness of these techniques depends heavily on the tester’s skills.
- can detect defects that may have been missed using the black-box and white box techniques.

Question 4

Commonly used Black-box Test Techniques ?
(K3)

Answer 4

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing

Question 5

Equivalence Partitioning (EP) (K3)

Answer 5

It divides data into partitions.
If a test case, that tests one value from an equivalence partition, detects a defect, this defect should detected by test cases that test any other value from the same partition. Therefore, one test for each partition is sufficient.

Question 6

Boundary Value Analysis (BVA) (K3)

Answer 6

It’s a technique based on exercising the boundaries of equivalence partitions. Therefore, BVA can only be used for ordered partitions.

Question 7

Decision Table Testing ? (K3)

Answer 7

Decision tables are used for testing the implementation of system requirements that specify how different combinations of conditions result in different outcomes. They are an effective way of recording complex logic, such as business rules.

Question 8

State Transition Testing ? (K3)

Answer 8

A state transition diagram models the behavior of a system by showing its possible states and valid state transitions.
A transition is initiated by an event, which may be additionally qualified by a guard condition.

Question 9

Code-related white-box test techniques?

Answer 9

Because of their popularity and simplicity we will focus on these two :
- Statement testing
- Branch testing

Question 10

Statement Testing and Statement Coverage ?

Answer 10

A white-box test technique;
In statement testing, the coverage items are executable statements. The aim is to design test cases that exercise statements in the code until an acceptable level of coverage is achieved.
Coverage is measured as the number of statements exercised by the test cases divided by the total number of executable statements in code, and is expressed as a percentage.
(Coverage TC/Executable statements)*100%

Question 11

Branch Testing and Branch Coverage?

Answer 11

A white-box test technique.
A branch is a transfer of control between two nodes in the control flow graph, which shows the possible sequences in which source code statements are executed in the test object. Each transfer of control can be either unconditional (straight-line code) or conditional (decision outcome)

Question 12

What is the value of White-box testing ?

Answer 12

The entire software implementation is taken in account during testing, which facilitates defect detection even when the software specification is vague, outdated or incomplete.
Weakness : If the software does not implement one or more requirements, white-box testing may not detect the resulting defects of omission.
Can be used in static testing.

Question 13

Commonly used Experience-based Test Techniques ?

Answer 13

• Error guessing
• Exploratory testing
• Checklist-based testing

Question 14

Collaborative User Story Writing - What is a User Story ?

Answer 14

A user story represents a feature that will be valuable to either a user or purchaser of a system or software.

Question 15

Most common format for a user story is ?

Answer 15

The most common format for a user story is “As a [role], I want [goal to be accomplished], so that I can
[resulting business value for the role]”, followed by the acceptance criteria.

Question 16

User stories have three critical aspects, called together the “3 C’s”:

Answer 16

• Card – the medium describing a user story (e.g., an index card, an entry in an electronic board)
• Conversation – explains how the software will be used (can be documented or verbal)
• Confirmation – the acceptance criteria

Question 17

Acceptance criteria for a User Story ?

Answer 17

Acceptance criteria for a user story are the conditions that an implementation of the user story must meet
to be accepted by stakeholders. From this perspective, acceptance criteria may be viewed as the test conditions that should be exercised by the tests. Acceptance criteria are usually a result of the Conversation.

Question 18

What are Acceptance Criteria used for ?

Answer 18

• Define the scope of the user story
• Reach consensus among the stakeholders
• Describe both positive and negative scenarios
• Serve as a basis for the user story acceptance testing
• Allow accurate planning and estimation

Question 19

Two most common ways to write acceptance criteria for a user story ?

Answer 19

• Scenario-oriented (e.g., Given/When/Then format used in BDD)
• Rule-oriented (e.g., bullet point verification list, or tabulated form of input-output mapping)

Question 20

Acceptance Test-driven Development (ATDD)

Answer 20

ATDD is a test-first approach.
Test cases are created prior to implementing the user
story. The test cases are created by team members with different perspectives, e.g., customers,
developers, and testers. Test cases may be executed manually or automated.