A welcome change of recent is the introduction of the Release Candidate (RC) into the new release cycle for DNN Platform.  Having early access to an upcoming RC gives everyone valuable insight into what is coming in the official release.  Not only do we get a chance to learn and prepare for use of the new version within our own test environments and those of our clients, but we also have a chance to participate in community-wide testing and provide valuable feedback.  This is an area in which the Leadership Team could really use your help.  The more people that test each Release Candidate, the greater the stability and quality of the platform.

The good news is you do not need to be a developer in order to help in this area.  Below I am going to describe a few simple steps that will help cover great testing ground, and it won't take much of your time to do it either.  Along the way, you'll be brought up to speed with the "latest and greatest" bug fixes, enhancements, and new DNN features.  You'll also help make the platform better for all by taking a few minutes to provide valuable feedback.

How Can I Help?

Step 1

Stay tuned to the Community Blog.  Here, a member of the Technology EAG will post when a Release Candidate is available and ready for testing.  There will also be a link provided for posting your testing results.  As of the writing of this blog, the last method used was a Google Form, but the medium by which we collect test results may change in the future.
 

STEP 2

Go to the provided GitHub link within the blog referenced in STEP 1.  It will take you a page similar to this one for Release Candidate (RC) 9.2.2.  Here, you will find Release Notes that may contain specific instructions for testing.  You will see a link to all the Pull Requests (GitHub terminology for proposed/merged code changes) for this RC.  More about this in STEP 3.  

The major highlight changes will be listed as Changes bullet points within the Release Notes.  Each change item usually links to the appropriate pull request(s) for that specific change.  Each pull request usually references a corresponding Issue (GitHub terminology for a bug, enhancement, feature request, question, etc.) where the details leading to the pull request was initially posted.

The contributor(s) for each change, including ones that are not explicitly highlighted, are also listed. 
 

STEP 3 (optional)

If you'd like to dig into these for specific Pull Requests relevant to your planned testing, you absolutely can.  That way you will gain insight into how the Issue was addressed by the contributor(s) and what conversations may have gone on between various community members during the process of accepting each pull request.  However, this is not required for basic testing.  

By the way, DNN Platform is on GitHub as open-source software for a reason.  Transparency is core to the open-source way of life.  You don't have to be a developer to get involved in the conversations on GitHub.  Everyone's opinion matters!  So, don't be intimidated by the DNN "heavy hitters" - get involved in the conversation.  The DNN Community, like every large community, has its share of "bad apples in the bunch", but for the most part, you will find this a very welcoming and respectful group of people.  Even if you do run into an unexpected "encounter", your opinion still matters!  ;-)
 

STEP 4

Download the appropriate DNN Platform package (ZIP file), which contains "Install" in the file name.
 

STEP 5

Install DNN on your local machine.  My preferred method is to use nvQuickSite (less than a minute to install), but there are plenty of resources out there to help you if you prefer to do it manually.  The thing we are looking for in this step is whether or not the actual DNN installation was successful.  Whether you use nvQuickSite or install manually, you will eventually see the DNN installation "wizard" in the browser window.  Do any errors show during or after the installation?  If so, make note of them and report them accordingly.
 

STEP 6

Add a new page to the test site.  Did it work as you would expect?  Did you notice anything out of sorts or any unexpected behavior?  If so, make note of the issues and report them accordingly.
 

STEP 7

Add a module to a page.  Did it work as you would expect?  Did you notice any issues?  If so, make note of them and report them accordingly.
 

STEP 8

Create a new user.  Did it work as you would expect?  Did you notice any issues?  If so, make note of them and report them accordingly.
 

STEP 9

Reset the user's password.  Did it work as you would expect?  Did you notice any issues?  If so, make note of them and report them accordingly.
 

STEP 10

Install a new and older version of DNN locally (again, nvQuickSite makes this super easy without the need to manually download that version from GitHub).  Then attempt to upgrade to the RC version of DNN using the "Upgrade" package.  I won't go into specifics on how to perform a DNN upgrade, as there are many resources out there to guide you through this step, but in short you simply UNZIP the contents of the "Upgrade" package into the root of the older version of DNN and attempt to visit the site URL again.  This should kick off the upgrade "wizard".

Did the upgrade go as you would expect?  Did you notice any errors or issues with the upgrade?  If so, please make note of them and report them accordingly.
 

Conclusion

And there you have it!  By performing the above simple steps, you will be "touching" many major areas of functionality within DNN.  And this testing feedback is vital to the continued success of DNN Platform and its stability.

You may find additional testing guidance within further RC testing online surveys.  While we would certainly appreciate more thorough testing, please know that having more people perform at least the above simple steps will help tremendously.

If you have questions about this, please feel free to comment below.  I or another member of the Technology Ecosystem Advisory Group would be happy to help.  

Happy Testing Everyone!