Nowadays, more than ever, the issue of software testing is relevant, and the relevance of this service lies primarily in the daily need to analyze various systems and their components. As a consequence, there are a number of types of testing. One of the classifications of testing based on the positivity of scenarios is considered below.
Positive testing is testing using scenarios that correspond to the normal (standard, expected) behavior of the system. Through this testing, it can be determined that the system does what it was designed to do. For example, multiplying the numbers 3 and 5 on a calculator.
Negative testing is testing in which scenarios that correspond to the out-of-order behavior of the system under test are used. For example, this can be exceptional situations or incorrect data. Using a calculator as an example, this is multiplying the number 3 by a pear. The pear value is not valid for the calculator.
First of all, negative testing is aimed at checking the system’s resistance to various influences, validating incorrect data, and handling exceptional situations. Positive testing scenarios are aimed at checking the operation of the system with the data types for which it was developed.
The creation of positive scenarios (test cases) precedes the creation of negative test cases. First, we check the operation of the system when our conditional user works with the system «correctly», and then proceed to check the response of the system to a user who makes various mistakes (entering incorrect data, for example). And our system must be ready to respond to the wrong request. This is the purpose of negative testing.
Today there is no exact and unanimous opinion about the ratio of positive and negative testing.
There is a perception that positive testing is considered more important than negative one.
Imagine a situation where our calculator is unstable to the introduction of incorrect data (it is difficult to multiply by pears and subtract oranges from integers). Is it critical? No. After all, users will soon realize that they shouldn’t perform some actions with a conventional calculator of numbers and will not allow operations with fruits and numbers at the same time. And now, let’s imagine that our calculator correctly responds to attempts to multiply oranges by numbers, but incorrectly calculates mathematical operations with numbers, that is, it does not fulfill its main purpose (business task).
Therefore, it is believed that positive testing is more important than negative. Individual errors when entering incorrect data are rare, and failure to fulfill the main business function is immediately noticeable.
But that does not mean that we do not need negative tests at all. It is they who contribute to the appearance of a large number of established defects.
There is also an opinion that the separation of negative from positive testing is unacceptable. Firstly, conducting two tests separately will take more time. Secondly, there is a risk of sacrificing negative testing with a lack of time. And thirdly, this may contradict the tester’s thinking.
Now let’s put aside our virtual calculator of numbers and fruits and look at some real-life test case examples.
A classic example of a login/logout:
- registration: entering a login and password, with a login without a password, via social networks;
- authorization: entering a login and password, logging in through social media;
- password recovery.
Positive scenarios:
- registration through a pair of login/password, through login, via social networks;
- registration when filling the required fields;
- registration when filling in all fields;
- checking the possibility of authorization after registration;
- registering in one browser and logging via another;
- check if the password recovery function is working.
Negative scenarios:
- re-registration (login/password already taken);
- registration without filling in the required fields (all fields are empty);
- registration with data entered in a wrong format;
- authorization with an incorrect username/password.
One more example of creating a simple contact ( that you can view, edit and delete):
Positive scenarios:
- functions of creating, editing, viewing and deleting a contact are available;
- the function of creating a contact is available when filling out the minimum number of required forms;
- the function of creating a contact is available when filling out the entire form;
- contact viewing is available after creation and compiles with the requirements;
- changes take effect after saving (updated data is reflected);
- after deleting a contact it is no longer there.
Negative scenarios:
- creating identical contacts is impossible;
- creating a contact without filling in the required fields is impossible;
- and so on.
If you have problems creating negative test cases, you can try popular examples:
-
Internal single quotes in SQL queries.
Databases have a problem detecting quotation marks when entering a query. Therefore, you need to make sure that for fields that accept normal text, the entering of quotation marks is acceptable by the system.
-
Required fields for data entry.
Basically, fields that are required for data entry are marked with an asterisk «*», which tells the user that these fields must be filled in. This is the first check – make sure that all the required fields are marked. The second is to make sure that the marked fields are indeed determined by the system as required. As part of these checks, you need to make sure that such fields really cannot be missed. It is enough to leave such fields empty when submitting the form and observe the system behavior. If the user receives an error about the need to fill in the field, then this scenario is incorrect and must be entered into the bug tracking system. Imagine a situation where a user does not enter a postal address or username during registration, and the system still successfully registers the user. Accordingly, such a user will not be able to enter the system, since he has not previously entered the data that will be required for authorization. The downside of these checks is to make sure that optional fields are required and the form can be submitted without them.
-
Data types in fields.
When checking data entry fields, you need to understand that such fields may differ in what data format they accept. For example, a text box means that it accepts any text. There are a few basic checks you can do here. First, check the character limit. Often the developers do not set a limit on characters. As a result, when entering a long name, for example, such text will be displayed in other sections of the application/site (go beyond the block, overlap other text, etc.). This is a very common problem. Secondly, we need to understand the purpose of this text box. The difference between the nickname and the name fields is significant. The nickname field can accept any set of characters, including numbers and special characters. The name field should only accept letters. Also in European countries and in the USA, it is customary to combine the name and surname under one concept «Full Name». Therefore, the field must accept at least two words separated by a space. It is also worth considering the market that the product is targeting. Indeed, in the French and German languages, additional characters (known as «umlauts») are used in names. And the input field must accept these characters. Numeric and date picker fields also have their own rules. A numeric field must accept no character other than numbers. The entered or selected date must be displayed in the correct format and so on.
-
Field size.
As mentioned above, each input field must have its own character limit. When entering characters larger than the size of the field, they should not go beyond its limits. If it is possible to change the size of the field, then when changing the field should not go beyond the block in which it is located.
-
Numerical limit values (boundary values).
Numeric fields, depending on their purpose, may have a restriction on entering numbers within the allowed range of entry. In order to know what restrictions are used, it is necessary to consult the product specification. If there is no such documentation, then it is necessary to check the basic logic of the behavior of numeric fields. For example, entering negative numbers is generally not allowed. For example, during the checkout, you can add a negative quantity of items to the cart. If the field takes on a value starting from a certain number, then entering a number less than this value cannot be accepted.
-
Numerical restrictions.
The difference between this check and the previous one is that here we check the input field for restrictions on entering numbers. For example, the weight input field accepts a three-digit number. Accordingly, the field should not accept a four-digit number.
-
Date limits.
There are a few basic checks to make when testing a date input field. Firstly, it is the entering of the date of birth on a day that has not yet come. Secondly, the system accepts users who are at least 18 years old. Accordingly, a date less than 18 years ago from the current date is considered invalid.
-
Date validity.
The date input field should only accept numeric values in a specific format. Entering text values is not allowed. It is also unacceptable to select a non-existent date (leap year, etc.)
-
Web sessions (only for web applications).
As part of this check, you need to make sure that certain functionality is available to the user only after his successful authorization in the system. Here you need to check that an unauthorized user does not have access to the functionality that is only available to an authorized user.
In conclusion, it should be said that the weight of positive and negative testing is quite large, even in comparison with such testing «whales» as functional testing or interaction testing, and therefore, they should not be neglected.
