Your understanding of Integration Testing may be only partially correct.
You said:
I know that integration testing means integrating unit tested modules and testing for interface errors etc.
And yes, integration testing involves integrating together modules that have (preferably) been unit tested to verify they play nicely with each other.
The next portion is where I think there may be some confusion.
If by interface you mean user interface then your understanding is incorrect. On the other hand, if you mean software Interface as is commonly used in OO programming, then your understanding is OK.
Integration testing is agnostic to front-end / back-end / middle-tier / n-layer / blah-blah-blah. As the SWEBOK section on Integration testing puts it:
Integration testing is the process of verifying the interaction between software components. Classical integration testing strategies, such as top-down or bottom-up, are used with traditional, hierarchically structured software.
Modern systematic integration strategies are rather architecture-driven, which implies integrating the software components or subsystems based on identified functional threads. Integration testing is a continuous activity, at each stage of which software engineers must abstract away lower-level perspectives and concentrate on the perspectives of the level they are integrating. Except for small, simple software, systematic, incremental integration testing strategies are usually preferred to putting all the components together at once, which is pictorially called “big bang” testing.
Wikipedia's entry on Integration Testing isn't bad either:
Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.
So I think some of your confusion stems from worrying about which layer is being involved and how that rolls into what your organization is calling "Integration Testing." It may very well be that your organization is using a less-than-precise variation of the term.
Have a look at SWEBOK's section on Testing to get a better understanding of the various classifications of testing (including unit, system, and usability). That should help sort out the remainder of your questions regarding which testing is which and what aspects should be tested at what stages of Testing.
SWEBOK stands for Software Engineering Body of Knowledge
