# TEST DESIGN TECHNIQUES

###### tags: `ISTQB` `SQA`
the chapter explores the **three categories of test case design techniques:**
- specification-based
- structure-based
- experience-based.

## THE TEST DEVELOPMENT PROCESS
The specification of test cases is the second step in the fundamental test process (FTP) defined in Chapter 1.

The design of tests comprises **three main steps:**
1. Identify test conditions.
2. Specify test cases.
3. Specify test procedures.

### A test condition
:::info
:star: **Definition**
***An*** item or event of a component or system that could be verified by <span style="color:red;">***one or more</span> test cases***, for example a function, transaction, feature, quality attribute or structural elemen.
:::

- In other words, a test condition is some characteristic of our software that we can check with a test or a set of tests.

### A test case
:::info
:star: **Definition**
***A*** set of *input values, execution preconditions, expected results and execution postconditions*, developed for ***a particular objective or test condition***, such as to exercise a particular program path or to verify compliance with a specific requirement.
:::

- In other words, a test case:
1. gets the system to some starting point for the test (execution preconditions)
2. then applies a set of input values that should achieve a given outcome (expected result)
3. and leaves the system at some end point (execution postcondition).

:::spoiler For example
We have to define what state the system is in when we start so that it is ready to receive the inputs and we have to decide what state it is in after the test so that we can check that it ends up in the right place.
我們必須在啟動時定義系統所處的狀態，以便準備接收輸入，並且必須在測試後確定係統所處的狀態，以便我們可以檢查它是否位於正確的位置。
:::

### A test procedure specification
:::info
:star: **Definition**
***A*** sequence of actions for the execution of ***a*** test.
:::

So, going back to our three step process above, we:
1. decide on a test condition, which would typically be a small section of the specification for our software under test;
2. design a test case that will verify the test condition;
3. write a test procedure to execute the test, that is get it into the right starting state, input the values, and check the outcome.

### Mapping relation example

digraph condiction_case_procedure_execution{
    rankdir="LR"
    
    // 'A' test condiction can be verified by 'one or more' test cases.
    "a specificaion1"
    ->{
        "a test condiction1"
        "a test condiction2"
    }
    
    "a specificaion2"
    ->{
        "a test condiction3"
        "a test condiction4"
    }
    
    "a test condiction1"
    ->{
        "a test case1-1"
        "a test case1-2"
        "a test case1-3"
    }
    
    "a test condiction2"
    ->{
        "a test case2-1"
        "a test case2-2"
    }
    
    "a test condiction3"
    ->{
        "a test case3-1"
        "a test case3-2"
    }
    
    "a test condiction4"
    ->{
        "a test case4-1"
        "a test case4-2"
    }
    
    // 'A' test procedure specification – a sequence of actions for the execution of 'a' test.
    "a test case1-1"
    ->"a test procedure\n specification1-1"
    "a test case1-2"
    ->"a test procedure\n specification1-2"
    "a test case1-3"
    ->"a test procedure\n specification1-3"
    
    "a test case2-1"
    ->"a test procedure\n specification2-1"
    "a test case2-2"
    ->"a test procedure\n specification2-2"
    
    "a test case3-1"
    ->"a test procedure\n specification3-1"
    "a test case3-2"
    ->"a test procedure\n specification3-2"
    
    "a test case4-1"
    ->"a test procedure\n specification4-1"
    "a test case4-2"
    ->"a test procedure\n specification4-2"
    
    // A test execution schedual collects a set of tests or test procedure specifications.
    {
        "a test procedure\n specification1-1",
        "a test procedure\n specification1-3",
        "a test procedure\n specification2-1",
        "a test procedure\n specification2-2",
        "a test procedure\n specification3-1",
        "a test procedure\n specification4-2"
    }->"a test execution schedual"
    
    
}

- according to the project condition
In some situations it may be appropriate to produce very little documentation and in others a very formal and documented process may be appropriate.
在某些情況下，生成很少的文檔可能是適當的，在其他情況下，非常正式且有文檔記錄的過程可能是合適的。
Safety-critical systems, for example, will normally require a more formal test process.

- In preparation for execution the test execution
the test execution schedule collects together all the tests and sequences them, **taking into account any priorities** (highest priority tests would be run first) and any **dependencies between tests**.

### THE IDEA OF TEST COVERAGE
**it provides a quantitative assessment of the extent and quality of testing.**

- important 2 reason
- It provides a quantitative measure of the quality of the testing that has been done by measuring what has been achieved.
- It provides a way of estimating how much more testing needs to be done. Using quantitative measures we can set targets for test coverage and measure progress against them.

