I should define a testing strategy and environments and I have encountered rather terminology issue (but might well be my fault) so I hope someone will correct me here. We are using INT environment where the application is deployed at first and then SIT environment, where is the app passed if it is fine on INT. So, testers do all system tests on SIT. But according to all definitons, SIT is system integration testing which is done after the system tests and validates cooperation of more systems. So why SIT serves actually for system testing, yet it is said to be a phase which actually follows the system testing? EDIT: According to common knowledge-books:

  1. Unit
  2. Integration (modules to larger pieces)
  3. System test
  4. ().. System Integration Test --if there are more system to integrate

Our apps consist of db, services, frontend. So to make a system test, they must be integrated, otherwise testers cannot do anything. So SIT precedes actual system testing (both funtional and non functional) which does not match with described processes. And environment for testers is also called SIT..

  • Is this the ideal of a textbook? or the real world? In the later, people may do testing wherever and not in the prescribed order (or even over the prescribed range of tests).
    – user40980
    Apr 9, 2013 at 20:00
  • 2
    Whether or not your workplace properly performs a certain practice does not reflect what it's defined as. Apr 9, 2013 at 20:14
  • SIT is a concept, whereas the types of tests within that concept can vary. SIT encompasses testing the coexistence with other systems, not your own system integration with itself. Apr 10, 2013 at 0:30
  • @Aaron McIver It is system integration, one point of view would be that you integrate your back-end, services, front-end etc. together (which is true). But I must agree that companies I have been to were using "SIT" for testers and "INT" for developers. Also yes, "SIT" was actually used for system testing, though it is a phase which should be after system test.
    – John V
    Apr 10, 2013 at 6:06

2 Answers 2


I think there are two possible views and issues:

  1. Companies tend to use "system integration testing" / SIT for testing of their application, integrated of more sub-systems. An "INT" environment is usually the first instance that serves as a testing place for developers trying to integrate the app to a working whole. Once they have a stable system on the "INT", it is promoted to "SIT". In this context, it would not mean "integration with external systems rather than integration of sub-systems".
  2. Application could be deployed to "SIT" for system testing and if it passes, on this very same environment it is used for real external system integration. In that case, once the system testing is considered as finished, without any changes to the environment, external systems would be integrated. Also the name "SIT" would reflect what is this environment used for (you do system testing there but eventually it is used for SIT). In this case it is a combination of system testing and system integration, which is not unusual.

Probably because in terms of environment design, there may not be a difference.

At my previous employer, we had 4 types of environments:

  1. Local (for dev)
  2. Integration/Verification
  3. Performance
  4. Production

IV environments could be used for either integration testing, verification, or both. They were sometimes used for UAT as well. The only difference is really in what testers use them for.

Performance was called out as a different type because its characteristics were different. It had beefier hardware, more servers, etc. Using it for functional verification would be a waste of money and would cause a process bottleneck (we could have many more IV environments than performance environments).

So the moral of the story is that environment names don't have to perfectly mimic the phases they are a part of, but rather, what type of work they can and cannot be used for.

Ask yourself this question, if you have a dedicated Verification environment and then a SIT environment, what is the value in promoting to SIT once verification is complete? If SIT can be performed in the same environment as verification once verification is complete, then you can just stick with the single environment or environment category.

If, however, you need a separate environment for SIT either for budget reasons (SIT may by definition require more external components), or for efficiency reasons (QA may have a standard endgame/prelaunch/staging test suite with data setup pre-defined), then you may want to make a dedicated verification and SIT environment.

Sources (wikipedia, of course):



  • Well, the thing is that according to books, there is system test and then SIT. But what I see is SIT and then system test. Which also makes sense, how can you test an app if it consist of more subsystems? Apr 9, 2013 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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