Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
I found an article with regards to the different types of salesforce sandboxes. I was wondering if you have used the full sandbox and can also share your feedback in the following features. What are the purpose of those features?:
Performance testing is almost worthless. In my experience all sandboxes perform slower than production environments.
You can do load testing on a regular developer sandbox, records created in a test are not counted towards limits.
Staging should only really be done in a full sandbox. That's the only way you can be absolutely certain that your code isn't going to run into interesting edge cases that you haven't thought of with the full set of user data. It's also the best way to make sure that code being developed in multiple developer sandboxes integrates properly.
It depends on the needs of your client. Depending on the complexity of your organization, it could be interesting to have such a Sandbox or not.
If you just want to test some bulk loads, or similar. You can get away with just a Partial Copy since you can load as many records as you want even though you the docs say you can't. The main issue with a Partial Copy sandbox is that the record-copying algorithm is broken and you will find yourself with inconsistent data on many occasions (Like having a Campaign Member without Contact/Lead).
On the other hand, if you need to actually test functionality against the whole dataset your client has, then you will need such a Sandbox. It's useful for detecting Governor Limit violations. For example, we have a very heavy duplicate management functionality coded with Apex in our organization and if we had not run it in such a Sandbox we would've never got the CPULimitException until it had reached production.
But just like I said at the start of the answer, it's very dependant on the size and complexity of your org. For 90% of the client's I've worked in, I can say they didn't need one.
I think it is almost mandatory when considering batches. Got a bad surprise recently when testing a layer of scheduled batches on a partial that ran extremly smoothly with max batch volumes and threw dml errors in production and it is still in production, working but not perfectly. Sometimes you don't have access to the exact state of production as you developp things and you are given some bad infos on some cases/volumes.
On ETL things it's another story because imho it is done poorly most of the time, but if you want to make salesforce launch everything as much as possible(as you should for data integrity) it may really make sense too.
Full sandbox also can make testing easier for users that work on the prod on a daily basis, for example when they know that there is a record perfect for their test case.
Case where it doesn't matter: new org, orgs with few data, or orgs with little automation and logic(triggers, pbs, vrs).
