►
From YouTube: Verify:Testing Category walk through April 2021
Description
A walkthrough of some of the current capabilities of the Testing Categories, what tiers they are available at and the near term roadmap for the Testing Features as of April 2021.
A
Hi,
I'm
james
eibach,
the
product
manager
for
the
verify
testing
team
at
gitlab.
Today,
I'm
walking
through
a
deck
that
I
put
together.
I
just
has
an
overview
of
the
group,
some
of
the
features,
the
categories
that
we're
responsible
for
where
we're
at
today
and
where
we're
going
in
the
not
so
distant
future,
so
just
want
to
start
with
the
mission
for
the
testing
group.
Verify
testing
group
provides
an
automated
testing
integration
into
git
lab.
A
A
So
our
vision,
long
term,
where
we
want
to
get
to,
is
that
a
developer
can
commit
code
and
have
that
code
into
production
in
an
hour
or
less
from
the
time
of
the
first
commit
to
the
mr.
We
think
that
by
presenting
data
from
unit
tests,
performance,
accessibility,
testing,
etc,
etc,
that
we
can
support
that
shorter
cycle
time
and
continuous
feedback
for
developers.
This
will
reduce
operational
costs
and
complexity
and
we
can
also
surface
data
to
managers,
directors
vps.
The
overall
quality
of
the
projects
that
we
collect
as
part
of
those
runs.
A
So
we
talk
a
little
bit
about
the
jobs
to
be
done.
We
talk
primarily
about
jobs
that
software
developers
need
to
do
and
that
dev
team
leads
need
to
do
day
to
day
things
like
review,
test
results
or
review
the
static
quality
analysis
scans,
compare
accessibility
of
their
app
from
before
they're
changed
after
their
change.
These
are
all
things
that
developers
need
to
do
day
to
day
to
ensure
that
they
have
that
confidence
and
their
change.
A
A
At
the
project
level,
you
can
see
historically
how
test
coverage
has
changed
within
the
project
as
well
as
at
the
group
level,
and
you
can
also
start
to
visualize
that
within
mr
diffs
of
if
a
code
change
is
covered
by
a
test
or
not
within
code
quality,
we
allow
you
to
review
code
quality
changes
again
within
the
merge
requests
or
within
the
pipeline.
We're
going
to
be
introducing
soon
a
feature
that
expands
on
that
I'm
excited
to
talk
about
later
in
the
in
the
video.
A
A
So
I
want
to
talk
a
little
bit
about
where
we
offer
value
across
the
tiers
within
gitlab
within
the
free
tier
we
offer
to
developers
a
lot
of
those
capabilities
within
the
merge
request.
I
can
see
how
accessibility
code
quality
test
results
are
changing
because
of
my
change.
Compare
that
against
the
branch
I'm
going
to
merge
into
and
then
team.
These
can
track
that
test
coverage,
how
it
is
changing
over
time.
All
of
those
are
enabled
at
the
free
tier
and
available
to
everybody.
A
If
you
move
up
to
premium,
then
developers
can
start
to
see
how
load
testing
browser
performance
testing
is
changing,
adding
in
those
capabilities
and
seeing
that
within
the
merge
request
and
also
recording
custom
metrics.
If
you're
looking
at
things
build
to
build
to
build
a
gem
size
is
one
that
our
team
looks
at.
That
is
a
feature
that
comes
to
you
in
the
premium
tier
and
then
directors
team
leads
can
start
to
track
test
coverage
within
all
of
the
projects
of
a
group.
So
you
can
start
to
see
at
the
group
level.
A
A
Developers
are
going
to
be
able
to
review
code
quality
changes
in
the
mr
diff.
This
is
one
I'm
excited
about
and
is
going
to
be.
Releasing
soon
our
first
iteration
shows
that
a
file
has
a
change,
and
our
second
iteration
will
show
that,
in
line
in
your
mr
diff,
there's
no
more
bouncing
back
and
forth
as
a
developer
between
the
test,
summary
widget
or
the
code
quality
widget
and
the
mrdiff.
U
to
see
hey,
has
this
change
also
modified
code
quality?
It's
simply
looking
at
it.
A
On
the
mr
diff
page,
seeing
this
line
that
has
been
changed
has
a
new
code
quality
violation
that
can
help
inform
you
as
you're
doing
your
review.
What
how
that
needs
to
be
fixed,
how
we
can
improve
that
change
and
further
down
the
delay
further
down
the
line
directors,
we
want
to
be
able
to
review
the
overall
quality
of
a
project
tracking
those
changes
over
time.
Things
like
test
coverage
over
time
code,
quality
over
time,
text,
execution
history
over
time.
A
So
our
near-term
roadmap,
now
we've
already
talked
about
the
team,
is
currently
working
on
as
of
today
april
12th,
getting
those
code
quality
violations
into
the
mrdifu.
The
next
thing
that
we're
going
to
be
jumping
into
is
improving
that
code
quality
experience
by
letting
teams
customize
which
violations
they
see.
If
I
don't
care
about
any
of
the
informational,
I
don't
want
to
show
that
as
part
of
my
full
report
or
my
merge
request
of
view,
it's
just
noise
to
our
developers
and
slows
down
our
cycle
time.
A
We
also
want
to
be
able
to
block
that
merge.
Using
our
merge
request
approvals.
If
quality
is
degraded,
the
code
quality
violations
have
increased
or
test
coverage
is
degraded.
If
I
see
an
increase
or
decrease
rather
in
the
percentage
and
test
coverage.
Because
of
this
change,
it
needs
to
be
approved
or
it's
a
blocked,
merge
request
and
letting
teams
that
are
using
those
rules
apply
them
to
this,
as
well
as
security
and
license
compliance
later
down
the
line.
A
A
So
that
you
can
start
to
get
a
hint,
is
this
a
flaky
test,
or
is
this
something
that
really
I
need
to
go
address,
and
then
that
view
of
overall
project
quality
being
able
to
look
at
a
dashboard
to
see
hey,
you
know,
is
test
coverage.
Changing
over
time.
Is
our
code
quality
changing
over
time
and
in
which
direction
is
that
change
going?