5

I'm wanting to test out a few new pages and have just a small set of beta testing users be able to access them before I allow them to go live to the rest of the site. What I've typically done is created pages with no links and just give those URLs to users to try out to give feedback. This has worked great for just text articles for proofreading. However, I'm about to install a chat plugin and there's no way to test this on a localhost install and test it effectively.

The way I do functionality improvements now is to have my beta testers ready, install the plugin live, and then test/coordinate this as quickly as possible so it can be removed if it functions poorly or allowed to stay live. This is crazy stressful to me.

I've thought of ideas like buying a garbage test domain (www.asfdsjkfsda.com), and cloning my site to it, and then allowing testing there. Effective/clever or not, it still seems like a ridiculous idea.

Is there a better way to test new functionality for a beta group? Is this really the way things are done?

Tony DiNitto
  • 797
  • 1
  • 5
  • 18
  • I could suggest using a robot in the chat system as the other user but I don't know if your chat system supports it. Probably a garbage domain is best, but I'm curious as to any amazing answer one would provide to this. – Mike -- No longer here Jun 13 '16 at 18:39
  • Yeah, I brought up the chat situation just to avoid the "Why would you ever want to do this? What are you trying to accomplish?" type responses. But there's probably a long list of reasons one would want to do this. I'd just be in disbelief that my idea of creating an garbage domain would really be the best solution. – Tony DiNitto Jun 13 '16 at 20:39
  • 1
    I often test new ideas on a temporary system and give people access to that. The idea is not to effect the live system. You do not have to have a garbage domain, you can certainly use a sub-domain to point to your temporary server. An old desktop should do or a temporary hosting space. When done and satisfied, just kill the sub-domain and port over the work you have done on the sub-domain to the live server. Simple. (I hope.) Cheers!! – closetnoc Jun 14 '16 at 03:27
  • @closetnoc If you wanted to elaborate a bit on how you might set up this temp hosting space (which sounds like an inexpensive way to avoid hosting and garbage domains, but performing the same basic functionality of that), then that answer probably probably would be helpful and be accepted. Thx! – Tony DiNitto Jun 15 '16 at 18:46

3 Answers3

3

Personally, I utilize my database's users table.

#    fname    lname        email                beta_access       username    [...]
1    James    Doe          jdoe@email.com       true              jdoe
2    Sally    Jones        sj@aol.com           true              sjones
3    Alex     Jennings     aj123@yahoo.com      false             ajennings

Using the above example, there are three random users. In your code, you can simply have an if statement to represent beta_access = true. If true, show beta code. If false, do not.

A second method, which I have done on larger sites, is to have a unique ID in the beta_access column. For example:

#    [...]   beta_access    [...]
1            14573
2            57232
3            14573
4            [null]

This way, you can have multiple things you'd like tested at once, but not grant access to each for all users with beta access. Live chat might be represented by 14573, whereas a new contact form UI might be represented by 57232. This is a bit overboard for simple applications, but is quite useful for larger sites.

zrosen
  • 31
  • 2
0

Website Staging:

If you're trying to do a major redesign on a site and/or trying to roll out other functions seamlessly without the down time associated with page by page updating, the most common and efficient strategy is called website staging.

Instead of trying to coordinate a time sensitive roll out of having a test user come onto a page at the exact moment you update a page's function / design would be not only stressful and inefficient, it also doesn't allow for appropriate time to test without major risk of bugs / downtime.

There are 2 common forms of website staging:

1) Localhost / offline staging - This is where you set up a local server on your home computer that only you can access and spend time developing. However, this is not as useful when you want to test functionality based on user interaction (such a chat app).

2) Online Staging / Subdomain - This is where you can mirror (ie. duplicate) your site to a subdomain address (eg. www.Testing.Example.com). Then you can do your development there, and have users that you want to have test it out in an online / live type of environment.

Migration:

When everything is perfect and good to go, you can migrate from either the localhost or the mirrored subdomain very rapidly rather than trying to manually update each page rapidly and/or having to go into an environment that requires strategies such as passwords for specific users.

Associated Costs:

Most of the time both local and online staging methods are free.

XAMPP is a commonly used local web server that's mostly free. And if you have access to cPanel, many hosts basic hosting packages will allow for subdomain creation.

Finally, while the process can be fairly technical with either method you use, WordPress has numerous plugins that will simplify website staging.

Tony DiNitto
  • 797
  • 1
  • 5
  • 18
0

I would assume users have to login. Use their id after login to only allow your beta testers on those pages you are testing. If they don't have to login, you could still make a quick login gateway for your pages that need testing.

psuedo code

If(loginID == "..." or loginID=="..." or loginID=="...")
{
let them in
}
else
{
send them elsewhere
}

or

if(password !="motorcycleMama")
{
send them elswewhere
}

This is how I would do it for your specific example.

JustJohn
  • 181
  • 3