From Requirements To Test Cases
This document is trying to give some guideline about how to do the requirement analysis, test plan and test case writing. The actual tasks and results should not be restricted by the guidelines documented here. As QA is more a creative activity, QA engineers should be creative to think about test cases and try everyway to break the system, at the same time stay focused so that a quality task can be done in a limited time.
An Example
Ideally any requirement can be divided into number of scenarios (user operations) and each scenario into number of test cases.
If you are testing a login screen, the requirement can be something like "Login screen should have username/password text fields and login/cancel buttons".
We can have scenarios from this requirement like,
1. Ensure that user with a valid username/password should be able to login.
2. If password/username is wrong user should not be able to login, an error page will be sent back.
3. If a valid user tries with invalid password 3 times he should be get locked for 24 hours.
For each scenario mentioned above we can have number of test cases depends the constraints. Test cases of first scenario will be like.
Assume there is a constraint for username length minimum-4 and password-6 characters.
1.a Try to login with valid username with length-4 and password with length-4.
1.b username with length 5 and password-4
1.c If there is an upper length limit can have test cases for that also....
What is a scenario?
A scenario (test requirement/testing points/functional points) is defined as a situation for a certain system behavior to happen. For any requirement, we need to really understand the requirement and classify the system behavior into multiple categories. As in the example above, three different scenarios are listed.
Scenario will help us think about the testing purpose for the particular feature.
From Requirements to scenarios
Here are some default scenarios to find out the scenarios based on the requirements.
- UI page
- Any submit action that results in different pages as normal flow
- Anything that results in abnormal flow
- Input validation
- Accuracy of the results
- Spelling check
- Graphic issues (color, shape, alignment)
- API argument change/New API
- Normal behavior with correct arguments
- Abnormal flow with wrong arguments
- Out of range arguments
- Missing arguments
- Null arguments
- Empty string, zero, negative cases
- Performance testing
- Related portal testing
- Regression testing on API and Portal
- File processing
- Normal behavior for file processing
- Wrong file format testing
- Testing the notification mechanism when file format is wrong and not coming
- Test the impact for big size file.
- Test on wrong file name or format
- Test on zero size file
- Test on wrong file creation time
- Scheduler
- Change the time waiting period
- Change the time activation time
- Change the property file format and value
- Verify scheduler internal is longer enough
- Message and keyword change
- Message format and spelling
- Normal behavior flow
- Abnormal behavior flow
- Default message
- Test when keyword is empty string
- Test different messages at multiple tries
- Test number of messages sent
- Backend API initialized features such as download retry
- Normal behaviors
- Abnormal behaviors
- Related MO testing
- Related portal testing
- Regression testing
From scenarios to test cases
A test case is the exact steps to verify a system behavior based on different constraints of inputs.
Test case will help us think about the exact steps to execute the test.
For each scenario, different user input, constraints, variables need to be identified. When such constraints, variables changes, the test case will need to be changed as well. Therefore a new test case will be produced. Overall, the number of test cases depends on the number of different combination for the constraints in the environment.