La tua comprensione dei test di integrazione potrebbe essere solo parzialmente corretta.
Hai detto:
I know that integration testing means integrating unit tested modules and testing for interface errors etc.
E sì, i test di integrazione prevedono l'integrazione di moduli che sono stati (preferibilmente) testati in unità per verificare che funzionino bene l'uno con l'altro.
La prossima parte è dove penso che ci possa essere una certa confusione.
Se per interface intendi interfaccia utente la tua comprensione non è corretta. D'altra parte, se intendi l'interfaccia software utilizzata comunemente nella programmazione OO, allora la tua comprensione è OK.
I test di integrazione sono agnostici per front-end / back-end / middle-tier / n-layer / blah-blah-blah. Come la sezione SWEBOK sui test di integrazione dice:
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.
La voce di Wikipedia su Test di integrazione non è male neanche:
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.
Quindi penso che parte della tua confusione derivi dal preoccuparsi di quale livello è coinvolto e di come si inserisce ciò che la tua organizzazione chiama "Test di integrazione". Potrebbe anche essere che la tua organizzazione stia utilizzando una variazione meno precisa del termine.
Dai un'occhiata alla sezione di SWEBOK sui test per avere una migliore comprensione del varie classificazioni dei test (inclusa unità, sistema e usabilità). Questo dovrebbe aiutare a risolvere il resto delle domande riguardo a quali test sono e quali aspetti dovrebbero essere testati in quali fasi del test.
SWEBOK è l'acronimo di Software Engineering Body of Knowledge