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:
- Unit
- Integration (modules to larger pieces)
- System test
- ().. 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..
4
I think there are two possible views and issues:
- 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”.
- 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:
- Local (for dev)
- Integration/Verification
- Performance
- 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
1