Test Design Techniques

Test Design Techniques

Static Techniques
rely on not-program execution, but analyse internal structure, source code and etc.



- Reviews:
Any method where the human being is the primary defect finder and scrutinizer of the item under test

• An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements.
• Reviews usually precede dynamic tests. Because the cost of a defect increases as that defect remains in the system, reviews should happen as soon as possible. However, because not all defects are easy to find in reviews, dynamic tests should still occur.

Types :

1. Informal review - basic, no documentation, in front of small audience
2. Walkthrough - done by the developer
3. Technical Review - done by experts with documentation
4. Inspection - led by moderator, documentation of entry/exit data and metrics
5. Peer Review - separate the application to smaller modules and then analyse the application's technical characteristics

What can happen after a review?
The ideal case is that the document is okay as is or with minor changes. Another possibility is that the document requires some changes but not a re-review. The most costly outcome— the document requires extensive changes and a re-review. (This is less costly than ignoring the serious problems and dealing with them during component, integration, system, or acceptance testing.) - Static Analysis:
Relies on a tool as the primary defect finder and scrutinizer


Advantages:
- Have access to the actual instructions the software will be executing
- No need to guess or interpret behavior
- Full access to all of the software’s possible behaviors

Disadvantages:
- Require access to source code or at least binary code
- Typically need access to enough software artifacts to execute a build
- Typically require proficiency running software builds
- Will not find issues related to operational deployment environments

Dynamic Techniques
rely on program execution, compare it's action with our interaction

- Specification-based (Black-box) Techniques

• Black-box techniques are a way to derive and select test conditions, test cases, or test data
  • Based on an analysis of the test basis documentation
  • Also called specification-based or behavioral techniques
  • Tests are based on the way the system is supposed to work
• Black-box testing does not use any information regarding the internal structure of the component or system to be tested
• Two main subtypes
  • Functional - What the system does?
  • Non functional - How the system does what it does?
• Domain includes the following techniques:
  • Equivalence Partitioning
  • Boundary Value Analysis
  • Decision Table Testing
  • State Transition Testing
  • Use Case Testing
  • Pairwise Testing
  • Classification Trees Testing

Test Bases vs. Test Oracle
The term test oracle is similar and related but not the same as the test basis
The test oracle is anything we can use to determine expected results, BUT THE CODE ITSELF
Which we can compare with the actual results of the component or system under test
Anything that can serve as a test basis can also be a test oracle
An oracle can also be an existing system or someone's specialized knowledge



A test condition is an item or event that could be verified by one or more test cases


Test Procedure Specification
During test implementation the test cases are developed, implemented, prioritized and organized in the test procedure specification
- Specifies the sequence of actions for the execution of a test