test cases for universal windows platform (uwp) and windows...

Test Cases for Universal Windows

Platform (UWP) and Windows 8.1

Applications

Contents 1. Launch-related Test Cases .................................................................................................................................. 4

1.1 Low spec devices ............................................................................................................................................. 4

1.2 Launch on all required device families ....................................................................................................... 4

1.3 Multi-regional launch ..................................................................................................................................... 5

1.4 Offline launch .................................................................................................................................................. 5

1.5 Launch time ..................................................................................................................................................... 5

1.6 Additional applications .................................................................................................................................. 6

2. Log In Test Cases .................................................................................................................................................. 6

2.1 Offline log in .................................................................................................................................................... 6

2.2 Invalid credentials........................................................................................................................................... 7

2.3 All log in methods are functional ................................................................................................................ 7

2.4 Switching away after logging in .................................................................................................................. 7

2.5 Account creation ............................................................................................................................................ 8

2.6 Account switching .......................................................................................................................................... 8

3. Application Use Test Cases ................................................................................................................................. 9

3.1 App Switching.................................................................................................................................................. 9

3.2 Software Input Pad implementation .......................................................................................................... 9

3.3 Touch targets ................................................................................................................................................. 10

3.4 Visual feedback ............................................................................................................................................. 10

3.5 Gestures ...........................................................................................................................................................11

3.6 Secondary tiles ................................................................................................................................................11

3.7 Command bar with contextual commands ............................................................................................. 12

3.8 Application is stable ...................................................................................................................................... 12

3.9 Application performance is responsive .................................................................................................... 13

3.10 Toast notifications are actionable............................................................................................................. 13

3.11 Offline mid-use scenarios ........................................................................................................................... 14

3.12 Saved status preservation .......................................................................................................................... 15

3.13 Portrait and landscape mode scenarios.................................................................................................. 15

3.14 Core scenarios completed within the application ................................................................................. 16

3.15 In-App purchases ........................................................................................................................................ 16

3.16 Geofencing ................................................................................................................................................... 17

3.17 Cross-Platform adaptive layout ................................................................................................................ 17

3.18 Application is feature complete ................................................................................................................ 17

3.19 App Resume ................................................................................................................................................. 18

3.20 Readability .................................................................................................................................................... 19

3.21 Placeholder text and imagery ................................................................................................................... 19

3.22 Application specific hardware ................................................................................................................. 20

3.23 Cortana ........................................................................................................................................................ 20

3.24 Resuming after idling ................................................................................................................................. 21

3.25 In-app settings ........................................................................................................................................... 22

3.26 Audio quality ............................................................................................................................................... 22

3.27 Multi-regional use ...................................................................................................................................... 23

4. Mobile-Only Test Cases .................................................................................................................................... 23

4.1 Back button for mobile ................................................................................................................................ 23

4.2 Continuum for mobile ................................................................................................................................. 24

5. Desktop-Only Test Cases .................................................................................................................................. 25

5.1 Display resolutions and scaling .................................................................................................................. 25

5.2 Application resumes from a suspended state ........................................................................................ 25

5.3 Back button for desktop ............................................................................................................................. 26

5.4 Desktop and tablet mode switching ........................................................................................................ 26

5.5 Multiple input methods ............................................................................................................................... 27

5.6 Forward and backward navigation ........................................................................................................... 27

5.7 Windowed and split screen views ............................................................................................................. 28

5.8 Prompted updates ....................................................................................................................................... 29

6. Social Networking Integration Test Cases ..................................................................................................... 29

6.1 Shared content .............................................................................................................................................. 29

6.2 Share targets ................................................................................................................................................. 30

7. Game Specific Test Cases .................................................................................................................................. 30

7.1 Game leaderboard ....................................................................................................................................... 30

7.2 Game achievements and scores ................................................................................................................ 31

7.3 Game multiplayer support .......................................................................................................................... 31

7.4 Roaming Game Saves ................................................................................................................................. 32

7.5 Game mods ................................................................................................................................................... 32

7.6 Save slots ....................................................................................................................................................... 32

8. Media Specific Test Cases ................................................................................................................................. 33

8.1 Background audio playback ....................................................................................................................... 33

8.2 Background audio controls ........................................................................................................................ 33

8.3 Video pauses playback when the application is in the background .................................................. 34

8.4 Saved streaming media position .............................................................................................................. 34

9. Feature Verification ............................................................................................................................................ 35

10. Competitive Parity Test Cases ........................................................................................................................ 35

10.1 Feature parity – Competitive platforms .................................................................................................. 35

10.2 Feature parity - Website ........................................................................................................................... 36

11. Surface Hub-Only Test Cases .......................................................................................................................... 36

11.1 First run experience ..................................................................................................................................... 36

11.2 Multiple input methods .............................................................................................................................. 37

11.3 Forward and backward navigation .......................................................................................................... 37

11.4 Split screen views ........................................................................................................................................ 38

11.5 Cloud storage or removable media support ......................................................................................... 38

11.6 Controls accessible without occluding content (presentation applications) .................................... 39

11.7 Controls accesible by multiple users (collaborative applications) ...................................................... 39

11.8 Large screen ergonomics .......................................................................................................................... 39

12. Xbox Device Family UWP App Test Cases ................................................................................................... 40

12.1 Mouse mode disabled ............................................................................................................................... 40

12.2 TV screen UI ................................................................................................................................................. 41

12.3 Gamepad and remote control mappings ............................................................................................... 41

12.4 Collapsed navigation pane ....................................................................................................................... 42

12.5 All controls should be accessible via d-pad .......................................................................................... 42

12.6 Snapped applications ................................................................................................................................ 43

12.7 Back button for Xbox ................................................................................................................................. 44

12.8 Cloud storage or removable media support ........................................................................................ 44

1. Launch-related Test Cases

1.1 Low spec devices

The application should install and function properly on low spec devices.

Expected result:

The application should function properly on low spec devices.

Note: A “Low spec” phone is defined as a 512MB Windows Phone 8.1 device, ex: Lumia 520 and a 1GB

Windows 10 Mobile device, ex: Lumia 535. A “Low spec” tablet is defined as a 2GB Windows 10

Desktop device with Intel integrated graphics, ex: Dell Venue 8 Pro.

If the application performs poorly with the hardware configuration above, be sure to disclose the

hardware requirements in the ‘System Requirements’ section of the ‘App properties’ page when

submitting the application and completing its metadata in Windows Dev Center. Be sure to also alert

users in the first line of the Store description, ex: “Is your PC Rise of the Tomb Raider ready? View

'System Requirements' below to find out!”

1.2 Launch on all required device families

The application should install and launch properly on all device families the application is supporting.

Steps to Reproduce:

1. Attempt to install and launch the application on all required device families.

Expected result:

