In most of our upgrade/downgrade tests, we perform FCV upgrades only on the latest binary. The tests start with the latest binary, then downgrade FCV, and later upgrade it again. However, this doesn't fully mimic the production scenario where we begin with a downgraded binary and FCV, then upgrade the binary, followed by an FCV upgrade.

This ticket aims to investigate whether there is a gap in our testing approach and if it's necessary to adjust our testing to better align with production scenarios.
 
There are two general types of tests, the general passthrough tests, and more targeted feature tests.
For general tests, there are phases of this upgrade process
1. All nodes on the downgraded binary - we test this through the last-lts/last-continuous passthroughs on evergreen (add example link)
2. Swap nodes one by one to the upgraded binary - we test each state of this through our multiversion passthroughs that have some nodes on the old binary and some on new (example: https://github.com/10gen/mongo/blob/4f48791a9a805a0384070ee2d016e35ae7630d1e/buildscripts/resmokeconfig/matrix_suites/generated_suites/sharding_jscore_passthrough_last_lts_new_old_old_new.yml)
3. FCV upgrade - this is tested in the fcv_upgrade_downgrade_jscore_passthrough suite

So we do mostly test each individual state of this process, but not the whole process together, and not the specific step of swapping the binaries. We should investigate if it is actually worth it to test the whole process and/or the specific step of swapping the binaries.

However, for targeted feature tests, each feature should still add tests to test the full upgrade (starting on downgraded binary -> swap to upgraded binary, do appropriate feature testing -> upgrade FCV, do appropriate feature testing).

We currently have an automated ticket in each project that talks about FCV testing, but we could add language in this around full testing the binary upgrade and then FCV upgrade. We also have this example test that we could point to. In addition we could add more info in the README about this.
Example of automated ticket in each project: SERVER-80086.