Having looked at testing the alphanumeric attributes of the fields in your application, there are some other small, but important, tests that should be covered.
One of these is to ensure that password fields, regardless of the characters entered, are masked.
This means that each of the characters which comprise the password is shown as another character, usually *, so the password 'mypass1234%' would be shown as '***********', for example. Strictly speaking, this is a Positive Test, and it is something that either works or it doesn't. This means that the Developer has either enabled masking, or they haven't. If they have enabled it, then no amount of different ways of entering characters will disable it - so this is really a test to ensure that it has been done.
Another one is the tab order. Normally, when you enter an application, or a page/window of an application, you will find that the cursor is already placed in the first field that you need to fill.
However, during development, this is often not the case, so this, of course, is your first test. During the development phase of a project, it is quite common for the cursor to be in another field. Behind the scenes, not visible to you, each of the fields is normally numbered - on opening the page/window, the cursor is placed in field #1. If the first field you need to fill has not been defined to be field #1, then the cursor will not be in it.
When you press the tab key on your keyboard, the cursor moves to field #2, and then to field #3, etc, etc. To start and tab in the correct order, each of the fields needs to be numbered accordingly. You will frequently find that this has not been done - and the usual reason is because it has not been written into the Specifications.
This is clearly an issue that could be addressed by you during your review of the Specifications - but if you didn't do so at that time, then now is a good time to raise the question.
If the cursor is jumping around the screen in no logical or coherent order (quite a common scenario), you will not normally find any opposition to numbering the fields logically, even when it is not defined as an application behaviour in the specifications.
Copying and Pasting Specifications are often missing a definition of how an application should handle copying and pasting. Tests on this therefore often give rise to a lot of debate. From a Tester's viewpoint, this is good, as it clarifies a vagueness about the way that the application works. For example, you have a Registration Form in which the applicant is asked to enter their email address, and is then asked to confirm their email address by entering it again. The intention of asking someone to enter their email address twice is to ensure that it is correct. If it is mis-typed the first time, then the applicant is unlikely to make the same mistake the second time they enter it. So should it be possible to copy the email address from the first field and paste it into the second field? When you look at it from the point of view of the intention of asking someone to enter details twice, then it is very clear that copying and pasting should not be allowed by the application. But you will still come across the argument that it makes it easier for the user to complete the form! Perhaps you could suggest at this point that it would be even easier to not even have the second field, which of course, leaves open the possibility that the user will mis-type their email address.
One of these is to ensure that password fields, regardless of the characters entered, are masked.
This means that each of the characters which comprise the password is shown as another character, usually *, so the password 'mypass1234%' would be shown as '***********', for example. Strictly speaking, this is a Positive Test, and it is something that either works or it doesn't. This means that the Developer has either enabled masking, or they haven't. If they have enabled it, then no amount of different ways of entering characters will disable it - so this is really a test to ensure that it has been done.
Another one is the tab order. Normally, when you enter an application, or a page/window of an application, you will find that the cursor is already placed in the first field that you need to fill.
However, during development, this is often not the case, so this, of course, is your first test. During the development phase of a project, it is quite common for the cursor to be in another field. Behind the scenes, not visible to you, each of the fields is normally numbered - on opening the page/window, the cursor is placed in field #1. If the first field you need to fill has not been defined to be field #1, then the cursor will not be in it.
When you press the tab key on your keyboard, the cursor moves to field #2, and then to field #3, etc, etc. To start and tab in the correct order, each of the fields needs to be numbered accordingly. You will frequently find that this has not been done - and the usual reason is because it has not been written into the Specifications.
This is clearly an issue that could be addressed by you during your review of the Specifications - but if you didn't do so at that time, then now is a good time to raise the question.
If the cursor is jumping around the screen in no logical or coherent order (quite a common scenario), you will not normally find any opposition to numbering the fields logically, even when it is not defined as an application behaviour in the specifications.
Copying and Pasting Specifications are often missing a definition of how an application should handle copying and pasting. Tests on this therefore often give rise to a lot of debate. From a Tester's viewpoint, this is good, as it clarifies a vagueness about the way that the application works. For example, you have a Registration Form in which the applicant is asked to enter their email address, and is then asked to confirm their email address by entering it again. The intention of asking someone to enter their email address twice is to ensure that it is correct. If it is mis-typed the first time, then the applicant is unlikely to make the same mistake the second time they enter it. So should it be possible to copy the email address from the first field and paste it into the second field? When you look at it from the point of view of the intention of asking someone to enter details twice, then it is very clear that copying and pasting should not be allowed by the application. But you will still come across the argument that it makes it easier for the user to complete the form! Perhaps you could suggest at this point that it would be even easier to not even have the second field, which of course, leaves open the possibility that the user will mis-type their email address.