https://msdn.microsoft.com/en-us/windows/uwp/publish/enter-app-properties#system-requirements

http://developer.windows.com/

The application should install on all required device families.

The application should launch without error.

1.3 Multi-regional launch

The application should launch properly on devices where the local username contains Unicode

characters.

Steps to Reproduce:

1. Launch the application on a device where the user local folder path has Unicode characters,

ex: c:\users\캔디\.

Expected result:

The application launches properly on devices where the local username contains Unicode characters.

1.4 Offline launch

The application should be stable and not crash or close unexpectedly if the device is offline. When the

application is offline, the application should warn the user for any requested action that cannot be

completed.

Steps to Reproduce:

1. Disconnect from the network and wait 10 seconds.

2. Launch the application.

3. Perform an action that will cause a connection to be attempted.

Expected result:

The application will detect that the network is not available and alert the user.

Application should not crash and provide a relevant error message to user. Application should

not display the exception stack to the user.

The application can also implement an offline (cached) mode without alerting the user.

1.5 Launch time

The application should launch in a reasonable amount of time, and should display a loading or

progress indicator if the application takes a while to load.

Steps to Reproduce:


2. Record the start-up time.

Expected result:

The application displays a loading or progress indicator if the application takes a while to load,

and the content loads in a reasonable amount of time.

1.6 Additional applications

The application must not deliver or install non-integrated third-party owned or branded applications

unless they are delivered as in-app products.

Steps to Reproduce:

1. Install the application.

2. Ensure that Step 1 installed only one listing to the Start menu.

Expected result:

Multiple applications should not be bundled in one installation.

In-app settings and options should be accessible from the main application rather than from

additional listings in the Start menu.

More information:

For more information see Windows Store Policies.

2. Log In Test Cases

The following test cases apply only to applications that support log in.

2.1 Offline log in

When the application is offline and the user attempts to log in, the application should warn the user

of the offline status.

Steps to Reproduce:



3. Attempt to log in with valid credentials.

4. Verify that an appropriate error message appears.

5. Reconnect to the network and wait 10 seconds.

6. Return to the application.

7. Log in with valid credentials.

Expected result:

https://msdn.microsoft.com/en-us/library/windows/apps/dn764944.aspx

When attempting to log in without a network connection, an appropriate error message

should appear warning the user of the offline state.

When the network connection has been resumed, log in should work appropriately.

2.2 Invalid credentials

The application should warn the user appropriately when invalid credentials are entered.

Steps to Reproduce:


2. Attempt to log in with invalid credentials.

3. Verify that an appropriate error message appears.

4. Log in with valid credentials, changing the casing in the username field.

Expected result:

When attempting to log in with invalid credentials, an appropriate error message should

appear warning the user that the credentials are invalid.

The username field should not be case-sensitive.

When correct credentials are entered after a failed attempt, log in should work appropriately.

2.3 All log in methods are functional

All available log in options should be fully functional and appropriately implemented.

Steps to Reproduce:


2. Log in using all available options with valid credentials.

Expected result:

Application logs in when valid credentials are entered.

Social networking log in and/or sign up is processed using the services’ login page(s) and not

using application pages for this purpose.

2.4 Switching away after logging in

The application should load content successfully after switching away during the loading process.

Steps to Reproduce:


2. Log in with valid credentials.

3. While the application is loading, switch away from the application.

4. Wait one second and return to the application.

Expected result:

Content should load successfully after returning to the application.

2.5 Account creation

The creation of accounts within the application (when available) should function properly.

Steps to Reproduce:


2. Create an account if the option is available, entering valid information when prompted.

3. Exit the application.

4. Attempt to log in with the newly created account.

Expected result:

Accounts can be successfully created within the application when the option is available.

If an email verification is required, the application should state this and the verification email

should arrive within an hour of creating the account.

Username, email, and password requirements are made clear to the user.

2.6 Account switching

Users should be able to log into various accounts properly when the option is available.

Steps to Reproduce:

1. Launch the application and log into account #1.

2. Navigate through the application, saving information to the account whenever possible.

3. Log out and exit the application.

4. Launch the application and log into account #2.

5. Navigate through the application.

Expected result:

Logging into a second account should function properly after logging out of a first account.

Data from a first account should not appear when logged into a second account.

3. Application Use Test Cases

3.1 App Switching

The application should display and function properly when switching away and returning, as well as

re-issue network requests when application is reactivated.

Steps to Reproduce:

1. Launch application.


3. Switch away from the application (using Windows key + D if necessary).

4. Select the Start button.


6. During loading (when loading indicator is present), switch away from the application.

7. Wait one second and return to the application.

Expected result:

Functionality completes successfully and data is downloaded without error or exception.

The application does not display in the background when deactivated and displays as

expected after switching away and returning.

More information:

For more information on Fast App Switching in Windows Phone applications, see Get Ready for Fast

Application Switching in Windows Phone and App activation and deactivation for Windows Phone 8

For Windows applications, see Managing app lifecycle so your apps feel "always alive"

3.2 Software Input Pad implementation

The Software Input Pad (SIP) should be contextually-aware of the types of input allowed per input

field and it needs to be dismissed when input field is not selected on an application or when the

application is deactivated.

Steps to Reproduce:

1. Switch the device to Tablet mode and ensure a keyboard is not connected.


3. Find an input textbox that allows alphanumeric characters.

4. Verify when this control has focus (is tapped with touch), the full keyboard and symbols are

displayed.

5. Find an input textbox that allows only numbers.

6. Verify when the control has focus (is tapped with touch), only the keypad SIP is displayed.

http://channel9.msdn.com/events/MIX/MIX11/DVC09

http://channel9.msdn.com/events/MIX/MIX11/DVC09

https://msdn.microsoft.com/library/windows/apps/ff817008(v=vs.105).aspx

http://blogs.msdn.com/b/windowsappdev/archive/2012/04/30/10292044.aspx

7. Move focus out of the input textbox (tap outside of the textbox with touch).

Expected result:

The SIP is dismissed when input controls lose focus.

Users can see what they are typing while they are typing it.

3.3 Touch targets

Touch targets should not be smaller than 7 mm or 26 pixels square.

Steps to Reproduce:



3. Identify actionable UI elements on the application.

Expected result:

Actionable UI elements in the application should be clearly visible and easily touchable by finger

without interfering with other neighboring touchable UI elements.

More information:

For more information on the Windows touch language, see Touch interaction design

3.4 Visual feedback

Visual feedback helps users recognize whether their interactions with your application are detected,

interpreted, and handled as intended.

Steps to Reproduce:


2. Explore and navigate the application. Tap on each actionable UI element.

Expected result:

There is visual feedback for actionable or interactive UI elements.

There is no visual feedback for non-actionable or non-interactive UI elements.

