 Hi, my name is Tharu and I'm a Product Manager on the Chrome commercial team. And my name is Jason. I'm a Program Manager on the Chrome ecosystem team. As a developer building products for Chrome OS and Chrome browser, you may wonder how best to support your users and customers while maintaining development velocity. This can especially be a challenge in enterprise environments where downtime can have a severe impact on the productivity of thousands of employees. We've put together some best practices from working closely with enterprise developers targeting Chrome. In this talk, we'll be covering application testing. By following some simple testing guidelines, you can ensure that your applications will be stable and operate with high performance. First, let's talk about what to test. When developing your tests, be sure to test your critical user journeys. Your test cases should be representative of the workflows people use in your application. Second, you should be sure to test against multiple operating systems. Chrome browser is available on Windows, Mac, Linux, Android, iOS, and Chrome OS. Look at what operating systems your users are on and be sure to test those versions of Chrome. In particular, Chrome for iOS is built on top of WebKit rather than Blink, so there may be unexpected feature gaps or unique issues. If you have a strong user presence using Chrome for iOS, be sure to test that platform separately. Finally, we recommend that you test against multiple channels of Chrome. You can install and run the stable beta and dev versions of Chrome simultaneously on Windows, Linux, and Android. Please note that side-by-side Chrome installation is not currently available on Mac OS, iOS, or Chrome OS. To test on these platforms, you should use one machine for each channel. There are four Chrome channels. The stable channel. You're probably already testing against the stable channel today. This is the channel that the majority of users are on, including enterprise users. So if you do find any bugs on the stable channel, they are likely to already be affecting your current customers. This is why we recommend testing on the beta channel so that you can mitigate potential issues ahead of time. The beta channel is the channel we most strongly recommend that you use for testing. We also recommend Chrome Enterprise organizations to keep 5% of their deployment on Chrome beta, as they will get a 4-6 week preview of new features and find issues which could impact their entire Chrome user base. The dev channel includes new features and is updated several times a week. We primarily recommend testing on the dev channel for previewing bug fixes. Finally, the Canary channel includes many experimental features and is not recommended for enterprise application testing due to its unstable nature, unless you are targeting those experimental features. New versions are released daily. Next, let's talk about when to test your application. Chrome operates on a 6-week release schedule. Be sure to test your application against the newest beta every 6 weeks. One week after a new stable version of Chrome is pushed to the public, the beta channel for the next version of Chrome will be released. The beta channel will be promoted to stable 5 weeks after it is released. The best time to test your application is during the first 2 weeks of the beta release so that there is more time to address any identified issues before it is promoted to stable. You can check the schedule at chromestatus.com slash features slash schedule for exact dates. Please note that the stable release is done as a scattered update so the published date does not reflect the date at which 100% of users will be on the latest version of Chrome. Also, each operating system has a different stable rollout plan. Now, we'll discuss how to test your application. First, in order to test against the relevant channels and operating systems, you will need to download those builds of Chrome. All builds of Chrome for all operating systems are available through the links on this page. Since Chrome Enterprise offers version pinning, Enterprise deployments may be pinned to an older version of Chrome. Please keep this in mind that we do not make historical builds available so in order to test against a specific older version of Chrome, you will need to maintain your own archive of builds. Also note, we do not support bugs filed against older versions of Chrome. Now, let's talk about some tools that we provide to help with testing Chrome. Puppeteer is a Node.js library which provides a high-level API to control headless or full non-headless Chrome or Chromium over the DevTools protocol. Puppeteer can be used to automate navigation to webpages, user input, JavaScript, execution, performance testing, reporting, and more. Lighthouse is an open source automated tool for improving the quality of webpages. You can run Lighthouse against any web page, whether public or requiring authentication. It has audits for performance, API deprecations, and more. Finally, let's talk about how to report issues that you come across in your testing. Testing and reporting bugs early using the right tools and providing the right context are key to getting resolution. First, you should verify that the bug is specific to Chrome. Make sure the bug can be reproduced on a different device running the latest beta version of Chrome. Before filing a bug, check if your issue has already been reported by searching through existing bugs. If you are logged in, you can click the star icon to subscribe to all updates posted on the bug. Starring a bug also helps us prioritize it and lets us know how many developers or users are impacted by the bug. Duplicate bugs will still be triaged, however, this may increase the time before your bug is addressed. In other words, it is more effective to add a comment to an existing bug and star it than to create a new bug for the same issue. Finally, be sure to provide sufficient detail. Evaluation and triaging will be more efficient and reliable if you can provide as much information as possible, including detailed reproduction steps, screenshots, operating system, and browser version. You can follow your bugs to the Chromium Issue Tracker, which is available to the public at crbug.com.