Answers: <h3>A Sandbox could be part of the solution</h3>
  
  <p>To bring material to the subject you can check the questions with tag <a href="/questions/tagged/sandbox" class="post-tag" title="show questions tagged &#39;sandbox&#39;" rel="tag">sandbox</a> on <a href="https://meta.stackexchange.com/questions/tagged/sandbox">MetaSE</a>, there are <strong>sanboxes</strong> for:</p>
  
  <ul>
  <li>Q/A formatting.</li>
  <li>Comments formatting.</li>
  <li>Chat.</li>
  </ul>
  
  <p>There's a feature request about "<a href="https://meta.stackexchange.com/questions/62585/can-we-get-a-stack-exchange-sandbox">Can we get a Stack Exchange sandbox?</a>" which has no status (neither declined, pending, review nor in-progress meta-tag).</p>
  
  <p>So I assume the answer (to the specific sample in the question) is that there's no way to test out of real SE sites for now and my recommendation to SE would be to accept this feature request.</p>
  
  <h3>When is a sandbox appropriate?</h3>
  
  <p>I don't think it's always needed to give users a sandbox, and it can be overkill sometimes. Defects should be spotted on Q/A environments, and when they're not, well, either you can know there's a glitch by a fine monitoring of your logs, or you will just never know until someone tells you.</p>
  
  <h3>Sanboxes come at an additional cost</h3>
  
  <p>Even if you deploy a sandbox for your users to try and confirm a bug, nothing tells you they will inform you of a bug/problem and you had to go through adding a public environment with <strong>dummy or anonymised data</strong> with no idea of it's ROI.</p>
  
  <p>So It boils down to: "You can create a sandbox for your users but it adds complexity to your infrastructure for a hardly measured return"</p>
  
  <h3>Recommendation</h3>
  
  <p>My personal opinion would be to put the efforts in log analysis to spot unwanted behaviors instead.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-10T09:46:44.217Z