Note: Acceptable visual feedback can be a slight change in color and/or movement of the

button when selected by touch or mouse (not when hovering over with a mouse.)

More information:

For more information on visual feedback, see Guidelines for visual feedback

http://msdn.microsoft.com/en-us/library/windows/apps/hh465415

https://msdn.microsoft.com/en-us/library/windows/apps/hh465342.aspx

Touch interaction guidance: Touch interactions for Windows

Responding to user interactions: Responding to user interaction

3.5 Gestures

Primary actions should be enabled by directly interacting with content. For example, tap to open,

swipe to select, pinch to zoom, and drag to pan/paginate. If a panorama or pivot control contains

other controls which use the same left / right flick gestures, this may result in a poor user experience

due to gesture overlaps. UI elements, controls or other parts of an application should not interfere

with Windows edge gesture.

Steps to Reproduce:


2. Explore and navigate the pages and functionality of application with touch only.

3. Inspect the application’s panorama/pivot control for scrollable map, horizontal scroll viewer,

toggle switches, sliders, or other controls that use left / right flick (or pan) gestures.

4. Navigate to each page and test the edge gestures for commanding surfaces (Title bar, Task

bar, Action center, Task View). (For Windows 8 apps: app bar, navigation bar, charms bar,

recent app.)

Expected results:

The application should fully support touch input. For example, the user should be able to

navigate or interact with commands using touch input only.

Touch gestures should only be used for actions that match the Windows touch language.

Pivot and/or panorama controls do not have controls with competing gestures and can be

used reliably.

If the hub, panorama or pivot reacts by scrolling then the child control should not trigger.

Any UI elements, controls, or other parts of the application should not interfere with Windows

edge gestures.

More Information:

Gesture interaction guidance: Gestures, manipulations, and interactions

3.6 Secondary tiles

Secondary tiles should enable users to pin context specific content on the Start screen.

Steps to Reproduce:

http://msdn.microsoft.com/en-us/library/windows/apps/hh465415.aspx


https://msdn.microsoft.com/en-us/library/windows/apps/xaml/JJ883700(v=win.10).aspx


2. Explore the application and identify functionality (if any) where the user has the option to ‘Pin

to Start’.

3. Select ‘Pin to Start’ to create a secondary tile on the Start screen.

4. Launch the application by tapping the primary tile of the application on the Start screen or

tapping the application name from the application list page.

5. Navigate to a second or third level page in the application.

6. Tap the Start button to return to the Start screen.

7. On the Start screen tap the secondary tile of the application.


9. Launch the application from the secondary tile.

Expected result:

Launching the application from the secondary tile results in displaying content related to the

secondary tile.

On pressing the Back button (if applicable), user exits the application or navigates to the main

page.

More information:

For more information on tiles refer below link: Secondary tiles overview (Windows Runtime apps)

3.7 Command bar with contextual commands

Command bar commands need to be functional as well as predictable and organized so users can

easily find them.

Steps to Reproduce:


2. Explore and navigate the pages and functionality of application.

3. Select items with contextual commands.

Expected result:

All command bar buttons are functional, relevant, and contextual.

3.8 Application is stable

The application should be stable and not crash or hang. The application should not have functional

bugs that prevent completion of core scenarios.


Steps to Reproduce:



Expected result:

Application should not crash or hang.

3.9 Application performance is responsive

The application must appear responsive to the user at all times. Visual feedback is needed to indicate

the application is not frozen. Load times may be longer on slow connections resulting in the

application appearing to be frozen if no visual feedback is provided.

Steps to Reproduce:



3. Invoke functionality that requires time to load. E.g. network request to load data.

4. For games, check the framerate using Fraps (www.fraps.com).

Expected result:

The application displays a loading or progress indicator for tasks that may take time to load,

and the content loads in a reasonable amount of time.

When the content has fully loaded, the loading indicator should no longer be present.

Application should be responsive and fluid.

Transition animations should be smooth.

The application should not display a blank screen, blank tiles, or empty white rectangles.

Games should have a framerate above 25 fps.

More information:

Guidelines for progress controls: Guidelines for progress controls

For Centennial applications: Desktop App Converter Preview

3.10 Toast notifications are actionable

Notifications should be used for time-sensitive or personally relevant notifications. Notifications are an

invite back into the application when it is not in the foreground. Tapping the notification should bring

the application to the foreground and in context to the notification.

Steps to Reproduce:


https://msdn.microsoft.com/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter


2. Invoke functionality to create a toast or notification. E.g. push notification or scheduled

reminder.

3. Switch away from the application and/or close the application.

4. Wait for the notification.

5. Select the notification.

Expected result:

When selecting the toast or notification, the application should be brought to the foreground

in the context of the toast or notification.

Toast notifications should not be displayed when the application is in the foreground.

More information:

For more information see Guidelines for toast notifications and Guidelines for toasts and badges

3.11 Offline mid-use scenarios

When the system is in an offline scenario (no cell coverage, no WiFi, airplane mode, etc.), the

application should alert the user appropriately.

Steps to Reproduce:





5. Perform an action that will cause a connection to be attempted.

6. Verify that the application notifies the user of the offline state.

7. Reconnect to the network and wait 10 seconds.


Expected result:

The application will detect that the network is not available and alert the user.

Application should not crash and provide a relevant error message to user. Application should

not display the exception stack to the user.

The application can also implement an offline (cached) mode without alerting the user.

When resuming to the application in an online state after being previously using in an offline

state, the application should detect that the connection has been restored and work properly.

More information:


http://msdn.microsoft.com/en-US/library/windows/apps/hh465403

For more information, see Offline Sync for Mobile Services and Build offline apps with Azure Mobile

Services

3.12 Saved status preservation

Application progress and saved states should be maintained after navigating away, exiting, and

synching on another device.

Steps to Reproduce:

1. Launch the application and log in if available.

2. Explore and navigate the pages and functionality of application, saving whenever possible (for

games, clear 2~3 levels/stages/checkpoints).


4. Launch the application (if applicable, launch on a second device and log into the same

account as in step 1).

Expected result:

The application should retain saved states.

The application should retain saved information across devices when logged into the same

account.

3.13 Portrait and landscape mode scenarios

The application should adapt properly to portrait or landscape view if supported.

Steps to Reproduce:

1. Rotate the device to portrait or landscape view.


3. If the application supports both portrait and landscape view (layout changes), navigate to

each page in the application. Rotate the device between all supported orientations at each

page.

Expected result:

When launched, the application remains in the same orientation as the device (if the

application supports multiple orientations).

All application pages render properly and adapt to the views supported. Ex: no text

truncation, all buttons are accessible, etc.

Applications should not display a logo or error message when the view is changed.

Applications should not launch in portrait mode on a Desktop device unless the application is

launched in portrait mode.

