Automated testing is to flush out, under controlled conditions, any problem that the system will have in production, we need to debate how much effort is required or if is it feasible to mimic the prod setup, Use the same database software, with the same versions, use the same version of the operating system, P_ut all the appropriate libraries that are in the production environment into the test environment_, Virtual environments make it much easier than it was in the past, today we can run production software in containers, and reliably build exactly the same containers for testing, even in a developer's workspace. It's worth the effort and cost to do this, the price is usually small compared to hunting down a single bug, but in some or most cases software is designed to run on multiple environments such as different operating systems and platform versions, if that's the case deployment pipeline should arrange for testing in all of these environments in parallel. I believe if the platform supports container-based workloads, you are mostly covered, but you need to define the org's permission model and strategies, what input went in, and what's crucial in mimicking the env, and as you move along you may define the standard template for cross-cutting concerns.