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 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..

share|improve this question
    
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). –  MichaelT Apr 9 '13 at 20:00
2  
Whether or not your workplace properly performs a certain practice does not reflect what it's defined as. –  Steve Evers Apr 9 '13 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. –  Aaron McIver Apr 10 '13 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. –  user970696 Apr 10 '13 at 6:06
add comment

2 Answers

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.
share|improve this answer
add comment

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):

http://en.wikipedia.org/wiki/System_integration_testing

http://en.wikipedia.org/wiki/Integration_testing

share|improve this answer
    
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? –  user1134916 Apr 9 '13 at 20:57
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.