http://azure.microsoft.com/blog/2014/07/30/offline-sync-for-mobile-services/

http://channel9.msdn.com/Series/Windows-Azure-Mobile-Services/Build-offline-apps-Azure-Mobile-Services

http://channel9.msdn.com/Series/Windows-Azure-Mobile-Services/Build-offline-apps-Azure-Mobile-Services

More information:

For Centennial applications, information on detecting orientation states and changes in Win32 apps

can be found here: Desktop Rotation Sample Whitepaper

3.14 Core scenarios completed within the application

All core application scenarios are completed without errors.

Steps to Reproduce:


2. Navigate through the entire application.

Expected result:

All core scenarios are accessible from within the application, not from an external web

browser.

Note: It is acceptable for a privacy policy or a login page that redirects back to the application

to open in a web browser.

Note: It is acceptable for the application to contain an in-app web browser.

3.15 In-App purchases

In-App (Add On) purchases should display the corresponding Store UI.

Steps to Reproduce:


2. Locate an in-app purchase.

3. Cancel the purchase.

Expected result:

The item for sale in the application should correspond to the one found in the Store UI.

The Store UI should take no more than 5 seconds to display.

Cancelling a purchase should not charge the user or reward them with the item.

After June 29, 2015, third party solutions for selling digital content consumed in the

application are no longer permitted. Microsoft IAP must be used to sell digital items that are

consumed or used within the application. The use of an external web browser or in-app

webview is not acceptable.

https://software.intel.com/en-us/articles/windows-8-desktop-app-desktop-rotation-sample-whitepaper

3.16 Geofencing

When geofenced sections of the application are accessed outside of the targeted area, the

application should display an appropriate error message.

Steps to Reproduce:


2. Locate or create the application scenario dependent on geofencing.

3. Perform an action that invokes the geofenced feature.

Expected result:

There should be an indication that the application is being used outside of the required region.

3.17 Cross-Platform adaptive layout

The application layout should adapt and display properly on all supported devices.

Steps to Reproduce:

1. Launch the application on all supported devices.

2. Navigate through the application and inspect the layout.

Expected result:

All application pages render properly and adapt across all supported devices. Ex: no text truncation,

all application buttons are accessible, no large blank areas, etc.

More information:

For more information see Introduction to Universal Windows Platform (UWP) applications for

designers , TargetDeviceFamily (Windows 10 Insider Preview) , UWP Development 1: Building an

Adaptive UI and Web Apps Beyond the Browser: Cross-Platform Meets Cross Device

For information on how to turn off scaling for UWP on Xbox see How to turn off scaling

3.18 Application is feature complete

The controls within the application should invoke the expected functionality. The application should

not display messages indicating features are ‘coming soon’ or do nothing in response to control

actions.

Steps to Reproduce:





https://channel9.msdn.com/Events/Build/2016/L724-R1

https://channel9.msdn.com/Events/Build/2016/L724-R1

https://channel9.msdn.com/Events/Build/2016/B888

https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/disable-scaling?f=255&MSPPError=-2147217396

2. Navigate through the application, interacting with buttons and tiles throughout.

Expected result:

The controls within the application should work as expected and should not present “coming soon”

messages.

3.19 App Resume

App Resume allows the previous suspended instance of the application to be resumed when user re-

launches the application from the Start screen.

Steps to Reproduce:

1. Launch the application by tapping the primary tile of the application on the Start screen or

tapping the application name from the application list page.

2. Navigate to a second or third level page in the application.

3. If testing a Desktop application in Desktop mode, navigate away from the application.

4. Tap the Start button to return to the Start screen.

5. On Start screen, tap the primary Tile again to resume the application.

Expected result:

The application resumes to the same page as in step 2 and pressing the back button takes the user

through the correct sequence of pages.

Or

The application resumes at the main page (without the splash screen and loading indicator) and

pressing the Back key exits the application. Pressing the Back key should NOT navigate to another

page.

More information:

For more information see App lifecycle - Windows app development

For Centennial applications:

To restrict your Win32 application to one instance and to bring it to the foreground if the application is

already running, consider the following C++ code:

When your application initializes, create a mutex. If it already exists, find the existing application and

bring it to the foreground. If the application has a fixed title for its main window, it is easy to find with

FindWindow.

https://msdn.microsoft.com/en-us/library/windows/apps/hh464925.aspx

m_singleInstanceMutex = CreateMutex(NULL, TRUE, L""Some unique string

for your app"");

