Negative test cases allow checking the software functionality when negative data is used. Such test cases should be performed while checking any software.

Further, we will name 10 most used negative test scenarios that should be applied regularly.

1. Embedded Single Quote

Most of the SQL database can have some problems with single quotes in a request body (for example, Ritchie’s car).
You should always use single quotes when validating each entry field that is functioning with the database.

2. Required Data Entry

In any product specification, you have to indicate all the mandatory fields. Remember that all the mandatory forms with number or text fields cannot be saved empty.

3. Fields Type Test

Software specification has to include data types for each field particularly (date field, time field, numeric field, the field for a contact phone number, field for email, etc.). You should always test every text field for its ability to easily enter/delete (and save) some kind of information from the specification. For example, a program must show the prohibition of entering letters and special symbols if the field is numeric.

4. Fields Size Test

Information criteria of software conformance to the requirements have to validate only the exact maximal number of symbols in any field. For example, there should be no more than 50 symbols in a field with a user name. Also, it is worth testing that the program doesn’t allow the user to enter or save more symbols than it is said in the specification.

[highlight dark=”no”]Don’t forget that information in any field should be not only validated correctly. It also has to notify users about given limits.[/highlight] For example, it can be notification based on explanatory text blocks or pop-ups with errors.

5. Numeric Bounds Test

Some software numerical fields may contain certain restrictions on entering valid numerical combinations. Such limits may be in the product specification or may come from the logic of its operation.

For example, you have a task to test the functionality that’s associated with charging interest on the account. In this case, the test case should check the possibility of charging interest to take the negative value (meaning, is it possible or no).

It is always worth to assure that the software shows the error message when the value is outside the acceptable valid range. For example, the error message must appear when entering 19 and 26 if the possible values are from 20 to 25.

6. Numeric Limits Test

There are a lot of databases and programming languages that define numeric values in the form of variables with a particular type.

It is extremely important to test the boundary values of the variables for numeric fields the boundary values of which aren’t clearly defined and described in the specification.

7. Date Bounds Test

Some products have a logical restriction for the date and time fields. For example, if a QA engineer is testing the date of birth field of a user, it will be the right choice to check the possibility of entering the future date. Also, it is worth checking the restriction on the entry date that is different from the necessary one for more than 150 years.

8. Date Validity

The date field must contain a programmed check for entering valid values. And it is always worth remembering the need for testing dates in a leap year.

9. Web Session Testing

Many web programs are based on browser sessions and are aimed at tracking users who are logged in. Moreover, they additionally apply a lot of specific configurations for a particular virtual user.

Besides, some software features cannot and should not work without preliminary logging in the system. It is necessary to test the software for the fact that the pages or logic of the software after logging are completely inaccessible to users who have not passed the verification process in the system.

10. Performance Changes

All new versions of the software should be introduced into use only after the stage of testing their performance (speed of adding data, the process of deleting information, etc.).

Compare results with performance tests of early product modifications. This testing strategy allows you to initially find possible performance problems that may arise as a result of editing program code in new software versions.