Hi there,
Please can people give me their throughs on distinction between âsystem testingâ versus âsystem integration testingâ within the context of testing data migration?
Sorry, not got much context to share!
Thanks,
H.
Hi there,
Please can people give me their throughs on distinction between âsystem testingâ versus âsystem integration testingâ within the context of testing data migration?
Sorry, not got much context to share!
Thanks,
H.
A problem with data bugs, e.g. data migration bugs, is that itâs not always obvious where they will show up / cause a problem. In a data-backed web app, bad data might cause some back-end code to fail, or some front-end code to fail. So you will probably need system testing, rather than e.g. just testing via an API, to test the data.
There is an interface between the front end and back end of a web app, so you could describe this as integration testing. However, there might be bigger, more important and riskier interfaces around, and the testing of these is what might be referred to as system integration testing.
For instance, if the system under test is actually a collection of systems (e.g. micro-services) and you add customers to the customer system via the data migration, has the same / equivalent data also been added to the debt chasing system, the payment system, the order history system etc? Tests would need to make sure theyâre testing the conversation across these interfaces.
Then there are major interfaces where you donât control whatâs on one side e.g. when talking to a bank (assuming your code is not also that bank, e.g. an online shop). Has the data in the part of the system under test that talks to the bank been migrated such that the necessary conversations can happen correctly?
Iâve noticed a general tendency in our industry to create rather arbitrary buckets (e.g. âAPI testingâ vs âUI testingâ, âend to end testingâ vs âintegration testing vs âsystem testingâ) and then split hairs over which buckets to put which tests in. Not to disparage this particular question, thatâs just my general observation. Maybe itâs partly the fault of ISTQB or something.
Personally, I donât think thereâs value in making a distinction between âsystem testingâ and âsystem integration testingâ, and I actually have no idea what that distinction is if someone has made it . What I think would be much more valuable is to take a step back and consider what kind of problems youâre looking for, what risks youâre concerned about and what you want to test. After you know that, it may be useful to bucket things based on how it makes sense to test different things on your list. I think @bobs answer did a great job of describing that aspect.
@cs0roc not sure , if you are looking something like this
Data migration is the process of moving data from one location to another, one format to another, or one application to another.
The data migration activity starts with the data backed up on the tape, so that, at any time, the legacy system can be restored. All the scripts and steps must be documented correctly without any ambiguity.
To note down the actual time taken for migration from the starting of migration till successful restoration of the system is one of the test cases to be executed and so that the âTime taken to migrate the systemâ needs to be recorded in the final test report which will be delivered as part of Migration test results and this information will be useful during the production launch. The downtime recorded in the test environment is extrapolated to calculate the approximate downtime in the live system. It is on the legacy system where the Migration activity will be carried out.
During the data migration testing, all the components of the environment will usually be brought down and removed from the network to carry out the Migration activities. Thatâs why it is important to note the âDowntimeâ required for the Migration test.
Once the application is successfully migrated, then data migration testing comes into the picture. Here end-to-end System testing is performed in the testing environment. Testers execute identified test cases, test scenarios, use cases with legacy data as well as a new set of data.
As per the testers, it all means that the application has to be tested thoroughly end-to-end along with migration from the existing system to the new system successfully.
System testing has to be performed in this case with all the data, which are used in an old application and the new data as well. Existing functionality needs to be verified along with the new/updated functionality. So, data migration testing includes testing with old data, new data or combination of the both, old features (unchanged features), and the new features.
The Integration test cases can be used to verify the interface between the components should be extensively tested, as the data should not be modified, lost, and corrupted when it is going through components.