08-16-2017, 09:01 PM
integration scenario for gmail login
Team
Can u please reply back whether my scenarios are correct
1.scenario for launching the gmail.com from the web browser
2.scenario for authentication with correct uid and pwd for gmail.com
3.scenario for authentication with wrong uid and pwd for gmail.com
4.Checking the inbox is accessible and sorting of mails datewise
5.Check clicking of compose mail new window is opening
6.Checking of spam mails stored in the spam folder
7.Checking of deleting mails getting deleted
8.Check sigining out of gmail.com page returns to the home page
Please clarify if anything is left.
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.