If we apply coverage measures to testing based on priorities, which are themselves based on the risks addressed by individual tests, we will have a reliable, objective and quantified framework for testing.

### CATEGORIES OF TEST CASE DESIGN TECHNIQUES
- The test case design techniques three categories
- Black-box specification-based
- based on specification or model of a system or proposed.
- black-box techniques are based on an analysis of the test basis documentation, including both functional and non-functional aspects.
They do **not use** any information regarding the **internal structure of the component or system** under test.
- White-box structure-based
- based on structure of a component or system
- experience-based techniques
- test case from the tester’s experience

### SPECIFICATION-BASED (BLACK-BOX) TECHNIQUES
The main thing about specification-based techniques is that **they derive test cases directly from the specification or from some other kind of model of what the system** should do.
:::spoiler 如果定義的好的益處
If a test basis is well defined and adequately structured we can easily identify test conditions from which test cases can be derived.
:::

The most important point about specification-based techniques is that
- specifications or models do not (and should not) define how a system should achieve the specified behaviour when it is built
- it is a specification of the required (or at least desired) behaviour.

:::danger
If they have misunderstood the specification or chosen to change it in some way without telling anyone then their implementation will deliver behaviour that is different from what the model or specification said the system behaviour should be.
Our test, based solely on the specification, will therefore fail and we will have uncovered a problem.
:::

:::info
:star: **If there is no specification at all**
the tester may have to build a model of the proposed system, perhaps by interviewing key stakeholders to understand what their expectations are.
:::

#### five specification-based techniques for the Foundation Certificate
- Equivalence partitioning.
- Boundary value analysis.
- Decision table testing.
- State transition testing.
- Use case testing.

#### Equivalence partitioning
- Input partitions
- Equivalence partitioning is based on a very simple idea: it is that in many cases the inputs to a program can be ‘chunked’ into groups of similar inputs.
**For example, a program that accepts integer values can accept as valid any input that is an integer(i.e. a whole number) and should reject anything else (such as a real number or a character).**
:::spoiler example
If we imagine a program that separates numbers into two groups according to whether they are positive or negative the total range of integers could be split into three ‘partitions’: the values that are less than zero; zero; and the values that are greater than zero.
:::

:::info
**excercise 4.1**
Suppose you have a bank account that offers variable interest rates: 0.5 per cent for the first £1,000 credit; 1 per cent for the next £1,000; 1.5 per cent for the rest. If you wanted to check that the bank was handling your account correctly what valid input partitions might you use?
:::

:::success
Answer: split three partitions: 0~1000 ,1001~2000 , over 2001
:::

:::info
**excercise 4.2**
A mail-order company selling flower seeds charges £3.95 for postage and packing on all orders up to £20 value and £4.95 for orders above £20 value and up to £40 value. For orders above £40 value there is no charge for postage and packing.
If you were using equivalence partitioning to prepare test cases for the postage and packing charges what valid partitions would you define?
What about non-valid partitions?
The answer can be found at the end of the chapter.
:::

:::success
Answer: split three partitions: 1~20 , 21~40 , over 40
non-valid: 0 , negative
:::

#### Boundary value analysis
**One thing we know about the kinds of mistakes that programmers make is that errors tend to cluster around boundaries.**

>For example, if a program should accept a sequence of numbers between 1 and 10, the most likely fault will be that values just outside this range are incorrectly accepted or that values just inside the range are incorrectly rejected.

:::info
For this variant, which is the one documented in BS 7925-2, we include one more value at each boundary when we use boundary value analysis: **the rule is that we use the boundary value itself and one value (as close as you can get) either side of the boundary.**
:::
:::info
**BS 7925-2**: the software component testing standard. Publisher: IEEE
:::
:::info
**Exercise 4.3**
A system is designed to accept scores from independent markers who have marked the same examination script.
Each script should have 5 individual marks, each of which is out of 20, and a total for the script.
Two markers’ scores are compared and differences greater than three in any question score or 10 overall are flagged for further examination.
Using equivalence partitioning and boundary value analysis identify the boundary values that you would explore for this scenario.
:::

:::success
**Equivalence partitioning Answer:**
each scores 0 - 20
total 0 - 100
different 0 - 3 and over 3
total different 0-10 and over 10

**Boundary analysis Answer:**
each score -1 0 1 and 19 20 21
total -1 0 1 and 99 100 101
different -1 0 1 and 2 3 4
total different -1 0 1 and 9 10 11
:::

#### Decision table testing
Specifications often contain business rules to define the functions of the system and the conditions under which each function operates.
**As testers we need to be able to assure ourselves that every combination of these conditions that might occur has been tested**, so we need to capture all the decisions in a way that enables us to explore their combinations.
The mechanism usually used to capture the logical decisions is called a decision table.


