Why should you test for backward compatibility during sprint testing?

Question

For example right now we are finished with the development of our sprint 10 and want to start testing sprint testing in Stage environment.

I was told that we should first test 'Sprint 10 frontend from Stage' against 'Sprint 10 backend from stage'. (I know why we need to do this)

And then also test 'Sprint 9 frontend from production' against 'Sprint 10 backend from stage' (don't know why we need to do this. Won't they just get backend frontend 10 and backend 10 altogether)

Answer 1

also test 'Sprint 9 frontend from production' against 'Sprint 10 backend from stage'

This is an important test case if you want to decouple the frontend and backend deployments which is necessary if you want to perform rolling deployments (i.e. deploying sprint 10 backend incrementally without downtime). Typically you deploy the backend first, so if you deploy spring 10 backend to production, it will temporarily be a mixture of spring 9's frontend and spring 10's backend until the sprint 10 frontend is deployed to production. Therefore you need to test this case.

Won't they just get backend frontend 10 and backend 10 altogether?

You could deploy backend and frontend together, but it would result in downtime for the user equivalent to stopping all frontend and backend servers, deploying sprint 10 artifacts, and starting frontend and backend servers.

What happens if the backend of sprint 10 can't support sprint 9 frontend?

This should only be the case if your sprint 10 backend changes have broken the interface. For example you decide to remove an API method from the backend, or you change the object model in a breaking way. In this case you have some options:

• Change the frontend or backend to be compatible with both versions 9 and 10. If you removed a method from the API in backend 10, you could remove the functionality from the frontend first (in 9.1 say), deploy it, and then deploy your new backend. Or you could add something in the backend temporarily to support both frontend versions. The compatibility code can be removed once frontend and backend are on the same version.
• Take the downtime and deploy the frontend and backend at the same time.

• Honey: What happens if the backend of sprint 10 can't serve sprint 9 frontend ie they are somewhat incompatible? Or I guess this when you have to add sprint-specific headers and then later correct those headers?
• bdsl: @Honey then you can either consider that a bug and fix it, or avoid deploying those two artefacts together.
• bdsl: Potentially you could deploy the new front end and backend together beside the old front end and backend, and then re-route the traffic to the new system instead of the old. That needn't involve downtime.
• Samuel: @Honey I've edited my question
• Honey: Thinking about this I guess a major reason would be that some users might not want to download the newer version of your app. Yet your background has to be compatible with them as well...