if (m_singleInstanceMutex == NULL || GetLastError() ==

ERROR_ALREADY_EXISTS) {

HWND existingApp = FindWindow(0, L""Your app's window title"");

if (existingApp) SetForegroundWindow(existingApp);

return FALSE; // Exit the app. For MFC, return false from

InitInstance.

}

3.20 Readability

All content in the application should be easily readable and adapt to a mobile or desktop device set

to both light and dark themes.

Steps to Reproduce:

1. If testing on a mobile or desktop device, set the device to the dark theme.


3. Navigate through the application, if an in-app light/dark theme is available switch between

the two.

4. If testing on a mobile or desktop device, set the device to the light theme.


Expected result:

All content in the application displays properly (ex: no light text against white backgrounds, etc.)

3.21 Placeholder text and imagery

The application should not display placeholder text or imagery.

Steps to Reproduce:

1. Locate the application in the device’s list of applications.

2. Pin the application to the Start screen.

3. Adjust the tile size.



Expected result:

• Tiles should be unique to the application and not display the default ⊠, a Unity logo, or be

blank.

• Splash screen should reflect the brand of the application. The splash screen should not

display the default icon ⊠ or be blank.

• The application should not display developer or placeholder text.

• Messaging and/or imagery in the application should not be from a different version of the

application (ex: Mobile imagery or tutorial instructions on a Desktop application,

iOS/Android imagery or text, etc.)

3.22 Application specific hardware

The application should function properly with all supported hardware.

Steps to Reproduce:

1. Connect supported hardware (ex: Bluetooth earphones, fitness band, etc.).


3. Navigate through the application, interacting with supported hardware as needed.

4. Disconnect or turn off the hardware.

Expected result:

• The application should connect with supported hardware and interact properly, registering

any changes made with the hardware in the application.

• When the hardware is disconnected, the application should not crash and should alert the

user that the hardware has been disconnected.

• The hardware device connection should not be intermittent and stay reliably connected to

the host device.

• In-application instructions on how to sync/connect the device to the application should be

provided if the connection is not done automatically.

3.23 Cortana

Actions performed using supported Cortana commands should execute properly.

Steps to Reproduce:

1. Launch the application (this will ensure the commands are populated).

2. Select the Cortana button in the lower left corner of the Windows taskbar (on non-Desktop

devices, launch the Cortana application).

3. Perform the command, “What can I say?”.

4. Scroll down through the list of applications and locate the application under test.

5. Select the application under test and perform each Cortana command listed with voice

(example: say “News, show me the latest stories”), ensuring that the application is running

before each command is spoken.

6. Close the application.

7. Perform each Cortana command from step 5 with voice, ensuring that the application is not

running when the commands are spoken (show all running apps by displaying the task

manager on Desktop or the running apps list by holding down the back key on Mobile).

8. For media applications on Xbox, locate and begin playback of a video or an audio track.

9. Perform the standard media control commands (see: “What can I say? – Media Controls”).

Expected result:

Spoken commands should perform the action that is implied by the listed commands.

Cortana should not perform a Bing search or simply launch the application.

Commands should function when the application is running and closed.

More information:

• Cortana Voice Commands: http://aka.ms/cortanadocs

• Speech interactions in your app: http://aka.ms/speechdocs

• App Linking: http://dev.bing.com/

• SystemMediaTransportControls: SystemMediaTransportControls class

3.24 Resuming after idling

Applications should support the application lifecycle and resume successfully after the screen is turned

off.

Steps to Reproduce:


2. Navigate to a page other than the default landing page for the application. Change the state

of the page. E.g. fill in a text box.

3. Let the device go idle until the screen automatically turns off.

4. Turn the screen back on and resume use of the application.

Expected result:

• The application should be in the same state as when the application was suspended.

• Interaction with the application should resume as normal.

More information:

For more information see Application lifecycle overview

http://aka.ms/cortanadocs



http://aka.ms/speechdocs

http://aka.ms/speechdocs

http://dev.bing.com/

https://msdn.microsoft.com/en-us/library/windows/apps/windows.media.systemmediatransportcontrols.aspx


3.25 In-app settings

Implementation of in-app settings is not required. If implemented, in-app settings should work as

expected.

Steps to Reproduce:


2. Navigate to the settings section.

3. Change various graphics, audio, and language settings and save.





Expected result:

• Changed settings should register properly.

• Settings should be retained after exiting and relaunching the application.

3.26 Audio quality

Audio effects and in-app music should play without distortion.

Steps to Reproduce:



3. If the ability to import local music files is offered, import a variety of file types (ex: mp3, wma,

aac) and play them in the application.

Expected result:

Audio effects and in-app music should play without distortion (ex: no crackling or low quality audio,

music plays when expected, etc.).

3.27 Multi-regional use

The application should function properly on devices where the local username contains Unicode

characters.

Steps to Reproduce:

1. Launch the application on a device where the user local folder path has Unicode characters,

ex: c:\users\캔디\.


3. Explore and navigate the pages and functionality of application, saving whenever possible.

4. If available, export and/or import local files to/from the application.

Expected result:

• The application functions properly on devices where the local username contains Unicode

characters.

• When available, saving, importing and exporting work as expected.

More information:

For Centennial applications see Unicode and Character Sets and Unicode in C and C++

4. Mobile-Only Test Cases

The following test cases apply only to Windows Mobile applications.

4.1 Back button for mobile

Applications should properly navigate back through pages when using the back key.

Steps to Reproduce:


2. Navigate to a second or third page within the application.

3. Press the back key until reaching the Start menu.

Expected result:

http://www.joelonsoftware.com/articles/Unicode.html

http://www.cprogramming.com/tutorial/unicode.html

The application should not bring up the Start screen or exit the application unless back key is

pressed while on the main menu.

The application should navigate back through the previously selected pages in the correct

order and eventually arrive at the Start menu.

More information:

Guidelines for back buttons

4.2 Continuum for mobile

Applications should display properly on external monitors and support keyboard and mouse when

using the continuum dock.

Steps to Reproduce:


2. Navigate to a second or third page within the application.

3. Dock the device.

4. Select the application from the application list on the external monitor and ensure that the

application resumes where it was in step 2.

5. Navigate through the application and check the functionality.

6. Undock the device.

7. Select the application from the application list and ensure that the application resumes where

it was in step 5.


9. Exit the application by holding down the back key and selecting the x in the upper right

corner and re-dock the device.

10. Launch the application from the external monitor while docked.


Expected result:

The application displays properly on larger external screens, ex: no truncation, stretched out

images, or large empty spaces.

The application functions properly with keyboard and mouse, including any login screens.

More information:

For more information on Continuum, see Optimizing Windows Apps for Continuum and Optimizing

apps for Continuum for phone


https://channel9.msdn.com/Events/Build/2015/2-703

https://blogs.windows.com/buildingapps/2015/12/07/optimizing-apps-for-continuum-for-phone/

https://blogs.windows.com/buildingapps/2015/12/07/optimizing-apps-for-continuum-for-phone/

5. Desktop-Only Test Cases

The following test cases apply only to Windows Client applications.

5.1 Display resolutions and scaling

The application should support a variety of display resolutions.

Steps to Reproduce:

1. Set display resolution to 1280x800 and the resolution scaling to 125% (if prompted to sign out

for the changes to take effect then do so).


3. Inspect the layout and application functionality with both touch and a mouse.

4. Set display resolution to 1920x1080 and the resolution scaling to 150%.



7. Reboot the device.



10. Set display resolution to 1280x800 and the resolution scaling to 125%.


Expected result:

All application pages render properly and adapt at various resolutions Ex: no text truncation,

all command and app bar buttons are accessible, etc.

The application displays properly and mouse and touch input is functional (not offset) at 125-

150% display scaling.

5.2 Application resumes from a suspended state

Applications should support the application lifecycle and resume successfully from a suspended state.

Steps to Reproduce:


2. Navigate to a page other than the default landing page for the application. Change the state

of the page. E.g. fill in a text box.

3. Switch to the desktop.

4. Open Task Manager (enable View | Status values | Show suspended state) and verify

application is suspended.

5. Switch back to the application.

Expected result:

Application should be in the same state as when the application was suspended.

More information:

For more information see Application lifecycle overview

5.3 Back button for desktop

Windows 10 applications should properly navigate back through pages when using the Windows 10

system back button.

Steps to Reproduce:

1. Set the device to Tablet mode.


3. Navigate to the second or third page within the application.

4. Select the system back button located on the taskbar until reaching the Start menu.

Expected result:

The application should not bring up the Start menu unless it is a Windows 8.x application or if

the system back button is pressed while on the main menu.

The application should navigate back through the previously selected pages in the correct

order and eventually arrive at the Start menu.

More information:

Guidelines for back buttons

5.4 Desktop and tablet mode switching

Applications should seamlessly support switching between Desktop and Tablet modes.



Steps to Reproduce:

1. Set the device to Desktop mode.



4. Switch to Tablet mode.



7. Switch to Desktop mode.


9. Navigate through the application and check the functionality

Expected result:

The application should not crash when switching between desktop and tablet mode.

The application should adapt to the change in screen format and handle the differing

functionality (Software Input Pad, split view, etc.)

5.5 Multiple input methods

The application should properly handle multiple input methods.

Steps to Reproduce:


2. Navigate through the application using a mouse. Checking boxes, right clicking on items, and

dragging if possible.

3. Navigate through the application using touch (and Xbox controller and Pen if applicable).

Attempt to perform all of the same functionality as the mouse (ex: right-clicking highlighted

text displays an additional menu).

Expected result:

Application fully supports navigation and selection using a mouse and touch.

Listbox items should not change state if there are no actions associated with marking or

‘ticking’ the item.

More information:

For more information on Touch: Gestures, manipulations, and interactions Keyboard: Responding to

keyboard interactions Mouse: Responding to mouse interactions

5.6 Forward and backward navigation

There should be UI that clearly indicates how to backward navigate within the application.





Steps to Reproduce:

1. Launch the application in Desktop mode.


3. Attempt to return to a previous page.

Expected result:

Applications should be easy to navigate (ex: in-app back buttons or menus on every page).

5.7 Windowed and split screen views

The application should support a variety of screen sizes and split view(s).

Steps to Reproduce:

1. Set display resolution to minimum recommended resolution of 800x600.

2. Launch the application in Desktop mode.

3. Select the window button in the title bar to resize the application screen.

4. On each page in the application, adjust the horizontal and vertical size of the application.

5. Inspect the layout and application functionality.


7. Set display resolution to 1280x800.

8. Switch the device to Tablet mode.


10. Split the screen by swiping down from the top of the screen.

11. On each page in the application, inspect the layout and application functionality.

Expected result:

All application pages render properly and adapt at minimum resolution and split and resized

view(s). Ex: no text truncation, all command and app bar buttons are accessible, etc.

Consumer non-game applications should not display a logo or error message (ex: "this app

does not support split screen view") in split screen view.

All non-game applications should support windowed views and not force the user to full

screen view.

When snapping an application, the currently viewable position and state of the application

should still be visible when the application is in split screen view and full screen view.

Navigation between pages is still functional when in split screen view.

More information:

For more information see: Defining layouts and views and Guidelines for snapped and fill views


http://msdn.microsoft.com/en-us/library/windows/apps/hh465371

5.8 Prompted updates

If the application prompts the user to update to the latest version of the application, the link to the

update should work properly.

Steps to Reproduce:

1. Launch the application, noting the version number.

2. If prompted to update to the latest version of the application, select “Yes” or “OK”.

3. Install the update and compare the version number to the version from Step 1.

Expected result:

If the application prompts the user to update to the latest version of the application, the link

to the update should direct users to the latest UWP version of the application.

Users should not be prompted to update unless a newer version of the application is

available.

6. Social Networking Integration Test Cases

The following test case applies only to applications that have Social Network Service integration.

6.1 Shared content

Sharing should function properly when available.

Steps to Reproduce:


2. Navigate through application where social networking or sharing tied features are provided

(also check the “Share” option located in the command bar or Share Charm if applicable.)

3. Verify that actions taken in the application are properly reflected on the social network or

target application.

Expected result:

The contents and status provided by the social network or target application function properly.

6.2 Share targets

Applications that are a share target should be able to have content shared to them from another

application.

Steps to Reproduce:


2. Launch another application that is a share source.

3. Share to the application under test.

4. Verify that the actions taken in the application are properly reflected on the selected share

target.

Expected result:

The application in test appears as a share target when appropriate content is selected in

another application, ex.: a news article to be shared to the application in test Facebook.

The content shared using another application is properly shared to the application, ex.: no

references to a link that does not appear in the post, no cut off text, etc.

7. Game Specific Test Cases

Game applications may have special user scenarios where additional attention or different

interpretation of requirement is needed. The following test cases ensures applications meet general

quality bars commonly expected from game applications.

7.1 Game leaderboard

Implementation of a leaderboard is not required. If a leaderboard is implemented, ensure the

leaderboard is updated for single and multiplayer scenarios.

Steps to Reproduce:


2. Play the game long enough to post to the leaderboard for both single and/or multiplayer

sessions if offered on the application.

3. Look at all the leaderboards in the game.

Expected result:

With an active connection to the game’s backend service, the application should post to the

leaderboard showing both the gamer info such as gamer name and the associated score that

is the same as the one from the game session played.

Without an active connection to the game’s backend service, the application should not show

stability issues when not posting to a leaderboard and should inform users about the

connection issue to refresh leaderboard when users access leaderboards.

The application should not require a code to access leaderboards.

7.2 Game achievements and scores

Implementation of achievements and score are not required. If implemented, posted achievements

and scores should be recorded correctly.

Steps to Reproduce:


2. Play the game and earn as many achievements and high scores as possible.

Expected result:

The achievements and high scores are posted on the application and the application’s online

service accurately.

The achievements and high scores are earned while the device has no network connection

are saved accurately on the application and the application’s online service when connection

becomes available.

The application should not require a code to access achievements.

7.3 Game multiplayer support

Implementation of multiplayer support is not required. If implemented, multiplayer game functionality

should gracefully handle any player leaving the game.

Steps to Reproduce:


2. Select multiplayer game mode and start the game playing.

Expected result:

The game is played in a multiplayer mode with valid user.

The application gracefully handles the case where other user(s) playing the game left the

multiplayer game session.

The application gracefully handles the case where the user lost network connection during

multiplayer game session.

The application should not require a code to start a multiplayer game.

7.4 Roaming Game Saves

UWP games that can be used across multiple device families should support roaming game saves.

Steps to Reproduce:

1. Launch the application on the first device family (ex: desktop).

2. Complete a level and/or earn an achievement.

3. Launch the application on the second device family (ex: mobile), ensuring that this device is

logged into the same Microsoft account as the device in step 1.

4. Complete another level and/or earn an achievement.

5. Launch the application on the first device family (ex: desktop).

Expected result:

The game should retain achievements and level completions across multiple device families.

7.5 Game mods

Implementation of mod support is not required. If implemented, it should be clear to users where to

place mods and mod functionality should load properly from this location.

Steps to Reproduce:


2. Navigate through the application and check the Store Product Description Page for any

reference to mod support and the location mods are loaded from.

3. Place at least one mod into the folder from step 2.

4. Exit and re-launch the application.

5. Play the game.

Expected result:

The application loads mods successfully when placed into the appropriate location.

7.6 Save slots

Implementation of save slots is not required. If implemented, additional save slots should both save

and load properly.

Steps to Reproduce:


2. Play the game and save to the first save slot.

3. Continue playing and save to the second save slot.

4. Load the saved game from the first save slot.

5. Play the game and verify that the save loaded correctly.

6. Continue playing and save to the first save slot (overwriting the previous data).



9. Load the saved game from the first save slot.


11. Load the saved game from the second save slot.


Expected result:

The application saves and loads successfully to and from multiple save slots.

8. Media Specific Test Cases

The following test cases only apply to applications that support background audio or play video.

8.1 Background audio playback

Media applications that play audio (music, radio, podcasts, etc.) should continue audio playback when

the application is not in the foreground.

Steps to Reproduce:


2. Start audio playback.

3. Switch away from the application.

Expected result:

Audio continues to play after switching away from the application.

8.2 Background audio controls

Media applications that play audio (music, radio, podcasts, etc.) should support the system transport

control when the application is not in the foreground.

Steps to Reproduce:


2. Start playback.


4. Use hardware hot keys for volume to activate the system transport control (on Xbox, Double

tap the Xbox button to bring up the Guide.)

5. Switch tracks or pause using the system transport control.

Expected result:

Audio playback should be controlled using the system transport control.

8.3 Video pauses playback when the application is in the background

Media applications that display video should pause playback when the application is not in the

foreground.

Steps to Reproduce:


2. Start video playback.



Expected result:

Video playback should be paused when switching away from the application.

More information:

For more information, see Application lifecycle (Windows Runtime apps) [Activated and suspending

events]

8.4 Saved streaming media position

Streaming video positions for television programs and movies and audio positions for podcasts

should be maintained after navigating away, exiting, and synching on another device.

Steps to Reproduce:

1. Launch the application and log in if available.

2. Begin streaming playback of a television program, movie or podcast and let run for several

minutes.


4. Launch the application (if log in is available, launch on a second device and log in).

5. Play the video or podcast from Step 2.

Expected result:

The application should resume playback of streaming television programs, movies, and

podcasts from the last viewed or listened to position.

The application should retain position points across devices when logged into the same

account.



9. Feature Verification

10. Competitive Parity Test Cases

10.1 Feature parity – Competitive platforms

The application should have feature parity with competitive platforms.

Steps to Reproduce:

1. Launch application on Android and iOS devices (if applicable) or the Win32 version (for

Centennial applications).

2. Check the application for feature gaps when compared to Android or iOS, or the Win32

version (for Centennial applications).

3. For Centennial applications, if the Win32 version offers the ability to set the application as the

default application for opening associated file types (ex: music files, documents), confirm that

this is offered in the converted version and that it works properly.

Features in competitive versions not available in Windows version:

Expected result:

For native UWP applications: Non-OS specific features that are found in the Android or iOS

versions of the application are also found in the Windows version.

For Centennial applications: Features that are found in the Win32 version of the application

are also found in the Centennial version (including options made available during installation),

including the ability to set the application as the default program for opening associated file

types.

10.2 Feature parity - Website

The application should have feature parity with its respective website.

Steps to Reproduce:

1. Launch application on a Windows device and open the website the application is based on.

2. Check the application on Windows Phone for feature gaps when compared to the website.

Features in the web version not available in Windows version:

Expected result:

Features that are found on the website are also found on the Windows application.

11. Surface Hub-Only Test Cases

The following test cases apply only to Surface Hub applications.

11.1 First run experience

Some applications show a tutorial or walkthrough on first run. Developers need to ensure their first

run experience accounts for the fact that Surface Hubs can be used by many different users, and

application data is cleared at the end of every session.

Steps to Reproduce:


2. Run through the first run experience if it exists.

3. Tap "I'm done" to end the session.

4. Launch the application again.

Expected result:

If no tutorial or walkthrough is implemented the application should be intuitive and easy to

use for first-time users

If the application supports sign in, provide a per-user first run experience.

If the application does not support sign in, provide an optional first run experience (e.g. a

nonintrusive pop-up that can be skipped).

11.2 Multiple input methods

The application should properly handle multiple input methods. Pen support is recommended for

productivity applications for ease of use and to encourage collaboration on Surface Hub.

Steps to Reproduce:


2. Navigate through the application using a mouse. Checking boxes, right clicking on items, and

dragging if possible.

3. Navigate through the application using touch. Attempt to perform all of the same

functionality as the mouse (ex: right-clicking highlighted text displays an additional menu).

4. Try annotating on the application canvas using one or more pens.

5. Locate text input fields and type using both the SIP and an external keyboard

Expected result:

Application fully supports navigation and selection using a mouse and touch.

Listbox items should not change state if there are no actions associated with marking or

‘ticking’ the item.

If the application supports content creation, commenting, or markup, pen should be

supported.

The SIP should pop up near where the user has tapped.

External keyboards should be supported wherever text input is available.

More information:

For more information on Touch: Gestures, manipulations, and interactions Keyboard: Responding to

keyboard interactions Mouse: Responding to mouse interactions

11.3 Forward and backward navigation

There should be UI that clearly indicates how to backward navigate within the application.

Steps to Reproduce:



3. Attempt to return to a previous page.





Expected result:

Applications should be easy to navigate (ex: in-app back buttons or menus on every page).

11.4 Split screen views

The application should support split screen view(s).

Steps to Reproduce:


2. Launch another application. Both applications should be displayed side by side.

3. On each page in the application in test, inspect the layout and application functionality while

resizing the application by adjusting the divider bar in the middle of the screen.

Expected result:

All application pages render properly and adapt to split screen view(s). Ex: no text truncation,

all command and app bar buttons are accessible, etc.

Consumer non-game applications should not display a logo or error message (ex: "this app

does not support split screen view") in split screen view.

When snapping an application, the currently viewable position and state of the application

should still be visible when the application is in split screen view and full screen view.

Navigation between pages is still functional when in split screen view.

11.5 Cloud storage or removable media support

For security reasons, Surface Hub clears all application and user data at the end of every session.

Users should be able to easily get content that they have created off the device into cloud storage or

removable media.

Steps to Reproduce:


2. Create content.

3. Attempt to save content to the cloud or to removable media (i.e. USB drives) from within the

application.

Expected result:

If the application supports creating content, it should provide ways for users to:

• Save their content to the cloud from within the application;

• Save their content to removable media (i.e. USB drives) from within the application; or

• Save their content to a location under C:\Users\SurfaceHub that is accessible via the File

Explorer app (i.e. in the current user's Documents, Downloads, Music, Pictures, or Videos folder). If this

option is the default then the application should present messaging to users reminding them to save

their content to an external drive.

11.6 Controls accessible without occluding content (presentation applications)

For applications that specialize in presentation, controls should be placed in a location that does not

require presenters to cross in front of the display.

Steps to Reproduce:


2. Create or open content for presentation

3. Stand to either side of the Surface Hub, as though presenting content.

4. Interact with the controls on either side of the Surface Hub.

Expected result:

Controls to change slides, etc. can be accessed without having to cross in front of the display.

11.7 Controls accesible by multiple users (collaborative applications)

Applications that specialize in collaboration (e.g. a digital whiteboard) are likely to be used by multiple

users at the same time. Developers should consider how people need to move around the screen to

interact with the application while other users are present, and locate controls as appropriate.

Steps to Reproduce:


2. With at least one other person present, explore the pages and functionality.

Expected result:

Controls should be placed in mutually convenient locations (e.g. along the bottom of the screen) or

contextually pop up on screen when needed.

11.8 Large screen ergonomics

The application should consider the ergonomics of using an app on a large screen (55" or 84").

Steps to Reproduce:


2. Inspect the layout and application functionality.

Expected result:

The application should consider users' "cone of awareness", i.e. limitations to radial legibility.

At 18" from the screen, the average person's radial legibility is 18". If an action triggers a

change to another control outside this cone of awareness, it may impede users' ability to

complete scenarios.

Intensive and repeated tasks should be kept near the user's point of interaction. Consider user

height (e.g. the average height of an American woman is 5'5"). For example, avoid placing

common controls at the top of the screen.

The size of content should neither be too large to be used up close, nor too small to be

viewed from a distance - 1.3m-4m away for huddle spaces, and 1.3-6m away for large

meeting rooms.

Gestures should not require gross physical movements, e.g. changing slides should only

require a flick of the finger, not a tennis swing.

12. Xbox Device Family UWP App Test Cases

See this Build 2016 talk for a great overview of best practices when building UWP applications for

Xbox: Building Great Universal Windows Platform (UWP) Apps for Xbox

See also: UWP features that aren't yet supported on Xbox

12.1 Mouse mode disabled

A UWP application running on Xbox has mouse mode enabled by default for both XAML and Hosted

Web Apps. All applications that have not opted out will receive a mouse pointer, similar to the one in

the Xbox Edge Browser. This should be disabled in code.

Steps to Reproduce:


2. Notice if the mouse pointer is displayed in the middle of the UI.

Expected result:

Navigation using d-pad navigation should be the default. This is enabled by disabling ‘mouse mode’.

More information:

For more information on disabling mouse mode see: How to disable mouse mode

https://channel9.msdn.com/Events/Build/2016/B883

https://msdn.microsoft.com/library/windows/apps/mt693377

https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/how-to-disable-mouse-mode

12.2 TV screen UI

The application should conform to television screens by using TV safe colors, drawing into the TV-

Safe area, not including essential controls in the TV-Safe area, and accounting for users sitting across

the room during use.

Steps to Reproduce:


2. Navigate through the application and inspect the layout from 10 feet away.

Expected result:

The application uses all of the available screen and extra outer borders are not displayed.

The currently focused element is clearly visible to the user at all times when seated roughly 10

feet away from the television screen.

The application does not use high intensity colors that make the application display banded

effects or appear washed out.

Application controls are not included in the TV-Safe area

More information:

For more information see: How to draw UI to the edge of the screen, Designing for Xbox and TV and

Adapt Your App for Xbox One and TV

12.3 Gamepad and remote control mappings

Media applications should support standard play, stop, FF, RW, etc. button mappings in order to meet

user expectations.

Steps to Reproduce:


2. If vertical or horizontal scrolling is supported, verify that the gamepad triggers and bumpers

function as expected.

3. Start video or audio playback.

4. Verify all media control buttons respond appropriately (use Xbox Movies for reference.)

Expected result:

The application responds properly to gamepad and remote control buttons.

https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/turn-off-overscan

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/designing-for-tv

https://channel9.msdn.com/Events/Build/2016/T651-R1

More information:

For more information on gamepad and remote control button mappings: XBox Apps - Gamepad and

Remote Control

12.4 Collapsed navigation pane

A navigation pane (also known as a hamburger menu) is a navigation control commonly used in UWP

applications. Typically, it is a pane with several options to choose from in a list style menu that will

take the user to different pages. Generally, this pane starts out collapsed to save space, and the user

can open it by selecting a button.

Steps to Reproduce:


2. Ensure the navigation pane is collapsed when the application is started.

Expected result:

So that more real estate is available to content, Xbox applications should start with the navigation

pane collapsed.

More information:

For more information on Navigation panes see: Navigation Panes

12.5 All controls should be accessible via d-pad

D-pad navigation is strictly up, down, left and right. Avoid positioning controls that cannot be

navigated to with these constraints.

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/designing-for-tv?f=255&mspperror=-2147217396#gamepad-and-remote-control

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/designing-for-tv?f=255&mspperror=-2147217396#gamepad-and-remote-control

https://msdn.microsoft.com/windows/uwp/controls-and-patterns/nav-pane

Steps to Reproduce:

1. Launch application.

2. Ensure all controls can be navigated to using the d-pad.

Expected result:

All controls should be accessible via the d-pad

More information:

For more information on Navigation panes see: XY focus navigation and interaction

12.6 Snapped applications

The application UI should adapt when other applications are snapped next to it.

Steps to Reproduce:


2. Double tap the Xbox button to bring up the Guide.

3. Navigate down to the “Multitasking” tab.

4. Select an application that supports snapping along the application in test (ex: Cortana).

5. Tap the Xbox button to return to the dashboard and select the application in test.

6. On each page in the application in test, inspect the layout and application functionality,

playing videos whenever available.

Expected result:

All application pages render properly and the UI adapts when another application is snapped next to

it. Ex: no text or video truncation, all buttons are accessible, etc. The application may have to run in

“fill mode” next to a snapped application.

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/designing-for-tv#xy-focus-navigation-and-interaction

More information:

For more information see: Design adaptive UI with adaptive panels

12.7 Back button for Xbox

The application should properly navigate back through pages when using the B button.

Steps to Reproduce:


2. Navigate to the second or third page within the application.

3. Select the back button on the gamepad (B) until reaching the homepage of the application.

Expected result:

The application should navigate back through the previously selected pages in the correct order and

eventually arrive at the application homepage.

More information:

Designing for Xbox and TV: Gamepad and remote control

12.8 Cloud storage or removable media support

When applicable, users should be able to easily access files from or save to cloud storage or

removable media.

Steps to Reproduce:


2. Navigate to an area that accesses user files (ex: “My Videos”, “Import”, “Save As”, etc.).

3. Attempt to access or save content to the cloud or to removable media (i.e. USB drives) from

within the application.

Expected result:

If the application supports accessing or creating files, it should provide ways for users to:

• Access their content from or save to the cloud from within the application or

• Access their content from or save to removable media (i.e. USB drives) from within the

application.

https://msdn.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide#design-adaptive-ui-with-adaptive-panels

https://msdn.microsoft.com/en-us/windows/uwp/input-and-devices/designing-for-tv#gamepad-and-remote-control