►
Description
Walk through the updates made to Maturity Plans for the Testing Categories from Aug 2021.
Maturity Page: https://about.gitlab.com/direction/maturity/#verify
Category Maturity Scorecard info: https://about.gitlab.com/handbook/engineering/ux/category-maturity-scorecards/
A
Hey
I'm
james
heimbuck,
the
product
manager
for
the
verified
testing
team
at
gitlab.
Today,
I
want
to
walk
through
some
of
the
recent
maturity
updates
that
I
made
to
the
categories
and
kind
of
walk
through
the
plan.
That's
gonna
get
us
there
so
because
I'm
posting
this
publicly
sharing
this
this
is
all
related
to
upcoming
products,
features
functionality.
It's
important
to
note.
A
It's
presented
for
informational
purposes,
only
don't
rely
on
this
for
any
purchasing
or
planning
purposes
and
as
with
everything
all
of
the
gitlab
projects
I
was
mentioned
in
this.
Video
linked
pages
are
subject
to
change
or
delay.
The
development
release
and
timing
of
any
products
features
or
functionality
do
remain
at
the
soul,
discretion
of
gitlab.
A
So
a
little
bit
of
background
every
month,
the
team
reviews
the
maturity
plans
and
adjust
dates
accordingly.
So
we
just
went
through
that
process
after
14.2
is
released.
Here
is
the
diff
of
our
changes
that
are
coming
up
so
performance
testing,
browser
testing,
load
testing.
I've
shifted
the
date
on
that
out
into
october
of
2022
from
april
usability
testing
to
july
of
2022
and
accessibility
testing.
A
All
the
way
out
into
january
of
2023
so
today
in
our
walkthrough,
we're
really
going
to
be
focused
on
the
usability
testing
and
code
testing
and
coverage,
because
those
are
the
next
two
things
looking
to
move
so
on
the
maturity
page
and
I'll
link
to
this
in
the
video
you
can
see
kind
of
where
we're
at
today.
I
took
the
screenshot
yesterday
of
what
the
current
maturity
of
all
of
these
are
continuous
integration.
Part
of
the
verify
stage,
is
it
complete,
co-testing
and
coverage
is
viable
and
usability.
A
Testing
that
we're
focused
on
today
is
at
minimal,
meaning
we've
introduced
the
category,
and
that
is
about
it.
So
we're
looking
at
moving
code
testing
and
coverage
to
complete
by
july
of
2022
and
usability
testing
to
viable
by
that
same
quarter.
So
I
wanted
to
talk
through
what
it's
going
to
take
to
get
that
to
happen.
So
we
use
a
scoring
maturity
or
a
scorecard
to
do
this.
So
it's
not
just
the
whim
of
product
managers
of
what
is
the
maturity
of
your
category.
A
So,
looking
at
complete
for
the
code,
testing
and
coverage
git
lab
the
company
dog
foods,
it
exclusively,
which
we
do,
we
utilize
our
testing
and
coverage
functionality
very
very
well.
There
are
some
bits
and
pieces
that
the
quality
team
uses
that
are
bolt-ons
that
are
add-ons
third-party
tools
that
we'll
be
looking
at.
So
we
meet
that
criteria.
I
think
at
least
100
customers
use
it.
A
So
what
do
we
need
to
do
to
get
there?
Well,
we'll
just
walk
through
it
a
little
bit.
We
have
done
a
gitlab.
The
company
does
dark
boot
exclusively
the
code
testing
and
coverage
functionality.
We
do
have
100
customers
using
it.
We
do
need
to
do
the
scorecard
part
and
part
of
that
there's
two
to-do's
within
it.
We
need
to
validate
those
traditional
jobs
to
be
done.
That
is
going
to
take
some
time.
A
A
What
we
have
found
historically
is
that
each
of
those
take
at
least
a
quarter
to
do
so,
we're
looking
at
approximately
half
a
year
just
to
complete
that
research.
That's
part
of
the
reason
that
this
is
so
far
out
just
trying
to
plan
in
the
future
a
bit
then
usability
testing
moving
that
from
minimal
to
buyable
to
do
significant
use
of
gitlab.
I
think
that
there's
some
opportunity
for
us
to
introduce
this
into
the
release
post
process
of
adding
comments
on
mrs
from
that
review,
app
and
then
within
docs
as
well.
A
Potentially
I
want
to
talk
to
the
designers
about.
Will
that
count
as
significant
use
at
gitlab,
because
we
know
in
our
discussions
with
kyle
and
the
engineering
productivity
team,
the
other
challenges
that
go
into
review
apps
when
it
comes
to
using
it
on
the
main
gitlife
project
itself,
but
for
things
like
handbook
things
like
release
post,
I
think
there's
a
big
opportunity
for
us
there
and
then
the
category
maturity
scorecard
of
the
main
jobs
to
be
done
again.
Breaking
that
down.
We
need
to
validate
that
main
job
to
be
done.
A
A
So,
breaking
that
down
further
a
little
bit
quarterback
quarter
in
the
current
quarter,
we're
in
august
of
2021
and
I'm
looking
at
this
from
a
calendar
year
perspective
not
fiscal
year,
we're
doing
research
for
the
jobs
to
be
done,
or
I
will
be
working
on
reviewing
the
job
to
be
done
for
code
coverage,
code
testing
and
coverage
in
this
quarter.
A
We're
going
to
need
to
do
some
additional
job,
maybe
done
validation
in
the
next
quarter,
so
I'll
tee
that
up
with
gina
and
our
ux
researchers
and
we'll
be
building
out
the
project
quality.
Summary
we've
previously
identified
that
as
one
of
the
things
that's
preventing
us
from
getting
from
viable
to
complete
and
then
looking
ahead
into
yeah
february
through
april
of
2022.
My
years
are
all
starts
off
project
test
results
summary
or
that
chacoco
parsing,
looking
at
the
opportunities
that
they're
out
there
and
what
is
going
to
drive
additional
usage
of
this
category.
A
Those
two
things
seem
to
be
the
tops,
so
we'll
be
right,
scoring
those
doing
a
little
bit
of
light
validation
on
the
opportunities
making
sure
we
are
choosing
something
that
we
can
move
on
and
that
really
solves
problems
for
our
users
and
then
looking
ahead
into
may
of
2022
is
when
we'll
be
doing
the
category
maturity
scorecard
with
those
external
users.
So
it
gives
us
that
full
quarter
to
do
the
research
recruit
find
folks
do
things.
A
This
is
all
a
kind
of
best
case
scenario
that
all
of
this
works
out
that
we
do
the
research
we
find
what
we
want,
but
there's
not
curveballs
in
it.
This
could
result
in
we
didn't
score
where
we
wanted
to
on
the
scorecard
in
july
of
2022,
and
we
don't
move
the
maturity
forward.
But
hopefully
this
is
the
plan
or
following
this
plan
will
get
us
there
and
then,
similarly,
for
the
usability
testing
for
minimal,
viable
gina,
like
I
mentioned,
is
doing
the
jobs
to
be
done.
A
Review
with
internal
users
now
we'll
be
continuing
that
probably
into
november
and
into
that
following
quarter.
This
is
two
quarters
worth
of
time
so
well,
this
research
part
will
probably
wrap
up
an
early
part
of
that
and
then
we'll
build.
We
don't
know
what
we
need
to
build
for
those
internal
users
of
understanding,
what's
preventing
them
from
using
this
as
part
of
that
process.
So
that's
what
some
of
that
research
is
and
some
other
exploratory
research
that
we'll
be
working
on
in
understanding.
Why
don't
we
use
visual
review
tools?
A
The
main
feature
in
the
category
today,
alongside
with
us,
which
we
use
heavily
when
it
comes
to
release,
post
and
handbook
changes
and
then
may
through
july
of
2022,
is
when
the
research
and
the
category
maturity
scorecard
will
happen
again
with
internal
users.
So
the
recruiting
shouldn't
be
as
bad
and
that's
what
should
get
us
to
the
maturity
maturity
that
we
have
set
out
and
the
targets
that
we
have,
and
so
that's
the
process
that
we
go
through
every
month,
just
looking
at
hey.
A
What
do
we
need
to
get
done
between
here
and
there
is
there
enough
time
to
do
it
or
does
that
align
with
our
other
priorities?
So
that's
the
process
that
we
go
through.
I
just
thought:
I'd
better
document
it
this
time,
put
a
little
more
thought
into
it
and
record
this
video.
If
you
have
any
questions,
you
can
contact
me
at
jheimbug,
underscore
gl
gitlab
or
jayheimbug
heimbach
gitlab.com
through
email
thanks.