2)
INTEGRATION TESTING
Testing the data flow or interface
between two features is known as integration testing.
Now let us consider the example of
banking s/w as shown in the figure above ( amount transfer ).
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.
There are two types of integration
testing,
Incremental
Integration Testing :
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
Top-down
Incremental Integration Testing:
Bottom-up
Integration Testing :
Non
– incremental Integration Testing
We use this method when,
a) When data flow is very complex
b) When it is difficult to identify
who is parent and who is child.
It is also called Big – Bang method.
Example for 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.
The above example displays a
homepage of a gmail inbox. When we click on inbox link, we are transferred to
the inbox page. Here we have to do non-incremental
integration testing because there is no parent and child process here.
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.
This comment has been removed by the author.
ReplyDeleteThanks for sharing this wonderful article with us. It's clearly explains about software testing complete guide. When you are telling about system testing, software testing services companies playing important role. Keep sharing content like this.
ReplyDelete