Source Code: https://aka.ms/absbeginnerdevwp8
PDF Version: https://aka.ms/absbeginnerdevwp8pdf

Now that we've finished the app, it's time to test it and submit it to the Store.

A word of caution before we continue ... at a minimum, your users expect your app to be solid and to look professional.

With regards to creating a solid user experience, there's only so much you can do by yourself because you have the curse of knowledge. As the developer, your knowledge of the flow and "normal operation" of the app creates a myopia. You'll quickly find that your users will brake the app in new and creative ways. So, I would spend a of time thinking about the states of the application, particularly any scenario that accepts information from the user in input controls or dialogs. I would spend time thinking about exception handling and messages back to the user to help diagnose the problem. I would think about inputs and outputs and edge case scenarios ... What if they use strange characters outside of the ASCII or Extended ASCII range? What if they add two sounds with the same name? What if the program runs out of battery while the user is recording a sound? What happens if the user clicks one of the hardware buttons while recording or playing back a sound? What if the user fills up Isolated Storage with custom sounds? As it stands now, that would be a problem because we don't have a delete sound feature in the app.

With regards to a professional appearance, here again you have the curse of knowledge and quite possibly a cognitive bias that leads you to think the flow and aesthetics of the app look great when your users think otherwise. Getting feedback, especially from someone who may study design, usability, etc. could prove invaluable. I would get them involved early and often throughout the development process. The beauty of the Windows Design language, formerly known as Metro, is that it pushes you towards a certain aesthetic sensibility. You should study the recommendations from Microsoft in this regard:

https://developer.windowsphone.com/en-us/design

At any rate, even when you're getting creative and thinking through the functionality of your app, you'll miss something. That's why it's good to:

1. Let others see your work, especially those who are not your close friends or family. You want honest feedback. Your family and friends won't want to hurt your feelings if they don't like your work.
2. Use the Beta test feature of the store before you attempt to sell the app. Now you're opening your app up to more scrutiny and feedback, however it's better you hear that feedback in beta rather than hear that feedback in the form of negative reviews that pour in and kill your app's chances at success.
3. Even after you've sold the app (or distribute it for free), be responsive to customer emails, questions, feedback, etc. Whether you realize it or not, once you publish an app you're now running a business. From now on you need to be the friendliest guy on the planet. If someone asks for a new feature, ask them for more details and genuinely give serious thought to whether that's a viable feature to add or a bug to fix. If someone is frustrated and uses harsh language or tone against your app, you gain absolutely nothing by returning the salvo. You need to grow thick skin, swallow your pride, and be the bigger person. From personal experience in handling customers who are displeased over the years, you can turn an enemy into a friend more often by not by choosing your words carefully. May I recommend the time-honored book, How to Win Friends and Influence People by Dale Carnegie.
4. Dedicate a URL and a few pages to your app. Include FAQ's so people can self-serve for the most common issues.
5. Understand the impact of low-memory on your app. I suspect most app crashes have to do with memory constraints, or the failure to close a resource like the file system when you're finished working with them.

The game plan for this lesson:

1. We'll perform some compliance testing to make sure our app has a chance to be included in the Store
2. We'll submit our app to the store

1. Run the Store Test Kit

To evaluate the readiness of our app for the app store, we'll use the Store Test Kit. This will automatically test a few scenarios and suggest other manual tests for you to conduct. Furthermore, it works as a check list for the items you'll need to submit to the store, like promotional images and the like.

To open the Store Test Kit, go to the Project menu select Open Store Test Kit:

This will open a new page in the main area. Notice there are three tabs on the left:

The Application Details collects basic data about the app, including a larger version of the main tile (300 pixels by 300 pixels) for the Store and screenshots of the app. If you use the Phone Store, you can see that each app has a page with descriptive text and details about the publisher, a page with the ratings and reviews for the app, and a page of screenshots.

The Automated Tests tab will perform a few tests to ensure the validity of the XAP deployment package, and will ensure the images (from the Application Details tab) are in place as well.

The Manual Tests tab has a number of suggestions for you to test on your app before submitting it.

To the right of the test status (think of this like a check box that you will manually check off) and the name of the test is the description of the test and how to perform the test, what constitutes failure, etc.

If you attempt to run the tests without changing anything in Visual Studio by clicking the "Run Tests" button on the Automated Tests tab ...

... you'll probably get the following warning / error:

There are several issues we'll need to correct, but the first one is that we need to create a Release version of the deployment package. We've been using a Debug version which includes additional files used to sync up the execution of the code on the Emulator or the Device with Visual Studio so that you can set break points, step through code, and so on.

Now we'll need to create a release version. Before I do that, let's confirm that Visual Studio will create a Release version that is configured to be deployed to "AnyCPU" per the instructions of this dialog. In the toolbar, I'll select the drop down list next to the Run button and select Configuration Manager:

The Configuration Manager dialog appears:

In the Action solution configuration drop down list, I'll select Release ...

And I'll review the Project contexts in the main area, ensuring that the Configuration is set to Release and the Platform is set to "Any CPU".

If the settings are right (and they should be by default), then I'll Build the Solution (Build menu, select Build Solution).

If all goes well, the Output window should indicate success. If it doesn't you'll obviously need to fix that before continuing.

Now that we have a valid release version of our XAP deployment package, we'll "Run Tests" again ...

... this time, we see that we failed with Iconography and Screenshots.

Before I set those, let's take a look at the button further down on that page ... the "Start Windows Phone Application Analysis" ...

Clicking this button will add a new .sap file which is a blank performance log file that will c