The second type of test on the list is to ensure that the application does
not do anything it is not supposed to do. This is Negative Testing.
Negative Testing can get complex, but is not necessarily so. In fact, this area of testing provides some "low-hanging fruit" - defects that are there for the finding with not a lot of effort.
One of these types of defect is concerned with alphanumeric tests.
To explain - there are three types of characters:
* alphabetic characters
* numeric characters
* special characters
The first two are self explanatory. The third is simply any character that is neither alphabetic nor numeric - characters such as @ or %, for example.
Alphanumeric tests simply ensure that all the fields under test do not accept the wrong types of characters - an alpha field should not accept non-alphabetical characters, and a numeric field should not accept non-numeric characters. A field for entering an email address should accept alpha, numeric, and special characters, e.g. john.smith32@website.com
These may seem like facile issues, but you would be surprised at the number of times that you will find that a numeric field accepts letters or special characters, or vice-versa. These types of faults are quite common.
By default, these tests also verify that the fields in the application do accept the correct types of characters.
In general, it is best to divide all the fields on a particular page or screen of the application into the type of field that they are and test them together - so you would write tests to cover :
- alphanumeric + special character fields (e.g. email address, password)
- alphanumeric fields (e.g member ID, postcode)
- alpha + special character fields (e.g. name with a hyphen or apostrophe)
- alpha fields (e.g. first name)
- numeric fields (e.g. member number, date)
- numeric + special (e.g date, member id with a hyphen or slash)
Fields which only allow special characters are extremely uncommon, but if they do exist in your application, then you would of course, include a test for them.
You will not normally find that there are too many fields of each type to include in one test, but if there are, then you will have to break your tests down to cover the fields by logical area.
Negative Testing can get complex, but is not necessarily so. In fact, this area of testing provides some "low-hanging fruit" - defects that are there for the finding with not a lot of effort.
One of these types of defect is concerned with alphanumeric tests.
To explain - there are three types of characters:
* alphabetic characters
* numeric characters
* special characters
The first two are self explanatory. The third is simply any character that is neither alphabetic nor numeric - characters such as @ or %, for example.
Alphanumeric tests simply ensure that all the fields under test do not accept the wrong types of characters - an alpha field should not accept non-alphabetical characters, and a numeric field should not accept non-numeric characters. A field for entering an email address should accept alpha, numeric, and special characters, e.g. john.smith32@website.com
These may seem like facile issues, but you would be surprised at the number of times that you will find that a numeric field accepts letters or special characters, or vice-versa. These types of faults are quite common.
By default, these tests also verify that the fields in the application do accept the correct types of characters.
In general, it is best to divide all the fields on a particular page or screen of the application into the type of field that they are and test them together - so you would write tests to cover :
- alphanumeric + special character fields (e.g. email address, password)
- alphanumeric fields (e.g member ID, postcode)
- alpha + special character fields (e.g. name with a hyphen or apostrophe)
- alpha fields (e.g. first name)
- numeric fields (e.g. member number, date)
- numeric + special (e.g date, member id with a hyphen or slash)
Fields which only allow special characters are extremely uncommon, but if they do exist in your application, then you would of course, include a test for them.
You will not normally find that there are too many fields of each type to include in one test, but if there are, then you will have to break your tests down to cover the fields by logical area.