Answers: merci for this answer, for which part of it seems to me like an answer to a question like "where somewhere in SE-space can I do this kind of tests". Such question clearly belongs on a meta site. Good to know that part of the answer, but that's not "my" real question here. My question is summarized in my title, somehow rephrased near the end with the "Voilà ..." at the end. IMO the "sandbox" tag you used is the beginning of a possible answer. If I'd be your customer I'd probably say "hang on, I know that from when I was a child, what does that mean in a DevOps context"? Wanna retry?
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-10T10:03:13.097Z
Answers: Edited to be more precise on my position.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-10T10:21:36.633Z
Answers: Interesting update! and actually you hit a very important extra item that goes with such a sandbox thing: ***the data you'll need for such sandbox***. You mind if I slightly change the formatting of some words you used which IMO are extremely important in the context of answering my question? If you don't like my edits, just rollback afterwards ...
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-10T11:00:06.827Z
Answers: OK, your turn again ... feel free to further improve / expand if needed, or just a rollback if you don't like it at all ... Curious to see if none-sandbox related answers will be added later on ... BTW, maybe "you" should also answer that meta question, eventually with a link to around here, to include another example of why such sandbox sites could/should be used also ..; PS: just completed yet another test in production. The result of it is a brand new user that got registered to join the private DevOps party, So the scenario mentioned in my PS works as a charm!
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-10T11:12:18.913Z
Answers: @Pierre.Vriens sounds ok, but I'm not sure of what you mean could/should (and for the new user, as already said, it's expected, the only thing blocked is direct access to `http://devops.stackechange.com` when you're not registered, passing though the area51 link works)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-10T08:53:28.863Z
Answers: 2017-03-10T10:58:42.483Z
Answers: 2017-03-10T10:58:42.483Z
Answers: Tensibai
Body: <p>When configuring test environments, the issue often comes up where I ask the question to the customer like in my question title here:</p>
  
  <blockquote>
    <p><strong>How to avoid a regular user can only test in production?</strong></p>
  </blockquote>
  
  <p>There are typically the environments like unit test, system test, integration test, volume test, user acceptance test, etc (I bet there are yet another dozen of names like those). But they all relate to environments in which something differs from how things currently work in the real production environments. So none of these is what my question is about.</p>
  
  <p>To make this a less abstract question, consider this sample below:</p>
  
  <blockquote>
    <p>Can non-SE employees only test SE sites in production?</p>
  </blockquote>
  
  <p>I run into this scenario over and over (earlier today it happened again ...):</p>
  
  <ul>
  <li>I discover some facility on an SE site that gets my attention (that I want to start using).</li>
  <li>I start looking around in help pages, etc, and either don't find what I'm looking for, or what I find is not 100 accurate or clear to me.</li>
  <li>I just try to start to use it, see what happens, hoping I will find the answer to what I couldn't find in the help pages (by just using that facility in some SE site ... read: by <strong><em>testing in production</em></strong>).</li>
  <li>I then just wait and see what happens, which may be things like:
  
  <ul>
  <li>I learn about something new/interesting and it works great.</li>
  <li>I get accused of trying to "fuzzle the system".</li>
  <li>I get corrected by a mod because of something I did (which I shouldn't have done).</li>
  <li>I discover a bug, which I either report (on meta.SE), or which I decide to consider as "a bug becomes a feature" (read: I don't want to disclose this handy feature).</li>
  </ul></li>
  </ul>
  
  <p>However, doing some of those "experiments in production" may damage your reputation (not really your "points", but your real reputation).</p>
  
  <p>So as a good SE citizens, I would be happy to do those experiments in an environment that is designed <em>just for that</em>: a none-production environment designed for users like me who want to do such experiments.</p>
  
  <p>Voilà, if you were asked to configure test environments for SE sites, what would you do (or recommend SE management) about this DevOps issue?</p>
  
  <p>PS: to my knowledge, at this very moment, there is no such SE environment that I can use right now to go check if a user that I "invite right now" for DevOps (while it is in private beta), and which I know did NOT commit to DevOps, will actually be able to login to the DevOps site. So instead of discussing it with mods on some other site, I already ... <strong><em>tested it in production</em></strong>. And despite what some moderator try to make me believe ... it did work (and the invited user now also has an account on DevOps.SE).</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-10T08:46:04.000Z
Comments: If you're talking about the private beta not being really private, well it's documented [here](https://meta.stackexchange.com/a/212239/287976) (This doesn't answer the overall question about test in prod, but this sched some ligths)
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-10T09:06:54.630Z
Comments: This question could use some linguistic editing. I find it hard to understand.
Comments: Assaf Lavie
Comments: CC BY-SA 3.0
Comments: 2017-03-10T09:29:42.520Z
Comments: @AssafLavie : feel free to edit my question. I'll review it afterwards, and either (a) accept or (b) improve (pretty sure no rollback), ok? If you do, make sure I don't need a dictionary to understand words that are a bit tougher to know/learn if English is not the language you learned on your mother's knees (Dutch shouldn't be any problem for me though).
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-10T09:37:08.957Z
Comments: I'm afraid I can't really help because I don't understand the question.
Comments: Assaf Lavie
Comments: CC BY-SA 3.0
Comments: 2017-03-10T09:49:31.463Z
Comments: @AssafLavie now I'm a bit confused what you wanted to say with "linguistic" in your first comment (I though it was about typos / grammar errors I made). Can you check my comment below the existing answer, does that help "you" somehow also?
Comments: Pierre.Vriens
Tags: <testing><scm>
Title: How to avoid a regular user can only test in production?
UserDisplayName: Pierre.Vriens
ThreadText: # How to avoid a regular user can only test in production?
  
  (Asked by: username_0 on 2017-03-10)
  
  When configuring test environments, the issue often comes up where I ask the question to the customer like in my question title here:
  
  > **How to avoid a regular user can only test in production?**
  
  There are typically the environments like unit test, system test, integration test, volume test, user acceptance test, etc (I bet there are yet another dozen of names like those). But they all relate to environments in which something differs from how things currently work in the real production environments. So none of these is what my question is about.
  
  To make this a less abstract question, consider this sample below:
  
  > Can non-SE employees only test SE sites in production?
  
  I run into this scenario over and over (earlier today it happened again ...):
  
  * I discover some facility on an SE site that gets my attention (that I want to start using).
  * I start looking around in help pages, etc, and either don't find what I'm looking for, or what I find is not 100 accurate or clear to me.
  * I just try to start to use it, see what happens, hoping I will find the answer to what I couldn't find in the help pages (by just using that facility in some SE site ... read: by ***testing in production***).
  * I then just wait and see what happens, which may be things like:
    + I learn about something new/interesting and it works great.
    + I get accused of trying to "fuzzle the system".
    + I get corrected by a mod because of something I did (which I shouldn't have done).
    + I discover a bug, which I either report (on meta.SE), or which I decide to consider as "a bug becomes a feature" (read: I don't want to disclose this handy feature).
  
  However, doing some of those "experiments in production" may damage your reputation (not really your "points", but your real reputation).
  
  So as a good SE citizens, I would be happy to do those experiments in an environment that is designed *just for that*: a none-production environment designed for users like me who want to do such experiments.
  
  Voilà, if you were asked to configure test environments for SE sites, what would you do (or recommend SE management) about this DevOps issue?
  
  PS: to my knowledge, at this very moment, there is no such SE environment that I can use right now to go check if a user that I "invite right now" for DevOps (while it is in private beta), and which I know did NOT commit to DevOps, will actually be able to login to the DevOps site. So instead of discussing it with mods on some other site, I already ... ***tested it in production***. And despite what some moderator try to make me believe ... it did work (and the invited user now also has an account on DevOps.SE).
  
  **Tags:** testing, scm
  
  > **Comments:**
  > **username_1**: If you're talking about the private beta not being really private, well it's documented [here](https://meta.stackexchange.com/a/212239/287976) (This doesn't answer the overall question about test in prod, but this sched some ligths)  
  > **username_2**: This question could use some linguistic editing. I find it hard to understand.  
  > **username_0**: @username_2 : feel free to edit my question. I'll review it afterwards, and either (a) accept or (b) improve (pretty sure no rollback), ok? If you do, make sure I don't need a dictionary to understand words that are a bit tougher to know/learn if English is not the language you learned on your mother's knees (Dutch shouldn't be any problem for me though).  
  > **username_2**: I'm afraid I can't really help because I don't understand the question.  
  > **username_0**: @username_2 now I'm a bit confused what you wanted to say with "linguistic" in your first comment (I though it was about typos / grammar errors I made). Can you check my comment below the existing answer, does that help "you" somehow also?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-03-10. Score: 6
  
  ### A Sandbox could be part of the solution
  
  To bring material to the subject you can check the questions with tag [sandbox](/questions/tagged/sandbox "show questions tagged 'sandbox'") on [MetaSE](https://meta.stackexchange.com/questions/tagged/sandbox), there are **sanboxes** for:
  
  * Q/A formatting.
  * Comments formatting.
  * Chat.
  
  There's a feature request about "[Can we get a Stack Exchange sandbox?](https://meta.stackexchange.com/questions/62585/can-we-get-a-stack-exchange-sandbox)" which has no status (neither declined, pending, review nor in-progress meta-tag).
  
  So I assume the answer (to the specific sample in the question) is that there's no way to test out of real SE sites for now and my recommendation to SE would be to accept this feature request.
  
  ### When is a sandbox appropriate?
  
  I don't think it's always needed to give users a sandbox, and it can be overkill sometimes. Defects should be spotted on Q/A environments, and when they're not, well, either you can know there's a glitch by a fine monitoring of your logs, or you will just never know until someone tells you.
  
  ### Sanboxes come at an additional cost
  
  Even if you deploy a sandbox for your users to try and confirm a bug, nothing tells you they will inform you of a bug/problem and you had to go through adding a public environment with **dummy or anonymised data** with no idea of it's ROI.
  
  So It boils down to: "You can create a sandbox for your users but it adds complexity to your infrastructure for a hardly measured return"
  
  ### Recommendation
  
  My personal opinion would be to put the efforts in log analysis to spot unwanted behaviors instead.
  
  > **Comments:**
  > **username_0**: merci for this answer, for which part of it seems to me like an answer to a question like "where somewhere in SE-space can I do this kind of tests". Such question clearly belongs on a meta site. Good to know that part of the answer, but that's not "my" real question here. My question is summarized in my title, somehow rephrased near the end with the "Voilà ..." at the end. IMO the "sandbox" tag you used is the beginning of a possible answer. If I'd be your customer I'd probably say "hang on, I know that from when I was a child, what does that mean in a DevOps context"? Wanna retry?  
  > **username_1**: Edited to be more precise on my position.  
  > **username_0**: Interesting update! and actually you hit a very important extra item that goes with such a sandbox thing: ***the data you'll need for such sandbox***. You mind if I slightly change the formatting of some words you used which IMO are extremely important in the context of answering my question? If you don't like my edits, just rollback afterwards ...  
  > **username_0**: OK, your turn again ... feel free to further improve / expand if needed, or just a rollback if you don't like it at all ... Curious to see if none-sandbox related answers will be added later on ... BTW, maybe "you" should also answer that meta question, eventually with a link to around here, to include another example of why such sandbox sites could/should be used also ..; PS: just completed yet another test in production. The result of it is a brand new user that got registered to join the private DevOps party, So the scenario mentioned in my PS works as a charm!  
  > **username_1**: @username_0 sounds ok, but I'm not sure of what you mean could/should (and for the new user, as already said, it's expected, the only thing blocked is direct access to `http://devops.stackechange.com` when you're not registered, passing though the area51 link works)  
  
  ---
  
  