Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know that integration testing means integrating unit tested moduls and testing for interface errors etc. But in real world examples, I am kinda lost. Here is an example of our system:

Back end (Java).
Front end (Flex).

Back end is processind data heavily and we have a lot of tests for weekly automated regression. But is it a system test? I think so, but on the other hand, it is just back end part testing. Or should I say it is system testing only when UI part is involved as well? But again, with testing UI we cannot test the logic in data processing.

share|improve this question
    
I think you should also consider System integration testing. –  user970696 Apr 8 '13 at 17:50
add comment

1 Answer

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

share|improve this answer
    
@user970696 - Are you're asking "how do I declare the line between integration and system testing?" The line between the two test areas is (intentionally) fuzzy and will vary by organization. That's why you'll see contradictory information; OTOH it doesn't matter that much. Testing the logic of a back-end process should be first done by integration testing on the back-end computer before it might be re-tested indirectly by an action from within the UI as part of System testing. Confusing matters is that you might re-use the same test data with both of those tests. –  GlenH7 Apr 8 '13 at 18:07
    
Why would you call back-end testing process integration testing if the system is done and ready and only feeds the UI? Isn't integration more about sanity/smoke tests when putting the software together? I am just asking, no irony intended. –  user970696 Apr 8 '13 at 18:43
    
An example: back-end is doing aggregations and processing of data. UI is just displaying it. When I test back-end operations (input and expect output), I cannot test it anyhow from UI. Still integration? To me it seems like back-end system test and with UI..maybe end to end? –  user970696 Apr 8 '13 at 18:52
    
@user970696 - No; integration testing is not "about sanity and smoke tests". It's about validation of contracts / agreements between objects. It's about making sure all of the widgets of a component are able to harmonize and work together. Loosely speaking: unit tests are sanity / smoke tests. Integration tests verify the units of the component. System test verifies the components of the system. Your back-end and UI are separate systems, which is where your suggestion of systems-integration testing comes into play. –  GlenH7 Apr 8 '13 at 18:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.