![\"Guide](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/image1.jpg\")
<\/p>\nAs you build the product, it\u2019s important to test internally and externally to get out of the development bubble. Dogfooding is a quick internal sanity check that ensures the product team stays empathetic to users. On the other hand, beta testing can be more in-depth since it is the last comprehensive user review of your product before you hand it off to be shipped. In this piece, we\u2019ll discuss helpful processes and documents to use for both types of testing.<\/p>\n
<\/p>\n
Once you\u2019ve iterated your product to the point where it’s usable, testing it with your team is a great low-cost (or no-cost) reality check.<\/p>\n
<\/p>\n
Since the cost of defects increases the longer they stay in the codebase<\/a>, this feedback loop \u2014 known as dogfooding, alpha testing, or user acceptance testing \u2014 might even get you some net gains. The importance of dogfooding might best be understood by what happens when you don\u2019t do it. For example, part of Facebook Home\u2019s failure was that its product team used mostly iPhones<\/a> while the product was based on Android. As a result, the team left out important widgets, docks, and app folders needed by Android users.<\/p>\n At <\/i>UXPin<\/i><\/a>, we eat our own dogfood. We use JIRA to keep track of bugs and a highly organized Google Docs spreadsheet for each team member to create a \u201cuser diary\u201d of good experiences, annoyances, and times to complete certain tasks. We also use UXPin to prototype new iterations of UXPin (a very meta UX design process). \u00a0\u00a0<\/i><\/p>\n Compared to earlier phases, the main difference is that dogfooding may not be done in as controlled a setting. Bug tracking software, user diaries, and alpha test surveys are all great for capturing feedback in this looser environment.<\/p>\n 1. Bug Tracking Software<\/b><\/p>\n Most of the data you\u2019ll get during dogfooding will likely be bug reports. While we\u2019ve talked about the project tracking capability of JIRA, it truly shines at allowing for easy visibility and collaboration when documenting and squashing bugs.<\/p>\n 2. User Diary <\/b><\/p>\n As we described in The Guide to Usability Testing, user diaries are great at capturing organic information as someone uses the product freely. Using Google Docs, you can create a simple template and then include open-ended prompts such as:<\/p>\n 3. Alpha Test Survey<\/b><\/p>\n Using a free site like Survey Monkey<\/a>, you can create a survey to gauge how team members feel about the usability and functionality of certain features and the product as a whole. This sample survey<\/a> captures both qualitative and quantitative information.<\/p>\n According to Luke Freiler, CEO of beta testing company Centercode, <\/b>the goal of an alpha test is to find bugs, crashes, and missing features<\/a> so tailor your survey questions accordingly. The qualitative and quantitative data from an alpha test will also set the benchmarks for the product and emulate testing done with ~80% of real users.<\/p>\n Now that you\u2019ve fed the dogfood to your own team, it\u2019s time to try it with real users in a beta test.<\/p>\n Unlike an alpha test which is designed to improve product quality, a beta test is designed to incorporate customer feedback into the product.<\/p>\n As we described in our Guide to Minimum Viable Products<\/a>, logging and then acting on customer feedback is one of the lowest-cost ways to prevent feature bloat. Since some bugs may still be discovered since alpha testing won\u2019t cover all edge cases, JIRA can still come in handy for documentation. Similarly, the surveys you ran during internal testing can also be adapted for real users. Below, we\u2019ll look at how other tactics like beta selection criteria, qualification surveys, and user forums can supplement your beta test.<\/p>\n 1. Beta Selection Criteria<\/b><\/p>\n Before finding applicants, it\u2019s important to prioritize the must-have qualifications, the nice-to-have qualifications, and subjective qualifications for testers. This will help you form a \u201cscorecard\u201d which you can use to filter applicants after they complete your qualification survey. Centercode has a simple selection checklist in their Beta Recruitment Kit<\/a> to get you started.<\/p>\n 2. Beta Qualification Survey <\/b><\/p>\n Whether your beta test is public or private, you will want a send a survey to potential testers to ensure they fit the user profiles outlined in your PRD. Centercode\u2019s <\/b>Beta Recruitment Kit<\/a> also contains a quick qualification worksheet survey which you can then translate into a live survey on Survey Monkey. You can also reference this live example from McAfee<\/a> or the sample below.<\/p>\n In our Guide to UX Design & Process Documentation<\/i><\/a>, <\/i>we also explain how to create different surveys to improve your product after launching.<\/p>\n <\/p>\n 3. Beta Testing Forums <\/b><\/p>\n Using a forum not only fosters earlyvangelism<\/a> by building a community, it allows your team to actually respond to beta testers. Beta testers are volunteering their time because they believe in the product, so it\u2019s important to make them feel appreciated. Furthermore, a forum will serve as a large-scale user diary of sorts for you to track the experiences of all beta testers.<\/p>\n Building your product is an ongoing process and the last thing you probably want to do is throw more paperwork into your sprints.<\/p>\n But a certain level of documentation is necessary to keep some order in all the chaos. User requirements coming from product management need to be translated. Dependencies among different technical entities have to be understood. And internal and external testing feedback must be captured to justify expensive-but-necessary changes. In between all this, you\u2019ll need to answer stakeholder questions like \u201cHow is everyone staying on the same page?\u201d and \u201cHow will we realize our goals in the set time limit?\u201d<\/p>\n The templates and tactics we\u2019ve listed all serve as helpful reference points as you prepare for the ultimate product test \u2014 your launch date.<\/p>\n For more smart ways on incorporating documentation into the design process, download the <\/i>Guide to UX Design & Process Documentation<\/i><\/a>. Expert advice is featured from Aarron Walter, Laura Klein, Ian McAllister, and dozens others. Visual examples are also shown from companies like Vurb, MailChimp, Apple, Google, and many more. <\/i><\/p>\n![\"Guide](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/jira-slide-scrum.png\")
<\/p>\n\n
![\"Guide](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/spreadsheets.jpg\")
<\/p>\n![\"Screen](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/Screen-Shot-2014-08-05-at-9.08.06-PM-1024x474.png\")
<\/p>\nFeed Your Dogfood to Others<\/h2>\n
![\"Screen](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/Screen-Shot-2014-08-06-at-6.10.38-PM.png\")
<\/p>\n![\"Guide](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/Screen-Shot-2014-08-06-at-6.41.25-PM.png\")
<\/p>\n![\"Screen](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2015\/01\/Screen-Shot-2014-08-06-at-6.15.28-PM.png\")
<\/p>\nUse What Works and Scrap the Rest<\/h2>\n
![\"blog\"](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2014\/11\/blog.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"