Test Techniques - Chapter IV of ISTQB-CTFL
Choosing the right test techniques depends on many factors, such as complexity, regulations, and budget. Testers often use a combination of techniques and adjust their formality as needed.
Categories of Test Techniques
The purpose of using any tesh technique is to identify the test conditions, cases, and data. Three types or categories of test techniques are mentioned in the syllabus, and each has its subtypes. However, the techniques that are mentioned below are not the only ones we can use; those are the ones that take place in the ISTQB standards!
Black-Box Test Techniques
Black-box test techniques analyse test basis, focusing on inputs and outputs without internal structure, and apply to functional and non-functional testing, ensuring accurate and reliable results.
The requirement documents, use cases and user stories are the typical test basis for this technique.
Equivalence Partitioning
- Each partition is called an equivalence class and each value can belong to only one partition. There are equivalence partitions for both valid and invalid values.
- Think of an exam result where one can have 3 grades. The partitions can be 0–50 (failed), 50–75 (need to take the exam again), and 75–100 (passed). However, we also need to be careful about invalid values such as -10 or 101.
- To achieve 100% coverage, test cases must cover all identified partitions, including invalid ones, using at least one value from each. Coverage is measured by the number of equivalence partitions tested, expressed as a percentage.
Boundary Value Analysis
- It is an extension of equivalence partitioning but can only be used with ordered partitions where there are minimum and maximum values of the partitioning.
- This technique is suitable for all test levels.
- We divide the number of boundary values tested by the total number of identified boundary test values and which gives the boundary coverage is usually expressed as a percentage.
- For the boundary values, we can use the values before, at, and just over the boundary.
- Let’s consider the example given in the prior technique, for the 50–75 interval we could use the values 49, 50, 51, 74, 75, and 76.
Decision Table Testing
Decision tables are useful for recording complex business rules in a system. They identify inputs and resulting actions, with conditions at the top and actions at the bottom. Each column corresponds to a decision rule, defining a unique combination of conditions that executes the associated actions.
The values of these conditions and actions are typically represented as Boolean values, discrete values, or numbers or ranges of numbers. These types of conditions and actions can be found together in the same table.
- The minimum coverage standard for decision table testing requires one test case per rule
State Transition Testing
- A state transition diagram only displays probable software states and their entry, exit, and transitions. An event initiates a transition, which can lead to multiple changes or actions.
- On the other hand, the state transition table displays valid and potentially invalid transitions.
- The number of tested states/transitions over the number of all states/transitions gives us the coverage (as a percentage)
Use Case Testing
- Use cases involve actors (users, external hardware) and subjects (systems) and each of them specifies some behaviour that the actors can take
- There can be different types of scenarios such as positive and negative or expected, exceptional, error etc.
- Pre-conditions and post-conditions are typical aspects of use cases
White-Box Test Techniques
White-box test techniques analyze test object architecture, design, internal structure, or code, focusing on structure and processing, unlike black-box techniques and are commonly used at component test levels
Statement Testing & Coverage
Statement testing evaluates potential executable code statements, calculating coverage by dividing test executions by total executable statements. Essentially, this means that we must cover every statement in the code.
Decision Testing & Coverage
During decision testing, the code's decision-making abilities are put to the test to see how it responds to various outcomes. This is achieved by testing cases that follow the control flow starting from a decision point.
Achieving 100% decision coverage guarantees 100% statement coverage (but not vice versa)
Experience-Based Test Techniques
When designing, implementing, and carrying out tests, experience-based test methodologies take advantage of the experience of developers, testers, and users. These methods are frequently used in combination with black-box and white-box test methodologies.
Measuring the coverage is challenging because this method is rather informal. There are three types of experience-based test techniques mentioned in the syllabus.
Error Guessing
Error guessing is a method used to predict errors, defects, and failures based on the tester’s knowledge of things like: • How the application has previously operated • What kinds of errors are likely to be made • Failures that have happened in other applications.
A methodical error-guessing technique involves creating a list of possible errors, defects, and failures, and conducting design tests to identify them. These lists can be based on experience, data, or common knowledge of software failures.
Exploratory Testing
- It involves the design, execution, logging, and dynamic evaluation of unstructured (not pre-defined) tests
- The test findings are used to discover more about the system or component and to develop tests for any potential testing gaps
- Session-based testing is a technique used occasionally to organise exploratory testing with a pre-defined time frame
Checklist-Based Testing
- In this type, testers design, implement and execute tests to cover test conditions found in a checklist. Testers are also responsible for creating and/or expanding the list
- It supports various test types, including functional and non-functional testing.
- When there are no detailed test cases, checklist-based testing can provide guidelines and a degree of consistency.
ISTQB offers dynamic techniques (e.g., black-box, white-box testing) and static techniques (e.g., code reviews, inspections). The key is to pick the right technique based on your project needs. So, mix and match these techniques, and you’ll have fantastic test coverage, delivering top-notch software! Happy testing! 😊🚀