This guide standardizes the test case design, all test cases will be based on user stories acceptance criteria.
The test cases will be using one or a combination of software testing techniques below.
Boundary Value Analysis - is a test case design technique to test boundary value between partitions (both valid boundary partition and invalid boundary partition). A boundary value is an input or output value on the border of an equivalence partition, including minimum and maximum values at inside and outside boundaries.
E.g. Let us assume a test case that takes the value of age from 21 to 65.
BOUNDARY VALUE TEST CASE | ||
---|---|---|
INVALID TEST CASE (Min Value – 1) | VALID TEST CASES (Min, +Min, Max, -Max) | INVALID TEST CASE (Max Value + 1) |
20 | 21, 22, 65, 64 | 66 |
Equivalence Partitioning - Equivalence partitioning is a technique of software testing in which input data is divided into partitions of valid and invalid values, and it is mandatory that all partitions must exhibit the same behavior.
E.g. OTP Number = 6 digits
VALID (DIGITS = 6) | INVALID (DIGITS >= 7) | INVALID (DIGITS <= 5) |
---|---|---|
123456 | 7654321 | 4321 |
State Transition - is a type of software testing which is performed to check the change in the state of the application under varying input.
E.g.
Correct PIN | Incorrect PIN | |
---|---|---|
S1: Start | Access Granted | S2 |
S2: 1st Attempt | Access Granted | S3 |
S3: 2nd Attempt | Access Granted | S4 |
S4: 3rd Attempt | Access Granted | Account Blocked |
Decision Table - is a software testing technique that is used for testing the system behavior for different input combinations.
E.g.
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
---|---|---|---|---|
Username | Valid | Valid | Invalid | Invalid |
Password | Valid | Invalid | Valid | Invalid |
Output | Success | Error | Error | Error |
Error Guessing - is a software testing technique based on guessing the error which can prevail in the code. The technique is heavily based on the experience where the QAs use their experience to guess the problematic part of the testing application. Hence, the QAs must be skilled and experienced for better error guessing.
Guidelines for Error Guessing:
The test should use the previous experience of testing similar applications
Understanding of the system under test
Knowledge of typical implementation errors
Remember previously troubled areas
Evaluate Historical data & Test results
Exploratory Testing - is simultaneously designing and executing tests to learn about the system.
When do we use exploratory testing?
We will use this testing for the following aspects:
When the requirement is missing
Early iteration is required
The QA team has experienced QAs when we have a critical application, and new QAs entered into the team.
Here are some cited test case examples.
User Story: SM-1204 - Privacy policy, Terms of Use, T&C acceptation Done
As a customer, I want to accept T&C so that I can continue in onboarding.
Acceptance criteria:
By clicking on each of the links a correct document type in its last version is displayed to the Customer
The Customer that does not agree to all of the documents (does not tick the checkbox), cannot proceed with onboarding
Once accepted the consent, the version of each document and timestamp is stored in the Prospect profile
In case some document is not downloaded and displayed to the customer, the error/info screen will pop up and the customer is asked to reload/retry or return to this step later on.
Test Cases For Acceptance Criteria #1 - “By clicking on each of the links a correct document type in its last version is displayed to the Customer”
Test Case 1: UI | MOBILE | ONBOARDING | User Has Viewed The Privacy Policy
Preconditions:
User is in SaFi Bank Privacy principles screen
Steps:
Tap on Privacy Policy
Expected Results:
Privacy Policy Screen should be displayed
Test Case 2: UI | MOBILE | ONBOARDING | User Has Viewed The Terms of Use
Preconditions:
User is in SaFi Bank Privacy principles screen
Steps:
Tap on Terns of Use
Expected Results:
Terms of Use Screen should be displayed
Test Case 3: UI | MOBILE | ONBOARDING | User Has Viewed The Terms and Conditions
Preconditions:
User is in SaFi Bank Privacy principles screen
Steps:
Tap on Terns of Use
Expected Results:
Terms and Conditions Screen should be displayed
Test Cases For Acceptance Criteria #2 - “The Customer that does not agree to all of the documents (does not tick the checkbox), cannot proceed with onboarding”
Test Case 1: UI | MOBILE | ONBOARDING | User Has Not Able To Proceed To Onboarding When I Confirm Checkbox Is Not Ticked
Preconditions:
User is in SaFi Bank Privacy principles screen
Steps:
Do not tick “I confirm” checkbox
Tap on “Continue” button
Expected Results:
Not able proceed to Onboarding step