Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 4 (4.2 CATEGORIES OF TEST DESIGN TECHNIQUES (Experience-based…
Chapter 4
4.2 CATEGORIES OF TEST DESIGN
TECHNIQUES
Static testing techniques: used to 'test' any form of the document including source code, design documents and models, functional specifications and requirement specifications. Often used to statically test source code
Specification-based (black-box) testing techniques: These are also known as 'black-box' or input/output driven testing techniques because they view the software as a black-box with inputs and outputs, but they have no knowledge of how the system or component is structured inside the box. In essence, the tester is concentrating on what the software does, not how it does it.
Structure-based (white-box) testing techniques
Structure-based testing techniques (which are also dynamic rather than static): use the internal structure of the software to derive test cases.
'White-box' or 'Glass-box' techniques (implying you can see into the system) since they require knowledge of how the software is implemented, that is, how it works.
Experience-based testing techniques
In experience-based techniques, people's knowledge, skills and background are a prime contributor to the test conditions and test cases.
The experience of both technical and business people is important, as they bring different perspectives to the test analysis and design process
Due to previous experience with similar systems, they may have insights into what could go wrong, which is very useful for testing.
Where to apply the different categories of techniques
Structure-based techniques
can also be used at all levels of testing.
the requirements specification or functional specification may form the basis of the tests.
When performing component or integration testing, a design document or low-level specification forms the basis of the tests.
used in system and acceptance testing, but the structures are different.
4.3 SPECIFICATION-BASED OR BLACK-BOX
TECHNIQUES
The specification-based techniques
Boundary value analysis
Decision tables
Equivalence partitioning
State transition testing
Equivalence Partitioning (EP)
Most testers
practise it informally even though they may not realize it.
The equivalence-partitioning technique then requires that we need test only one condition from each partition
Is a good all-round specification-based black-box
technique
if one of the conditions in a partition does not work, assume that none of the conditions in that partition will work
If one condition in a partition works,assume all of the conditions in that partition will work
Boundary value analysis (BVA)
Have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions)
Best solution to the problem is to find out what the boundary should be specified as
Is based on testing at the boundaries between partitions
Decision table testing
if different combinations of inputs result in different actions
Decision table testing and state transition testing are more focused on business logic or business rules.
The techniques of equivalence partitioning and boundary value analysis are often applied to specific situations or inputs
State transition testing
A state transition model has four basic parts
The transitions from one state to another
(not all transitions are allowed)
The events that cause a transition
(closing a file or withdrawing money)
The states that the software may occupy
(open/closed or funded/insufficient funds)
The actions that result from a transition
(an error message or being given your cash)
Note that in any given state, one event can cause only one action, but that the same event
This state diagram, even though it is incomplete, still gives us information on which to design some useful tests and to explain the state transition technique
4.1 IDENTIFYING TEST CONDITIONS AND DESIGNING TEST
CASES
Term
Test Conditions
: test requirement , test situation
An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element.
Test cases:A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.
Test basis: SRS,ADD,DDD,Source Code
Test procedures: A sequence of test cases in execution order, and any associated actions that may be required to set up the initial preconditions and any wrap up activities post execution.
Test data: Data created or selected to satisfy the execution preconditions and inputs to execute one or more test cases.
Test analysis: identifying test conditions
Test design technique: The activity of deriving and specifying test cases from test conditions
Test traceability : Test conditions should be able to be linked back to their sources in the test basis
4.6 CHOOSING A TEST TECHNIQUE
There's no best technique. Each technique is good for certain things, and not as good for other things.
The internal factors
Models used: The models available will to some extent govern which testing techniques can be used.
Tester knowledge I experience: Knowledge of Tester about the system and about testing techniques.
Likely defects: This knowledge could be gained through experience of testing a previous version of the system and previous levels of testing on the current version.
Test objective: If the test objective is simply to gain confidence that the software will cope with typical operational tasks then use cases would be a sensible approach.
Documentation: Whether or not documentation exists and whether or not it is up to date will affect the choice of testing techniques.
Life cycle model: A sequential life cycle model will lend itself to the use of more formal techniques whereas an iterative life cycle model may be better suited to using an exploratory testing approach.
The external factors
Risk: The greater the risk, the greater the need for more thorough and more formal testing.
Customer I contractual requirements; Sometimes contracts specify particular testing techniques to use.
Type of system: E.g. embedded, graphical, financial, etc.
Regulatory requirements: Some industries have regulatory standards or guidelines that govern the testing techniques used
Time and budget: When more time is available we can afford to select more techniques and when time is severely limited we will be limited to those that we know have a good chance of helping us find just the most important defects
The decision to choose techniques is depended on a number of factors, both internal and external.
4.4
4.5