Like any recipe, you can tweak this for your own situation.
First, you need a shared test environment to work in. I recommend beginning with a persistent test environment intended to model your production environment as closely as possible. While you may eventually evolve the ability to share a test environment with commonly-configured VMs or containers, having a persistent shared test environment at the beginning gives everyone the experience of keeping something running that looks a lot like the production system. (TOAD! DevOps!) For that matter, proper use of feature flags and such could make production itself a perfectly fine shared test environment. Sharing the responsibility of keeping the shared test environment up and running and valuable is a big part of understanding the value of the recipe.
Second, you need some end-to-end tests (Testing!) to run against the shared test environment. You need to set up test data, tear down test data, type the typies and click the clickies in the UI to use the data, figure out what to assert to make sure that you know that the system continues to work the way you expect. The tests themselves are not all that valuable right away-- the most important thing is that you emphasize the *design* of the end-to-end tests, and include everyone in the end-to-end test design process. How you "include everyone" might vary-- it may be as limited as asking questions of dev and ops (DevOps!) about how the data work, or how the UI is hooked up the API. Or it could be mob programming on the end-to-end tests. Your org is your org, but make sure to share the creating of the tests.
But you have to make sure to get code changes to the shared test environment right away in order to run your end-to-end tests against the changes. You need a deploy pipeline straight from the code repository to the test environment (DevOps!). Having built this, of course you could just as easily deploy straight to production, but that would be irresponsible. You need to monitor your test env (Observability!) and run your regression tests (Testing AND Observability!) before you commit to updating the production environment.
Over time your end-to-end tests, your test data schemes, your test environment monitoring become more valuable. You have well-designed tests with reporting schemes that tell you exactly what kind of problems you have as soon as you have them.
That is the recipe.
* Have a shared test environment
* Use that environment for deploying, testing, monitoring, and reporting
* Make it all better over time
First, you need a shared test environment to work in. I recommend beginning with a persistent test environment intended to model your production environment as closely as possible. While you may eventually evolve the ability to share a test environment with commonly-configured VMs or containers, having a persistent shared test environment at the beginning gives everyone the experience of keeping something running that looks a lot like the production system. (TOAD! DevOps!) For that matter, proper use of feature flags and such could make production itself a perfectly fine shared test environment. Sharing the responsibility of keeping the shared test environment up and running and valuable is a big part of understanding the value of the recipe.
Second, you need some end-to-end tests (Testing!) to run against the shared test environment. You need to set up test data, tear down test data, type the typies and click the clickies in the UI to use the data, figure out what to assert to make sure that you know that the system continues to work the way you expect. The tests themselves are not all that valuable right away-- the most important thing is that you emphasize the *design* of the end-to-end tests, and include everyone in the end-to-end test design process. How you "include everyone" might vary-- it may be as limited as asking questions of dev and ops (DevOps!) about how the data work, or how the UI is hooked up the API. Or it could be mob programming on the end-to-end tests. Your org is your org, but make sure to share the creating of the tests.
But you have to make sure to get code changes to the shared test environment right away in order to run your end-to-end tests against the changes. You need a deploy pipeline straight from the code repository to the test environment (DevOps!). Having built this, of course you could just as easily deploy straight to production, but that would be irresponsible. You need to monitor your test env (Observability!) and run your regression tests (Testing AND Observability!) before you commit to updating the production environment.
Over time your end-to-end tests, your test data schemes, your test environment monitoring become more valuable. You have well-designed tests with reporting schemes that tell you exactly what kind of problems you have as soon as you have them.
That is the recipe.
* Have a shared test environment
* Use that environment for deploying, testing, monitoring, and reporting
* Make it all better over time