4

Okay, we have a major release coming next week. So, I would like to know if this a good/best practice:

After the successful deployment using Change sets, some other manual deploying steps(sObject's standard picklist value changes) and activating automation flows, is it okay to create Test record data on the Production org to see if all the features/functionalities are functioning as expected?

Scenario: We had a twelve sprint(24 weeks) worth of development with around 15 user stories on a single Visualforce page(external site) which creates Case record on a successful submission. Thus our QA had some use cases for each story which he used to test when each story is in Ready for Testing. All of them were passed without any issues.

Questions:

  1. Is it okay to create test data on the Production org after the successful release and later delete those records?
  2. Is this a good practice to test all the use cases on the Production org from all the development stories?
  3. Or, we should just deploy and smoke test(just make sure everything deployed successfully, look/feel of the UI) the complete feature and leave it for the end-users to get back to us with their feedback?

Note: We had tested all use cases on the Staging org already. So this deployment is going to be from the Staging to the Production org respectively. Also, I will be considering to Delete the test data after all the successful testing on Prod.

Any best practices/methods/considerations are welcome.

11

No, QA testing should never be done in a production environment. It is not best practice to do so.

However, if you need to do a small test just to confirm that everything you needed to deploy was properly deployed and assigned, then yes, it is ok to create some "junk data" as long as you delete it right after the tests are finished, and you make sure they are not mixed with production data (that includes integration with external systems and outbound emails).

  • 1
    Also not synced to external parties (specially billing), not fire any emails to real customers, not being shown to community users and so on. Answer should be just a first sentence (from my bitter experience). – kurunve Jul 19 '18 at 18:42
  • @kurunve Sure, I would like to know more people's opinions. Because, experience is the only good source for quality productivity. – Arnold Jr. Jul 19 '18 at 18:46
5

Adding on top of what has already been answered by Renato, here’s how I have usually approached and am trying to answer specifically on your questions.

  1. Is it okay to create test data on the Production org after the successful release and later delete those records?

Yes. You can absolutely create test data in a Production org and as you already mentioned, just delete those before you handover the system to Business Users. Be careful though while creating test data and always review what impacts it may have from any process perspective as triggering emails, sending events for integration, etc.

  1. Is this a good practice to test all the use cases on the Production org from all the development stories?

No. This goes back to what Renato mentioned. Testing all use cases are always part of QA/UAT and you don’t “usually” do that on Production. Consider this - will you even have time for it? A QA/UAT cycle goes through a fixed timeline in any SDLC, and that if you plan to test all use cases in Prod, you definitely don’t have that much time!

  1. Or, we should just deploy and smoke test(just make sure everything deployed successfully, look/feel of the UI) the complete feature and leave it for the end-users to get back to us with their feedback?

Yes. You should definitely have a sanity/smoke suite created so that you can verify the most important features/functionalities of your hard built system.


In general, make sure you always perform a deployment validation after every release.

2

A further addition:

Part of this depends on ownership and responsibility within the business. If you work for a consultancy, then you may or may not own the whole process of deployment and testing. You may or may not have the final responsibility for deliverables.

If you own everything, then I'd agree: no test records in production would be preferable.

If not (e.g. you're a consulting partner working with an end-user who has their own Salesforce team), then that team may have a use for test records which actually live in production. In which case, you could bake test data into your design e.g. if a record is flagged as test, we do everything up to the point of calling an external system; we don't include them in financial reporting etc.

As a consulting partner, I'd say that pretty much every org I've ever seen has test data in it, created by the business. So, sometimes, it's best to give them a path to create that data well, so that it doesn't lead to wonky accounting results or other undesirable results. If you do that, then it also give you a legitimate way to do some sanity checking of your deployment in production.

0

It is not OK to create Test Data in Production based on the scenario you mentioned. Your final test should be performed in Full Sandbox environment which will give you similar experience as if you did in Production. Starting listing down the thought, problem, reasoning why you want test data in production and resolve those one by one. I think you will be able to get through testing through Full Sandbox environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.