--Common mistakes --Too many unnecessary test patterns --Insufficient abnormal system test --Test case concept --Normal system and abnormal system --Equivalence division --Boundary value analysis --Error guessing --Test case particle size ――What is a good test case?
It is a type that creates a lot of meaningless test cases because it makes me think that "all combinations must be covered". As shown in the previous example, the number of combinations quickly becomes the number of astronomical patterns.
It is a type that does not have enough tests for abnormal patterns such as "If you enter katakana in the numerical item" or "If you cannot connect to the database". In actual system operation, unexpected situations often occur. Insufficient anomalous testing can lead to vulnerable applications that break quickly at such times.
Normal system and abnormal system The normal system is the idea of "whether or not the output is as expected for the input that the target expects." On the other hand, the abnormal system is the idea of "whether the target can properly deal with the input that is not expected".
Equivalence split Equivalence division is a method of dividing the input into meaningful groups (equivalence class) and selecting a representative value from each group. The advantage is that you can avoid testing with similar input values and you will not miss a test with meaningful input values. As an example, suppose you have an application with the following specifications.
-Enter the user's age in the text box. ・ Age can be entered from 0 to 200. ・ After inputting, press the "Check" button. -A different message box is displayed on the screen according to the entered value.
If 0-19 is entered: Message box "Underage"
If 20-99 is entered: Message box "Adult"
If 100-200 is entered: Message box saying "You live very long"
In this application, there are many types of numbers that can be entered, but you can see that there are actually only three groups. In equivalence splitting, representative values such as 10, 80, and 150 are selected from each of these groups and tested.
Boundary value analysis Boundary value analysis is a "method of inputting the value of the boundary between equivalence classes". Method implementation mistakes are generally more likely to occur at boundary values, so boundary value analysis can prevent mistakes. In the previous application, 19 and 20, 99 and 100 are the boundary values. Bugs mixed in by mistaken "less than or equal to" and "less than" in the specifications or by mistaken inequality signs "<" and "≦" in the if statement of the program can be detected using this method.
Guess the error Error guessing is a technique for guessing data patterns that are likely to cause errors and creating test cases. Such data patterns are explicit to some extent. Specifically, the following are often used.
Maximum / minimum value, value larger than maximum value / value smaller than minimum value The maximum and minimum values that can be entered and the character length are determined by the language and application specifications. Verify what happens when that value is exceeded.
Decimal We will test things such as floating point numbers that cause rounding errors when dealing with data with a large number of digits.
Empty string, space, zero, NULL Programs are prone to malfunction when "data does not exist" or "when NULL is referenced".
Character types not intended to be entered Verify that validation is working for character types that should not be entered, such as entering kanji in the numeric field or entering symbols in the name field.
Leap year, non-existent date / time Enter the leap year in the date field and make sure it works correctly. You may also try entering a date / time that does not exist, such as "2015/14/12" or "26:00:00".
Based on the above viewpoints, the test cases are identified by the following procedure.
What kind of cases can be considered in the normal system?
What kind of cases can be considered for abnormal systems?
What kind of input value can be considered when dividing by the same value for 1-2?
What kind of input values can be considered by boundary value analysis for 1-2?
Based on 1-4, consider the quality and man-hours required by the service as a test case. When identifying test cases, it is possible to build a stable application by considering the abnormal system rather than the normal system.
Test case particle size In the previous chapter, we showed "Considering the quality and man-hours required by the service ...".
For example, if the service under development is a product that is costly to the customer, test cases should be covered as much as possible. Especially when it comes to critical parts such as payment functions.
In this case, you may want to consider thoroughly testing not only the domain / application layer but also the interface layer (View, etc.).
On the other hand, for toC services that consist solely of ads and do not handle sensitive information, it may be better to spend more on developing features for the user than spending time implementing tests. You can write as many tests as you want, but the particle size is flexible depending on the nature of the service.
Recommended Posts