- QATestLab Blog >
- QA Basics >
- Types of Software Testing >
- Functional Testing >
- Negative Test Cases for Functional Testing
Negative Test Cases for Functional Testing
Negative testing is a testing technique when invalid input data are used for software quality assessment. Its purpose is to check the software behavior in case of invalid input. In general, you check system stability by conducting negative tests. Also, this technique gives you an insight of error handling capabilities of the software.
Here we are going to present the most popular and useful negative tests for functional verification you should definitely include into QA activities.
Embedded Single Quote
Many SQL based applications have problems encountering embedded single quote as input data, e.g., Anna’s pencil. This happens because of SQL queries designation. So, a good testing practice would be to type embedded single quote to every field that refers to the database.
Required Data Entry
Checking fields a tester should always pay attention to whether it is marked as required for filling or not. The omission of the required fields should always provoke errors with an appropriate accompanying message.
Field Type
Different fields require appropriate data types, e.g., numbers, text, time, date, telephone numbers, etc). A tester should always try to enter an incompatible data type in the field and proceed to another step. The detailed information about fields and its compatible types can be found in the specification.
Field Size
Field Size is a maximum number of characters that can be entered into the field (e.g. the “First name” field should contain more than 40 characters). A user should not be able to type more or fewer characters than the amount defined in the specification. There could be different implementations of this limit in the system. It can be, for example, an error message after a user has already entered more characters that are specified or a prevention measure.
Numeric Bounds
Some numeric fields have evident bounds every tester should check. If the bounds are not so clear, you can use the specification. For example, let’s imagine that a field requires values from 1 to 10. Try to check boundary values as well as the next values beyond the bounds (0, 1, 10, 11). Often the results are quite unexpected.
Numeric Limits
Most commonly, numbers are saved inside the application code as integers or long integers. Check the boundary values of these number types even if there are no defined bounds in the specification. Common integer boundary values are -32,767 and 32,767 and for long integers -2147483648 and 2147483647.
Date Bounds
Testers should pay special attention to dates and consider the bounds appropriate to the field. For example, for the “Age” field try to enter values more than 150 and for the “Date of Birth” field enter the date from the future. Check whether there is an expected error message or the validation has successfully been passed.
Date validity
You definitely know that there are no such dates as the 31st of June or the 30th of February, though a user may type by mistake to the “Date” field. A tester should check all data fields with invalid data inputs as well as the valid ones from the leap years.
Web session testing
If you sign up and log in the application, you could enter your personal cabinet and see the content intended only for registered users. But what if you copy URL of such a page and paste it into another browser? What if you open it on another device without logging in? A tester should always check unauthorized access to the content intended for authorized users.
Performance changes
A tester should always check the performance of an application after software updates or other code changes. The result should be compared to the previous one received during testing of the old version. The purpose of such testing is to find out potential causes of performance decreases which are caused by code changes.
These may be the top ten for application (functional) testing, but what about non-functional, OAT and DR?