Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Accordin to ISTQB etc., it should. But from practice I can see it is not that clear.
An example: We have a backend (pulling data from external systems, processing...), DB, and frontend. Testers do system tests (in GUI) on the SIT environment (system integration testing).

Also to make the system testing, they need a system which is the result of the system integration testing.

So how can I say that SIT follows system testing? I think this is valid only if the other systems are not under my control (external systems)?

share|improve this question

It is often risky and problematic to test the integration between your system and external systems that you do not control. For example, if your system performs financial transactions, it is daunting to test whether you perform those transactions correctly. Sometimes there are "test" versions of the external systems available for integration testing. If there are not, your options are constrained.

True story: at a previous job, one of the testers performed a boundary test while integrated with an external system of a large, international bank. This resulted in a unintentional $999,999,999 transaction. Someone eventually caught the error, and no harm was done, but it still resulted in a conference call between the bank, our company, and the United States Federal Reserve. The bank's system was ultimately at fault, but the tester was discouraged from performing that type of test in the future.

ISTQB terminology/practices aside, you should aim to perform integration tests with fake data and fake/mocked external systems first. After that, you may choose to perform live tests with live external systems, but you should perform those tests with the potential risks in mind.

share|improve this answer
Nice example with the Federal Reserve :) – Bogdan Gavril Apr 12 '13 at 9:57

The system test precedes the system integration test.

The goal of the system test is to test exactly one system. If this system depends on other systems, these should not be tested at the same time, but stubs should be used instead of them. The reason for this is, that it is harder to identify the root cause of observed failures, if multiple systems are tested together, compared to only one system being tested. These failures could be defects in any of the involved systems, or in the interactions between them, or it could be test data issues etc.

After the system test has successfully been performed, this system can move to the system integration test, where it tested only with other successfully tested systems, and maybe still some stubs. In the system integration test the interaction between systems is tested.

share|improve this answer

A scenario that comes to mind where System Testing precedes Integration testing is an expense application that I worked on, that integrated with an external banking application.

Once expenses are registered by a user in the Expense application, the Admin would then run a payroll export which would result in the user being reimbursed that amount through the external banking application. Our options on testing this integration was constrained and only tested up to the point that if the correct output files were received the test is deemed to have passed.

share|improve this answer

Your Answer


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.