
- First of all, know the Business Logic very well. For this, apply Exploratory Testing Technique or understand the features well from the Business Analyst/Project Manager. Then get a good idea about how many modules are there, what is the function of a feature, who are the users.
- Then determine the ordering of the features. It means which one will run after which feature.
For example, what can a Bkash user do? KYC verified user can send money, deposit money, make payment, cashout, check balance and transaction and a lot of more. So how to order the features? Let’s order the features first.
Feature Ordering Steps:
Since a KYC verified user can only access all the features, we will do a user registration at the beginning and verify KYC with NID.
- Fillup the signup form
- Verify NID
- Login to dashboard
- Add your bank card with the bkash account
- Add money from the bank card
- Check balance and SMS
- Recharge your SIM
- Do a bill payment (utility or internet or any)
- Send money to your friend or relative
- Cash out money by cash out feature
- Money transfer to your bank account
- Check statement finally
3. Now we will add some negative and positive test cases based on the above flow. But keep in mind, flow cannot be broken.
Standard Test Case format must be maintained while adding Test Case.
Necessary columns for Standard Test Case Format:
Module Name, Test scenario, Test case Id. Test Case Title, Prerequisites, Steps, Test data, Actual Result, Expected Result
Although many more negative test cases can be added here, we will add a few negative test cases for ease of understanding. Another thing, Data Testing has not been applied here. If you do, several more test cases will be added. For example, many test cases related to Daily and Monthly Limit and Fees have been left out on purpose, otherwise the case will become much bigger.
4. Positive and Negative test cases based on the ordered feature:
- During fill up the signup form, try submitting form without giving mandatory fields (Assert the validation error)
- Then try to submit with existing NID (Assert the verification error)
- Then submit with correct info (Assert your have been get the registration successful message)
- During login, try with any unregistered Mobile Number (not yours) (Assert the verification error)
- During login, try with your recent registered mobile number but invalid PIN (Assert the verification error)
- Now login with correct credentials (Assert dashboard)
- During adding bank card, input invalid card number and try to save (Assert the validation error)
- During adding bank card, input valid card number but giving wrong validity date or CVV(Assert the verification error)
- Now Add the valid card with giving correct info
- Try to deposit money with wrong PIN (Assert the verification error)
- Deposit with valid PIN
- Check balance and SMS
- Try to recharge with less than 10 tk (Assert validation error)
- Try to recharge with valid amount e.g 100 tk (Assert the successful message and balance)
- Try to any bill payment more than balance (Assert the validation error)
- Try to bill payment with fractional amount (if accept fractional value)
- Do a bill payment with correct amount (Assert the successful message, fees, balance and SMS)
- Now try to cash out with full amount (Assert the verification error)
- Now cash out with a valid amount (less than balance including fees) but in wrong agent number (Assert the verification message)
- Now cash out with a valid amount (less than balance including fees) (Assert the successful message, fees, balance and SMS)
- During the money transfer give wrong validation date or CVV (Assert the verification error)
- Transfer money with valid amount less than balance including fees (Assert the successful message, fees, balance and SMS)
- Check transaction history
So we can see that based on only 12 features, we have already added 23 test cases in a flow. If you think a little, it is possible to increase much more.
5. Now it is possible to capture these features one by one with any testing frameworks that can be used for app automation such as (Selenium, Appium, Webdriver.IO) etc. Of course, if the Prerequisites and Test steps are created as classes, methods (such as POM architecture), our code will be much more standard. By doing this, we will not need to write repetitive code and it will be convenient to add/update any module as needed.
So let’s summarize the whole thing.
1. Every Feature and Flow of the Project/Product should be understood well
2. Then proper ordering should be done from the beginning to the end of the flow.
3. Then write the Test Case (Positive and Negative) keeping the flow.
4. Assertion must be added for each Test Case.
5. Then you need to identify the scope for which one can be automated.
6. Then, keeping the Flow in place, which can be automated, every web/app element should be automated from the beginning of the Test Case.
7. Method should be created for repetitive web/app element and steps. For this you need to know OOP well.
To subscribe our webpage, visit this link:
https://blog.feedspot.com/sdet_blogs/
Get touch with our Facebook page:
https://www.facebook.com/groups/roadtosdet
Leave a Reply