Migration testing: System Testing vs System Integration Testing

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!




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

1 Like

@cs0roc not sure , if you are looking something like this