►
From YouTube: Verify:Testing 12 month direction Oct 2020
Description
Walking through the themes for the next 12 months the Verify:Testing team specific to the Code Quality and Code Testing and Coverage categories.
Code Quality: https://about.gitlab.com/direction/verify/code_quality/
Code Testing and Coverage: https://about.gitlab.com/direction/verify/code_testing/
A
Hi,
I'm
james
heinbeck,
the
product
manager
for
the
verified
testing
team
at
gitlab.
Today,
I
want
to
run
through
a
little
bit
of
our
direction
for
some
of
the
testing
categories
over
the
next
year.
These
are
updates
that
I'll
start
to
provide
quarterly
to
give
some
headlights
into
what
we're
looking
at
over
the
next
12
months,
so
go
ahead
and
share
my.
A
Screen
and
we're
going
to
start
today
on
the
code
quality
category,
so
we
have
a
couple
of
themes
that
we're
looking
at
in
the
near
term
and
the
long
term.
The
first
theme
is
moving
this
category
to
more
of
a
viable
state
for
developers,
specifically
that
persona
and
we
track.
You
know
maturity
for
our
categories.
A
Currently,
the
category
maturity
for
code
quality
is
at
minimal,
and
so
there's
a
couple
of
problems
that
we
know
we
need
to
solve
to
really
make
this
more
of
a
viable
feature
set
for
the
developer
persona
and
really
work
it
into
their
day-to-day
workflow.
So
the
three
problems
that
we're
targeting
are
issues
being
presented
really
without
any
context
of
severity
in
the
ui
and
really
low
severity
issues
mixing
in
and
creating
noise
in
the
mix.
A
So
as
you
look
at
our
maturity
plan,
you'll
see
issues
here
that
call
out
and
look
to
solve
some
of
those
problems,
at
least
in
a
minimal
state,
we're
looking
forward
to
iteration
on
these
and
feedback
on
the
issues
themselves
and
we'll
be
making
use
of
feedback
issues.
If
you
want
to
leave
comments
there
after
a
feature
has
been
launched
and
tell
us
really
what
the
next
iteration
should
be
and
how
we
can
better
solve
these
problems.
A
The
second
theme
is
to
provide
trending
quality
data
to
both
managers
and
directors,
as
we
think
about
some
of
the
other
personas
that
make
use
of
this
feature
set.
So
this
area
is
less
clear
for
us
right
now
and
we're
actively
looking
for
feedback
around
some
of
the
problems
and
proposed
solutions
to
these
problems,
but
based
on
our
initial
discussions
with
managers
and
directors,
we
do
understand
that
we
have
the
following
problems:
that
we
can
go
out
and
solve
today.
A
So
we
know
that
directors
can't
easily
compare
any
sort
of
quality
score
of
projects
within
their
group
to
see
where
maybe
more
investment
in
paying
down
tech
debt
might
need
to
occur,
and
then
team
leads
really
can't
tell
as
they're
improving
their
quality,
how
it's
trending
over
time.
So
it's
really
just
anecdotal
or
digging
into
pipelines
to
get
that
data
today.
A
So
it's
hard
to
tell
if
you're,
making
an
investment
in
quality
if
it's
really
paying
off
so
looking
even
further
out,
we
see
potential
in
a
quality
dashboard
of
sorts,
similar
to
what's
being
provided
by
the
security
team
and
the
security
feature
set
in
gitlab.
Today,
you
can
see
some
rough
designs
for
this
on
our
direction
page.
A
This
design
came
out
of
a
brainstorming
session
with
the
team
and
with
our
product
designer
it's
really
not
tied
to
any
specific
issues
today
or
any
future
work.
This
is
really
just
a
future
vision
of
where
we
think
we
want
to
go,
but
we
do
think
that
some
of
the
bits
of
this
are
going
to
get
pulled
into
issues.
We
really
love
this
vision,
looking
forward
of
how
you
can
look
at
quality
holistically
across
the
product
across
your
projects
across
your
groups
to
see
how
things
are
trending
over
time.
A
A
After
that,
first
step,
we
really
want
to
provide
this
data
at
the
project
level.
We
think
that's
the
next
step
that
makes
sense
so
that
a
quality
lead
or
a
dev
lead
can
more
easily
spot
tests
that
are
failing,
often,
which
is
probably
indicative
of
them
being
flaky
tests
and
just
unnecessarily
having
to
rerun
a
pipeline
to
get
a
test
to
pass.
That's
a
lot
of
time
that
can
be
used
by
a
developer,
to
do
a
code,
review
or
write
new
code
and
get
those
features
out
into
production.
A
So
the
second
theme
is
providing
visibility
into
test
history
for
groups
so
again
surfacing
that
data
up
from
across
projects
as
part
of
a
group.
We
know
there's
some
areas
to
be
solved
or
some
problems
to
be
solved
here
and
we're
exploring
which
one
we
think
is
going
to
have
the
highest
impact
for
users.