1. Decision Table
One of the most extensively used case design strategies for black box testing is the decision table technique. This is a methodical methodology in which various input combinations and their corresponding system behaviour are tabulated.
It's also called as a cause-and-effect table for this reason. This technique is used to choose test cases in a systematic manner; it reduces testing time and ensures that the software application's testing area is adequately covered.
For functions with a logical link between two or more inputs, the decision table technique is acceptable.
2. All-pair Testing
Pairwise testing is another name for all-pairs testing. It's used to test all of the available discrete value combinations. This combinational method is used to test applications that employ checkbox input, radio button input (radio button is used when you only have one choice to choose from, such as when selecting gender male or female), list box, text box, and so on.
Assume you have a testing function in a software application with ten fields for data input, resulting in a total number of discrete combinations of 10 10 (100 billion), however testing all possibilities is difficult because it will take a long time.
3. Cause-Effect Testing
The cause-effect graph is a type of black box testing that highlights the relationship between a given outcome and all of the factors that influence it. It's a tool for creating dynamic test cases.
When code functions dynamically based on user input, dynamic test cases are utilised. When you enter acceptable email into an email account, for example, the system accepts it, but when you enter invalid email, it returns an error notice. The input conditions are assigned causes in this technique, and the output of these input conditions is assigned effects.
The Cause-Effect graph technique is based on a set of requirements and is used to determine the smallest number of test cases that can cover the software's maximum test area.
The key benefit of cause-effect graph testing is that it cuts down on test execution time and costs.
This technique seeks to reduce the number of test cases while still providing maximum coverage for all relevant test cases to achieve the desired application quality.
Using logical operators like AND, OR, and NOT, the Cause-Effect graph technique translates the requirements specification into a logical relationship between the input and output circumstances.
4. State Transition
The general definition of state transition is "various forms of the same circumstance," and the state transition method follows this definition. When different input values are presented to the same function, it is utilised to capture the behaviour of the software application.
We all use ATMs, and when we withdraw money from one, it finally displays account information. Now we perform another transaction, and the ATM displays account information once more; however, the information presented after the second transaction differs from that showed after the first transaction, but both details are provided using the same ATM function. The same function was used here, but the output was different each time; this is known as state transition. This technique checks whether a function follows state transition specifications when different inputs are entered when testing a software application.
This is true for apps that allow a limited number of attempts to access the application, such as the login feature of a programme that locks after a certain number of incorrect attempts. Let's look at the details: in the login function, we use an email address and a password; it allows a certain number of attempts to access the application; once the maximum number of attempts has been reached, the application is locked with an error message.
Let see in the diagram:
There is a login feature in an application that allows for a maximum of three attempts, after which the user will be forwarded to an error page.
State transition table
5. Use Case
The use case is functional testing, which is a type of black box testing that is used to identify test cases from the beginning to the end of a system based on its intended use. The test team constructs a test scenario using this technique that can exercise the complete software depending on the functionality of each function from beginning to end.
It's a visual representation of business requirements that explains how the end-user will interact with the programme or application. The use cases offer us with all of the different approaches for how the end-user interacts with the programme, as shown in the graphic below:
A sample of a use case where we have a requirement connected to the customer requirement definition can be seen in the image above (CRS).
Who is the author of the use case?
The customer supplies the application's customer requirement specification, after which the development team writes the use case according to the CRS and sends it to the customer for review.
