14-07-2015, 02:44 PM
100 test scenario for gmail in integration testing
Scenario 1 – Login as A to amount transfer – send 100rs amount – message should be displayed saying ‘amount transfer successful’ – now logout as A and login as B – go to amount balance and check balance – balance is increased by 100rs – thus integration test is successful.
Scenario 2 – also we check if amount balance has decreased by 100rs in A
Scenario 3 – click on transactions – in A and B, message should be displayed regarding the data and time of amount transfer
Thus in Integration Testing, we must remember the following points,
1) Understand the application thoroughly i.e, understand how each and every feature works. Also understand how each and every feature are related or linked to each other.
2) Identify all possible scenarios
3) Prioritize all the scenarios for execution
4) Test all the scenarios
5) If you find defects, communicate defect report to developers
6) Do positive and negative integration testing. Positive – if there is total balance of 10,000 – send 1000rs and see if amount transfer works fine – if it does, then test is pass. Negative – if there is total balance of 10,000 – send 15000rs and see if amount transfer happens – if it doesn’t happen, test is pass – if it happens, then there is a bug in the program and send it to development team for repairing defects.
Let us consider gmail software as shown above. We first do functional testing for username and password and submit and cancel button. Then we do integration testing for the above. The following scenarios can be considered,
Scenario 1 – Login as A and click on compose mail. We then do functional testing for the individual fields. Now we click on send and also check for save drafts. After we send mail to B, we should check in the sent items folder of A to see if the sent mail is there. Now we logout as A and login as B. Go to inbox and check if the mail has arrived.
Scenario 2 – we also do integration testing for spam folders. If the particular contact has been marked as spam, then any mail sent by that user should go to spam folder and not to the inbox.
We also do functional testing for each and every feature like – inbox,sent items etc .
Let us consider the figure shown above.
We first do functional testing for all the text fields and each and every feature. Then we do integration testing for the related features. We first test for add user and list user and delete user and then edit user and also search user.
Points to remember,
1) There are features we might be doing only doing functional testing and there are features we might be doing both integration and functional testing. It depends on features.
2) Prioritizing is very important and we should do it at all the stages which means – open the application and decide which feature to be tested first. Go to that feature and decide which component must be tested first. Go to that component and decide what value to be entered first. Don’t apply same rule everywhere!!. Testing logic changes from feature to feature.
3) Focus is important i.e, completely test 1 feature and then only move onto another feature.
4) Between 2 features, we might be doing only positive integration testing or we might be doing both positive and negative integration testing. It depends on the feature.
Take two modules. Check if data flow between the two is working
fine. If it is, then add one more module and test again. Continue like
this. Incrementally add the modules and test the data flow between
the modules.
There are two ways,
a) Top-down Incremental Integration Testing
b) Bottom – up Incremental Integration Testing
In the above example. The development team develops the s/w and send it to the CEO of the testing team. The CEO then logs onto the s/w and creates the username and password and send a mail to a manager and tells him to start testing the s/w. The manager then edits the username and password and creates an username and password and send it to the engineer for testing. This hierarchy from CEO to Testing Engineer is top-down incremental integration testing.
Similarly, the testing engineer once he finishes testing sends a report to the manager, who then sends a report to the CEO. This is known as bottom-up incremental integration testing.
Stub is a dummy module which just receives data and generates a whole lot of expected data, but it behaves like a real module. When a data is sent from real module A to stub B, then B just accepts the data without validating and verifying the data and it generates expected results for the given data.
The function of a driver is it checks the data from A and sends it to stub and also checks the expected data from stub and sends it to A. Driver is one which sets up the test environment and takes care of communications, analyses results and sends the report. We never use stubs and drivers in testing.
In WBT, bottom-up integration testing is preferred because writing drivers is easy. In black-box testing, no preference and depends on the application.
Scenario 1 – Login as A to amount transfer – send 100rs amount – message should be displayed saying ‘amount transfer successful’ – now logout as A and login as B – go to amount balance and check balance – balance is increased by 100rs – thus integration test is successful.
Scenario 2 – also we check if amount balance has decreased by 100rs in A
Scenario 3 – click on transactions – in A and B, message should be displayed regarding the data and time of amount transfer
Thus in Integration Testing, we must remember the following points,
1) Understand the application thoroughly i.e, understand how each and every feature works. Also understand how each and every feature are related or linked to each other.
2) Identify all possible scenarios
3) Prioritize all the scenarios for execution
4) Test all the scenarios
5) If you find defects, communicate defect report to developers
6) Do positive and negative integration testing. Positive – if there is total balance of 10,000 – send 1000rs and see if amount transfer works fine – if it does, then test is pass. Negative – if there is total balance of 10,000 – send 15000rs and see if amount transfer happens – if it doesn’t happen, test is pass – if it happens, then there is a bug in the program and send it to development team for repairing defects.
Let us consider gmail software as shown above. We first do functional testing for username and password and submit and cancel button. Then we do integration testing for the above. The following scenarios can be considered,
Scenario 1 – Login as A and click on compose mail. We then do functional testing for the individual fields. Now we click on send and also check for save drafts. After we send mail to B, we should check in the sent items folder of A to see if the sent mail is there. Now we logout as A and login as B. Go to inbox and check if the mail has arrived.
Scenario 2 – we also do integration testing for spam folders. If the particular contact has been marked as spam, then any mail sent by that user should go to spam folder and not to the inbox.
We also do functional testing for each and every feature like – inbox,sent items etc .
Let us consider the figure shown above.
We first do functional testing for all the text fields and each and every feature. Then we do integration testing for the related features. We first test for add user and list user and delete user and then edit user and also search user.
Points to remember,
1) There are features we might be doing only doing functional testing and there are features we might be doing both integration and functional testing. It depends on features.
2) Prioritizing is very important and we should do it at all the stages which means – open the application and decide which feature to be tested first. Go to that feature and decide which component must be tested first. Go to that component and decide what value to be entered first. Don’t apply same rule everywhere!!. Testing logic changes from feature to feature.
3) Focus is important i.e, completely test 1 feature and then only move onto another feature.
4) Between 2 features, we might be doing only positive integration testing or we might be doing both positive and negative integration testing. It depends on the feature.
Take two modules. Check if data flow between the two is working
fine. If it is, then add one more module and test again. Continue like
this. Incrementally add the modules and test the data flow between
the modules.
There are two ways,
a) Top-down Incremental Integration Testing
b) Bottom – up Incremental Integration Testing
In the above example. The development team develops the s/w and send it to the CEO of the testing team. The CEO then logs onto the s/w and creates the username and password and send a mail to a manager and tells him to start testing the s/w. The manager then edits the username and password and creates an username and password and send it to the engineer for testing. This hierarchy from CEO to Testing Engineer is top-down incremental integration testing.
Similarly, the testing engineer once he finishes testing sends a report to the manager, who then sends a report to the CEO. This is known as bottom-up incremental integration testing.
Stub is a dummy module which just receives data and generates a whole lot of expected data, but it behaves like a real module. When a data is sent from real module A to stub B, then B just accepts the data without validating and verifying the data and it generates expected results for the given data.
The function of a driver is it checks the data from A and sends it to stub and also checks the expected data from stub and sends it to A. Driver is one which sets up the test environment and takes care of communications, analyses results and sends the report. We never use stubs and drivers in testing.
In WBT, bottom-up integration testing is preferred because writing drivers is easy. In black-box testing, no preference and depends on the application.
