►
Description
Today's think small continued our discussion from thinking big about how to enable Testing features by default for customers or make them easier to use.
Think Big: https://www.youtube.com/watch?v=HmNosq4MsK0&list=PL05JrBw4t0Kq53VUOvTk3VdXN79PA0SXT&index=2&t=267s
A
This
is
the
verify
testing
think
small
for
march
9th
we're
wrapping
up
the
topic
around
enabled
by
default
for
testing
features.
So
a
quick
recap
from
last
week
and
I'll
put
the
recording
in
the
comments
below
this
recording.
We
talked
about
a
few
different
ways
of
getting
users
started
with
testing
features
automatically.
A
Some
of
the
things
that
I
pulled
out
of
our
discussion
were
just
better
automatic
enablement
of
testing
features
that
require
little
to
no
setup.
So
I
thought
about
categories
like
code
quality,
browser
performance,
accessibility,
you
don't
have
to
write
a
test
to
test
or
to
run
those
tests
and
run
those
jobs,
and
you
can
get
data
back
out
of
them
and
then
running
smoke
tests
automatically.
A
We
had
a
really
great
discussion
about
how
we
can
detect
things
in
a
project
and
create
or
open,
mrs,
that
would
allow
you
to
start
to
utilize
some
of
the
testing
features
or
even
do
things
like
hey.
You
have
a
profile,
let's
start
the
app
for
you
and
just
validate
that
it's
up
and
do
that
as
a
kind
of
new
smoke
test
kind
of
feature
to
get
you
started.
A
A
A
So
if
they
want
to
start
to
dig
in
and
figure
out
hey
what
else
could
I
start
to
add
to
my
project
feel
free
to
link
through
to
that,
but
I
want
to
jump
into
our
first
question
of
as
we
move
towards
that
larger
goal
or
that
bigger
vision
of
hey
testing
stuff
just
works.
For
me.
What
is
something
that
we
could
do
in
our
next
milestone
that
moves
us
a
little
bit
closer
to
that
goal,
especially
around
the
second
bullet
point
talking
about
the
first
better
automatic
enablement.
B
James
during
the
week,
either
yesterday
or
last
week-
I
don't
remember
you
brought
up-
you
brought
up
a
tool
in
slack
that
does
something
kind
of
similar
here
it
was
like
an
automatic
like
mocking
and
testing
library.
That
sort
of
is
like
the
api
testing
infrastructure
as
a
service
kind
of
thing.
The
I
think,
broadly
one
of
the
smaller
things
we
could
do
is
find
an
existing
tool
to.
B
I
mean
this
is
sort
of
a.
This
is
a
second
part
of
it.
There's
find
an
existing
tool
and
then
automatically
apply
it
to
people's
projects,
but
I
think
there's
certain
kinds
of
tools
like
that
that
are
sort
of
amenable
to
being
thrown
on
and
just
saying
yeah
you
can
do
it.
You
know,
there's
there's
a
zero
configuration
path
to
getting
started,
and
so
we
could
yes
wire
mock.
Thank
you.
We
could
kind
of
start
with.
I
don't
even
know
what
we'd
implement
here,
but
essentially
start
with
sort
of
figuring
out.
B
B
B
B
That
yeah,
I
I
agree
and
like
on
that
same
line
of
thought,
it'd,
probably
be
easiest
to
look
for
a
similar
tool
to
wiremock
that
just
kind
of
plugs
into
a
swagger
or
open
api
definition
that
that
way,
it
seems
like
wiremock,
had
a
bit
more
of
manual
setup
where
you'd
have
to
set
the
requests
and
expectations.
It
looked
like
java,
but
I
didn't
look
too
far
into
the
docs
and
and
something
like
swagger
open
api
just
has
the
the
yaml
definition
of
the
api
endpoints
and
the
expectations
for
them.
B
B
A
I
mean
I
think,
that,
trying
to
collect
thoughts
if
we
implemented
a
new
feature
that
was
or
implement
a
new
functionality.
That's
targeted
at
api
testing
say
we
see
you
have
an
endpoint
or
even
you
have
a
open
api
or
a
swagger
definition
file
as
part
of
your
project,
great
we're
going
to
grab
it
and
use
it,
and
just
make
sure
that
the
endpoints
that
you
describe
except
accept
a
get
and
output
that
as
junit,
something
that
it
fits
into
an
existing
bit
of
functionality
for
us.
A
I
think
stepping
back
and
trying
to
answer
drew's
question
of
I
don't
know
what
that
list
would
look
like
would
be,
let's
just
list
out
some
of
the
possible
ones.
Maybe
that's
the
first
thing
of
hey:
are
there
already
a
ton
of
projects
out
there
with
swagger
definition
files
in
them,
or
are
there
a
ton
of
projects
that
we
can
figure
out?
They
use
review,
apps
or
you
know,
publish
so
there's
a
staging
webpage
somewhere
that
maybe
we
could
hit
just
to
see
if
it
returns.
Things
like
that.
B
And
it
it
could
be
something
like,
like
I
know
in
our
spec
there's
a
way
to
write
configuration
to
hook
into
all
the
requests
that
our
spec
handles
in
your
integration
tests.
So
that's
a
specific
place
where
I
know
that
we
could
just
hook
into
a
test
suite
and
start
automatically
doing
things
for
people,
so
we
could
potentially
generate
genuine
artifacts
without
asking
them
and
start
generating
reports
and
just
showing
it
to
people.
B
B
What
can
we
do
to
make
our
features
just
easier
to
use
so
like,
if
the
more
we
iterate
toward
removing
steps
for
people
to
set
up
our
features,
the
closer
we
get
for
them
to
just
kind
of
working
anyway
right
like
if
we
can
take
some
of
these
down
to
one
step
enablement,
then
what
do
we
have
to
do
after
that?
To
get
it
to
zero
step
enablement?
It
would
probably
be
more
clear
at.
A
That
so
a
couple
of
different
tracks
there
of
maybe
some
new
functionality
that
gets
us
closer
to
our
vision,
maybe
some
existing
functionality
that
we
simplify
set
up
for.
I,
like
that
one
step
then
zero
steps,
because,
if
we're
at
zero
steps,
then
including
an
auto
devops
makes
it
super
dead.
Simple
of
I
just
get
six
testing
features
for
free.
If
I
use
auto
data
box.
B
C
B
Yeah,
I'm
I'm
kind
of
hesitant
to
put
a
lot
of
eggs
in
that
basket
at
the
moment,
just
because
it
seems
like
it's
a
bit
up
in
the
air.
I
I'd
prefer
to
make
steps
that
kind
of
further
our
own
direction,
without
tying
it
directly
to
autodevops
until
it
becomes
clear
that
that's
the
the
you
know,
and
again,
that's
just
my
suggestion.
That's
totally.
C
It
doesn't
have
a
lot
of
value,
though
right.
Hopefully
I
I
like
my
hope
is
that
we
are
investing
more
in
it
than
less
so.
I
think
it's
good
to
check
that
out,
because
you
know
point-and-click
ci
cd
templates
or
go
hand
in
hand
with
what
you're
talking
about
right
here.
As
far
as
usability
and
ease
of
use,
right
kind
of
like
you're
talking
about
like
a
switch,
you
can,
you
know
hey
if
we
could
just
flip
this
code,
quality
switch
and
then
you
know
the
lights.
All
turn
on.
C
B
A
B
Quality,
I
think,
is
the
easiest
one,
but
it's
also
the
hardest
one
on
our
infrastructure
side,
if
you
know
what
I
mean
like
with
docker
and
docker,
and
it
takes
a
while,
if
you're
not
using,
if
you're,
using
a
shared
runner
to
do
it,
so
it
it
it's
the
I'm
still
kind
of
torn
between
getting
that
super
linter
up
and
running
as
a
prerequisite
for
going
down
the
code
quality
path.
Just
so
that
we
have
something
that's
a
bit
more
flexible
and
doesn't
require
docker
and
docker.
D
I
know
last
week
we
talked
about
giving
them
like
a
free
number
of
ci
minutes
for
things
like
code
quality,
just
to
see
if
they
find
it
useful
at
first,
like
a
trial
kind
of
thing,
because
the
what
we
don't
want
to
do
is
automatically
add
code
quality
and
add
all
these
things
that
are
taking
up
their
ci
minutes
immediately
and
then
like
as
soon
as
they
import
a
project.
It's
just
they're
done.
They
don't
have
any
more
ci
minutes
that
month,.
B
B
B
D
D
B
A
If
we
get
like
looking
down
the
road,
if
we
get
to
more
of
a
combined
quality
widget,
that
includes
some
of
the
various
scans,
that
we
run
that
once
we're
taking
up
that
real
estate
and
maybe
not
expanding
on
it,
as
you
run
more
scans,
that
might
be
a
place
where
we
can
say
hey
looks
like
you
have
review
apps,
you
should
run
accessibility
or
you
should
enable
visual
review
tools
and
here's
how
to
do.
It
would
be
a
way
to
go.
If
we
on
the
pipeline
page,
do
we
sh?
A
I
can't
remember
if
we
show
the
test
page
if
they
don't
have
any
tests,
but
if
we
do,
because
that's
just
a
tab
along
there,
we
could
do
something
like
that
and
say
like
looking
at
your
gitlab
ci
yaml,
it
looks
like
you
generate
test
data
click
here
to
open
nmr
in
your
gitlab
ci
yaml.
That
will
enable
this
tab.
That
might
be
that's
not
the
smallest
thing
we
could
do
probably,
but
that
might
be
a
step
in
that
direction,
to
see
if
there's
appetite
for
turning
a
feature
like
that
on
more
broadly.
D
B
That
seems
like
a
pretty
good
opportunity
to
just
put
a
link
in
there
because,
like
that,
that
brings
awareness
to
the
feature
right-
people-
oh
tess,
what's
that
and
they
click
on
it.
It's
just
like
there
are
no
tests.
They're
gonna,
be
like
okay.
Well,
how
do
I
get
stuff
to
show
up
in
there
right?
It's
kind
of
not
answering
the
implicit
question
that
somebody
might
have
when
they
come.
A
A
B
Oh
yeah,
this
just
seemed
to
align
with
some
of
the
like
corrective
action
linking
that
we
had
talked
about
on
widgets.
You
know
it's
like.
Oh,
you
have
code
quality
configured,
but
it's
not
showing
up
here.
We
can.
We
know
why
click
here
and
we'll
fix
it
kind
of
thing
or,
like
you
know,
start
with
here's,
how
to
fix
it
and
then
automatically
fix
it.
Just
that
same
idea,
the
problem
might
be.
You
haven't
configured
code
quality
instead
of
you
know,
you've
configured
code
quality
and
it's
not
here.
B
A
All
right,
we
are
quickly
hurtling
towards
the
end
of
our
time.
I
want
to
make
sure
that
we
at
least
acknowledge
these
other
questions
here
the
hardest
part
of
the
problem
to
solve.
I
think
we
covered
some
of
that
of
where
to
start
in
the
myriad
of
places
where
we
can
introduce
some
quality
and
then
yeah.
I
think
that
that's
probably
it
or
you
could
debate
that
of.
Can
we
just
make
these
things
discoverable
and
then
the
riskiest
assumption
that
we've
made
is.
I
think
that
people
actually
want
this.
A
If
we
look
back
at
where
we
started,
we
started
with
one
customer
interview.
It
was
a
great
customer
interview.
They
had
a
lot
of
great
data
for
us,
but
that
is
one
anecdote,
and
that
could
be
just
that
one
customer's
feeling
and
nobody
else
is
feeling
that.
So
I
think
that
would
be
the
riskiest
assumption,
but
I
think
that
some
flavor
of
what
we've
identified
around
hey-
we
already
have
ui
and
there's
nothing
there.
A
A
So
I
will
write
up
an
issue
that
describes
some
of
what
we
talked
about,
that
we
can
iterate
on
before.
We
actually
schedule
it
for
a
milestone,
but
with
the
goal
of
scheduling
it
in
one
of
the
next
couple,
upcoming
milestones
and
potentially
work
with
growth
on.
How
do
we
measure
this?
How
do
we
run
this
experiment
to
see
if
it's
something
that
we
should
continue
to
move
forward
with.
B
I
think
we
have
a
lot
of
very
small
actionable
tasks
that
we
can
kind
of
tack
on
and
a
lot
of
it
is
front-end
work
that
is
unblocked
by
back-end
work.
So
it's
stuff
that
we
can
just
kind
of
go
and
get
done,
and
then
they're
pretty
low
risk
and
pretty
pretty
small
changes
like
adding
a
link
here.
They're
tightening
up
the
the
ux
with
some
of
our
features,
and
I
think
those
things
if
we
had
tracking
could
be
a
a
great
indicator.
I
really
like.
A
Awesome,
well,
I
will
make
a
plug
go
into
the
list
of
all
of
the
think
big
issues.
If
you
don't
see
a
topic
you
want
to
talk
about,
please
add
one.
If
you
do
see
topics
you
want
to
talk
about,
give
them
thumbs
up
comment.
Edit,
add
some
content
there
that
we
can
jump
into
the
next
topic,
and
I
think
that
our
next
one
is
just
in
a
couple
of
weeks.