on inability to model system behavior precisely enough, so as additional test design may be required during test execution.
Examples below demonstrate top‐down approach to functional testing.
Pretend we are working on a web‐based system that allows users save and share their notes to a group of other users subscribed to the system. System requirements state that an application should:
- Have a login system that allows users to sign up and sign in using login and password (user name contains only alphabetical symbols and is X to Y characters long; password can contain any symbols but spaces and is N to M characters long).
- Have means to change user password (old password shall be entered to confirm password change).
- Have means to accept user notes and save it into database (a user can allow or disallow making his or her notes visible to other users).
- Have means to allow users seeing notes of other users.
- System supposed to work with 1000 users.
- Each user may have up to 100 notes.
- UI description.
Let's put UI description aside and focus on main use cases for this system (what users will likely do right from the start):
- Subscribing for the service
- Logging in with correct credentials
- Submitting private notes to the system / viewing private notes
- Submitting public notes to the system / viewing public notes (including notes of other users)
- Changing private/public permission for existing notes
This is unlikely that users will change the password right after subscribing. Anyways there will be nothing wrong to include this requirement into critical path scope.
- Changing password
So, now we have use cases and all we need to do is converting them into test cases. Remember that on the data side we try picking values that users are likely to submit. User names and password would be typical combinations of symbols allowed by the application. Data submitted into notes can be a tricky thing though. Try to find out what types of notes a target user group is likely you submit and use this knowledge to generate notes content for testing.
Once we have finished test design for Critical path we can advance to the extended testing.
As you probably noted, we did not verify whether our system works correctly in respect to specified limitations on user name and password. We also have no idea on how it will work with a big number of notes available for viewing. So, let’s focus on boundary values:
- Subscribing with a name or password of minimal and maximal length.
- Adding and viewing a note of maximal size.
- Adding and viewing maximal number of notes to the system.
Now we have a much better testing coverage than if we had only critical path tests. However, it still has some weakness. We do not know how system will react if user tries to use incorrect symbols for user name or password or if its size bigger or smaller than specified.
- Subscribing with an empty name or password
- Subscribing with a name or password of minimal-1 and maximal+1 length
- Adding a note bigger that maximal size.
- Adding maximum+1 notes to the system
- Subscribing with invalid user name (containing nonalphabetic characters)
- Subscribing with invalid password (containing spaces)
- Viewing zero notes.
Note that the latest scenarios we included in our testing examine logic branches through the system. Whereas correct user name and password lead to successful completion of the operation, the variants we have chosen should lead to an error.
From the perspective of a visible user behavior, it does not matter what specific type of input have caused an error.