**we do not enter every possible combination of conditions into our decision table**, but restrict it to those combinations that correspond to business rules – **this is called a limited entry decision table** to distinguish it from a decision table with all combinations of inputs identified.

**DECISION TABLE TESTING – EXAMPLE 4.3**
A supermarket has a loyalty scheme that is offered to all customers. Loyalty cardholders enjoy the benefits of either additional discounts on all purchases (rule 3) or the acquisition of loyalty points (rule 4), which can be converted into vouchers for the supermarket or to equivalent points in schemes run by partners.
Customers without a loyalty card receive an additional discount only if they spend more than £100 on any one visit to the store (rule 2), otherwise only the special offers offered to all customers apply (rule 1).

**From the decision table we can determine test cases by setting values for the conditions and determining the expected output**, for example from rule 1 we could input a normal customer with a £50 transaction and check that no discount was applied.
The same customer with a £150 transaction (rule 2) should attract a discount. **Thus we can see that each column of the decision table represents a possible test case.**
:::info
**Exercise 4.4**
A mutual insurance company has decided to float its shares on the stock exchange and is offering its members rewards for their past custom at the time of flotation. Anyone with a current policy will benefit provided it is a ‘with-profits’ policy and they have held it since 2001. Those who meet these criteria can opt for either a cash payment or an allocation of shares in the new company; those who have held a qualifying policy for less than the required time will be eligible for a cash payment but not for shares. Here is a decision table reflecting those rules.
:::
What expected result would you expect to get for the following test case?

Billy Bunter is a current policy holder who has held a ‘with-profits’ policy since 2003.
:::success
Billy可以拿到現金，但不會拿到股票
:::

#### State transition testing
in other words, **behaviour depends on current state and past state, and it is the transitions that trigger system behaviour.** It will be no surprise to learn that this technique is known as state transition testing or that the main diagram used in the technique is called a state transition diagram.

**which is the symbol for a state.**
A state is just what it says it is: the system is ‘static’, in a stable condition from which **it will only change if it is stimulated by an event of some kind**. For example, a TV stays ‘on’ unless you turn it ‘off’; a multifunction watch tells the time unless you change mode.
**which is the symbol for a transition, that is a change from one state to another.**
**The state change will be triggered by an event (e.g. pressing a button or switching a switch).**
The transition will be labelled with the event that caused it and any action that arises from it. So we might have ‘mode button pressed’ as an event and ‘presentation changes’ as the action.
<style>
.blue {
color: blue;
}
</style>

>STATE TRANSITION DIAGRAM – EXAMPLE 4.4
A hill-walker’s watch <span class="blue">has two modes: Time and Altimeter</span>. **In Time mode, pressing the Mode switch causes the watch to switch to Alt mode; pressing Mode again returns to Time mode. While the watch is in Alt mode the Set button has no effect.**

>When the watch is in Time mode pressing the Set button transitions the watch into Set Hrs, from which the Hrs display can be incremented by pressing the Set button.
>If the Mode switch is pressed while the watch is in Set Hrs mode the watch transitions to Set Mins mode, in which pressing the Set button increments the Mins display. If the Mode button is pressed in this mode the watch transitions back to Time mode (Figure 4.1).
Note that not all events have an effect in all states. Where an event does not have an effect on a given state it is usually omitted, but it can be shown as an arrow starting from the state and returning to the same state to indicate that no transition takes place; this is sometimes known as a ‘null’ transition or an ‘invalid’ transition.



:::info
Exercise 4.5
In the state transition diagram in Figure 4.2, which of the sequences of transitions below would be valid?
a. ABCDE
b. FEABC
c. ABCEF
d. EFADC
:::

:::success
b FEABC
:::

#### Use case testing
**Use cases are one way of specifying functionality as business scenarios or process flows.**
They capture the individual interactions between ‘actors’ and the system.
**An actor represents a particular type of user** and the use cases capture the interactions that each user takes part in to produce some output that is of value.
Test cases based on use cases at the business process level, often called scenarios, are particularly useful in exercising business rules or process flows and will often identify gaps or weaknesses in these that would not be found by exercising individual components in isolation.
**This makes use case testing very effective in defining acceptance tests because the use cases represent actual likely use.**

Well-defined use cases can therefore be an excellent basis for system level testing, and they can also help to uncover integration defects caused by incorrect interaction or communication between components.

>**USE CASES**
In a use case diagram (e.g. Figure 4.3) each type of user is known as an actor, and an actor stands for all users of the type. Use cases are activities carried out for that actor by the system. This is, in effect, a high-level view of requirements.
The diagram alone does not provide enough detail for testing, so we need some textual description of the processes involved as well.