Software Testing Techniques
Although there is a number of methods and techniques used in software testing, we can divide them into three categories. The first one includes black-box techniques (you can find out a little bit more about them in the article about Usability testing) - also called techniques based on the product specification. They consist of defining and selecting test points based on documents, then describing the functionality of the components or the system. These are:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Table Testing
- State Transition Testing
- Use Case Testing
The second category of testing techniques are white-box techniques, otherwise known as structure-based. They are based on the code or architecture analysis and include:
- Statement Testing and Coverage
- Decision Testing and Coverage
- The Value of Statement and Decision Testing
In the last category, there are experience-based techniques which rely on the tester's experience, skills, and intuition. Consequently, the more experience and knowledge the tester has with similar technologies and applications, the more effective they are. These techniques include:
- Error Guessing
- Exploratory Testing
- Checklist-based Testing
How to use a decision table?
What is a decision table?
A decision table is a black-box test technique that visually presents combinations of inputs and outputs, where inputs are conditions or cases, and outputs are actions or effects. A full decision table contains all combinations of conditions and actions. On the contrary, optimized one excludes impossible combinations of conditions and combinations of inputs that don't have any effect on outputs. They can also be applied when the action of the software depends on many logical decisions. What’s more these techniques can be used at any test level.
How to create a decision table?
To explain how to create a decision table we will illustrate it with the login feature. What cases should we consider?
- A user can enter a valid email or invalid email.
- The user’s email is in the database.
- A user enters a correct or incorrect password (a password that doesn’t fit the account or password is invalid).
- A user can be blocked.
The table above looks overcomplicated, but we still have to optimize it by removing cases that cannot exist and combining cases for which a change in one of the conditions is not relevant to the action of the system. We can see that some cases don't have any sense. Case 3, 9, 10, and 15 cannot occur because, when an email is invalid, it cannot be saved in the database, so we can delete those cases. The next cases to be removed are 4, 7, 11, and 14 - if the email is not saved in the database, it cannot be blocked. We can also combine cases 1 and 5 if the email is invalid (it doesn't matter if the password is). Let’s see what the table looks like now, after simplifying and removing a few cases.
Of course, in decision tables, we can use Yes/No or True/False - which are analogous to 0/1 values. We can use number value (for example, temperature), words, or pictograms (or whatever we need). An example of such a decision table may be a table containing information about access to various locations of the application by users, depending on the type of user.
A decision table, as a tool to find missing signals
To present how a decision board can help in finding missing signals, we will use the example of simplified water heating, operating on the following principles:
- Water in the tank should have a temperature between 30*C and 60*C.
- The heater turns on when the temperature drops below 30*C.
- The heater turns off when the temperature rises to 60*C.
- The heater will also turn off when the water in the tank drops below the minimum level.
At first glance, all we need to do with the table is to optimize the decision table. However, it is not recommended for us to turn on the water heating as soon as the temperature drops to 60*C, because according to our assumptions we want the temperature in the tank to be between 30 and 60*C. So we should optimize cases 1,2, and 3 - change the temperature to ‘-’(because the heating doesn’t switch on when the water level is too low) and add one condition and one action changing the value of this condition, we’ll call it ‘warm water’. When the water is warm, the heating won’t switch on.
How can the decision table help in software testing?
A well-created decision table can help to sort out the right response of the system, depending on the input data, as it should include all conditions. It simplifies designing the logic and thus improves the development and testing of our product. With design tables, the information are presented in a clear, understandable way so it's easier to find them than in the text describing the logic of the system. And finally, of course, creating using this technique helps to find edge cases and to identify missing signals in the system.
Want to develop your testing skills with the best QA specialists? Check our job-offers and join our Quality Assurance Team!