THARU: Hi.
My name is Tharu, and
I'm a Product Manager
on the Chrome commercial team.
JASON WONG: And
my name is Jason.
I'm a Program Manager on
the Chrome ecosystem team.
THARU: 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.
JASON WONG: 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.
THARU: 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 four to six
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 six
week release schedule.
Be sure to test your application
against the newest beta
every six 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 five weeks
after it is released.
The best time to
test your application
is during the first two
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
/features/schedule
for exact dates.
Please note that
the stable release
is done as a scattered update,
so the publish 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.
JASON WONG: 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 web pages, user input,
JavaScript, execution,
performance testing,
reporting, and more.
Lighthouse is an
open source automated
tool for improving the
quality of web pages.
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 resolutions.
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're logged in, you
can click the star icon
to subscribe to all
updates posted on the bug.
Starting 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
[MUSIC PLAYING]
