Answers.Body: <p>I strongly prefer the approach of having a $1 membership type set up, and testing it with real cards and real money. For $2-3 I get full piece of mind that things are working. I generally only need to know it is working on one Contribution page to give me confidence that it will be working on all pages using the same Payment Processor.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-13T23:50:53.150Z
Answers.LastActivityDate: 2017-03-13T23:50:53.150Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>I'm pretty new to the CiviCRM world and am just finishing my first project using it. We are now in the process of making sure that our membership signup procedure (with contributions) works well. As I see it there are a couple of ways to increase the chance that we will have a high quality in this part of our system:</p>
  
  <ol>
  <li>We can communicate with users who have used the live system</li>
  <li>We can carefully monitor the stats for new users</li>
  <li>We can run tests ourselves</li>
  </ol>
  
  <p><em>For the tests</em> I see several possible ways, for example we can <em>use the payment processor that we are using for the live payments but instead run it in test mode</em> ("preview" in the url params). KarinG suggested in her answer to <a href="https://civicrm.stackexchange.com/questions/17504/error-message-when-testing-memberships-expected-one-paymentprocessor-but-found">this question</a> that we create a new payment processor and run it in <em>live mode</em> but with <em>test credentials</em>. Also there is the <em>"dummy payment processor"</em> which seems to be recommended in the CiviCRM user guide ("For the purposed of testing, you can configure dummy payment processors.")</p>
  
  <p><strong>How do we (in general) ensure that our donation procedure is working well?</strong> And a more specific question: <strong>Which of the options above (dummy payment processor etc) is the best way to test a membership system?</strong></p>
  
  <p>Grateful for help and with kind regards,
  Tord</p>
  
Tags: <civicontribute><civimember><payment-processor><testing>
Title: Quality assurance considerations for membership signups
ThreadText: # Quality assurance considerations for membership signups
  
  (Asked by: username_0 on 2017-03-13)
  
  I'm pretty new to the CiviCRM world and am just finishing my first project using it. We are now in the process of making sure that our membership signup procedure (with contributions) works well. As I see it there are a couple of ways to increase the chance that we will have a high quality in this part of our system:
  
  1. We can communicate with users who have used the live system
  2. We can carefully monitor the stats for new users
  3. We can run tests ourselves
  
  *For the tests* I see several possible ways, for example we can *use the payment processor that we are using for the live payments but instead run it in test mode* ("preview" in the url params). KarinG suggested in her answer to [this question](https://civicrm.stackexchange.com/questions/17504/error-message-when-testing-memberships-expected-one-paymentprocessor-but-found) that we create a new payment processor and run it in *live mode* but with *test credentials*. Also there is the *"dummy payment processor"* which seems to be recommended in the CiviCRM user guide ("For the purposed of testing, you can configure dummy payment processors.")
  
  **How do we (in general) ensure that our donation procedure is working well?** And a more specific question: **Which of the options above (dummy payment processor etc) is the best way to test a membership system?**
  
  Grateful for help and with kind regards,
  Tord
  
  **Tags:** civicontribute, civimember, payment-processor, testing
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-03-13. Score: 3
  
  I strongly prefer the approach of having a $1 membership type set up, and testing it with real cards and real money. For $2-3 I get full piece of mind that things are working. I generally only need to know it is working on one Contribution page to give me confidence that it will be working on all pages using the same Payment Processor.
  
  
  ---
  
  