►
From YouTube: Verify:Testing Group Think Big #7
Description
Today we think big about Code Quality, who has a problem this category could solve and how we could differentiate from competitors.
A
This
is
the
think
big
session
for
august
25th,
for
the
testing
group
today
is
the
think,
big
part
of
think
big
and
we're
going
to
be
talking
about
code
quality.
That
was
the
most
upvoted
of
the
think
big
issues
in
our
on
our
board.
When
I
took
a
look
on
friday,
so
let's
go
ahead
and
start
with
some
prompt
questions
in
here
of.
A
What's
the
problem
we're
trying
to
solve,
what's
the
job
to
be
done,
that
this
solves
I've
dropped
a
tentative
job
in
there,
but
no
problem,
because
I
didn't
get
that
far
into
my
brainstorming.
So
why
don't
we
start
with
the
problem?
What
problem
are
we
solving
with
code
quality,
or
could
we
solve
that?
We
aren't
today
with
the
code
quality.
A
B
I
at
a
at
a
high
level,
I
think
it's
it
can-
should
be
a
useful
tool
in
quantifying
technical
debt,
maybe
technical
debt
of
a
very
particular
kind,
but
I've
always
found
technical
debt
very
hard
to
quantify
and
articulate
and
like
recognize
and
have
there
it's
like.
This
is
a
problem
and
we
should
fix
it
and
we're
gonna.
You
know
pick
this
off
at
some
point
and
so
the
more
insight
a
tool
can
give
me
into
hey.
Remember
you
know
you
took
this
shortcut
like
a
year
ago.
B
The
more
can
keep
that
package
and
report
it
to
me
the
better.
So
I
can
so
I
can
show
to
other
people
like
hey.
This
is
important.
Remember
we
took
on
all
this
debt
like,
let's
not
forget
about
it.
C
I
think
james
froze,
but
I
agree
I
was
also
thinking
along
with
technical
debt.
It
also
helps
you
avoid
future
technical
debt
by
showing
you
on
your
merge
requests
like
hey
you're,
not
using
best
practices
that
we've
decided
on
as
a
team
to
to
use
for
this
code
quality
using
this
cut
quality
tool.
A
B
Technical
debt-
just
don't
do
it
sorry
go
ahead,
as
you
can
say.
So
how
do
you
think
the
things
that
you
are
talking
about
are
different
or
the
same
than
the
job
to
be
done
that
james
picked
out,
which
is
when
I'm
writing
code
for
a
project?
I
want
that
code
to
be
scanned
for
issues
like
duplication
and
not
following
standards.
So
it's
easier
to
read
by
others,
making.
B
Too,
I
think
the
james's
job
to
be
done
is
like
calls
out
stuff,
like
duplication
as
being
very
specific,
well
calls
out
things
like
duplication,
which
is
more
specific,
and
so
I
guess
the
more
kinds
of
quality
issues
we
can
capture
and
quantify
the
more
sophisticated
the
tool
will
be
and
the
more
of
your
debt
it
will
be
able
to
report
for
you.
D
D
I
think
the
so
clause
is
different
in
this
particular
category.
It's
so
I
can
make
better
decisions
about
the
code
that
I'm
trying
to
merge,
or
so
I
can
communicate
better
with
the
team
about
our
technical
debt
that
we've
taken
on,
or
so
I
can
manage
the
technical
debt
that
I
already
have.
A
You're
so
phrasing
in
that
and
there
is
that
all
as
the
developer
zeff.
D
Yeah
I
was
just
that
was
just
following
up
on
on
drew's
and
scott's
comments.
I
they
both
and
correct
me
if
I'm
incorrect,
but
it
seemed
like
you
all
were
applying
it
to
how
you
would
use
it
personally
as
a
developer
right,
or
did
I
not
get
that?
Okay,
yes,.
C
B
I
think,
speaking
from
like
a
manager
or
the
director
level,
I
think
the
individual
pieces
of
code
quality,
probably
matter
less
unless
they
are
like
security
vulnerabilities
or
like
this-
is
like
risk
like
as
soon
as
you
can
quantify
the
quality
of
the
code
in
how
much
risk
exists
in
the
code
base,
it's
probably
what
matters
more
to
the
director
or
the
the
manager
level.
So
if
there's
like
a
critical
security
vulnerability
that
the
code
quality
report
is
servicing,
that's
some
risk.
B
That's
something
that
I'm
going
to
care
about
as
a
manager
as
a
director.
But
if
it's
just
like
oh
well,
you
didn't
yoda
style.
Your
if
statement,
that's
like,
I
really
could
care
less
about
whether
you
yoda
style,
your
if
statement
or
not
the
other
thing
that
would
kind
of
bubble
up
into
risk
for
the
manager
and
director
persona
would
be,
if
there's
just
an
atrociously
huge
number
of
violations
in
the
code.
Quality
report,
like
I
kind
of
want
to
see
that
bird's
eye
view
of
like
okay.
B
B
That's
a
good
signal
to
me
that
we
need
to
spend
some
time
paying
down
that
technical
debt
so
that
we
can
move
forward,
particularly
when
I'm
looking
at
that
information,
in
conjunction
with
other
things
that
I
know
to
be
true,
like
the
mr
rate
for
that
project
is
lower
or
the
mean
time
to
merge
for
merge
requests
to
go
into
that
project
is
really
high
compared
to
other
projects.
B
Like
that's
one
data
point
that
I
can
use
to
try
and
explain
why
the
performance
of
that
project
or
the
performance
of
the
engineers
on
that
project
are
different
than
other
projects.
D
B
Think
I
would,
but
I
wouldn't
necessarily
that
wouldn't
be
my
only
data
point
right
like
there's,
there's
a
lot
of
other
things
that
I
would
consider
as
factors
as
well.
If
there's
another
team
that
was
doing
really
well
on
those
reports,
that's
probably
something
that
I'd
want
to
look
into
like.
Maybe
they
have
different
rules
to
find,
and
so
they're
not
they're,
just
ignoring
a
lot
of
these
different
things,
or
maybe
they
have
a
different
process
that
my
team
isn't
following.
B
So
I
can
see
what
they're
doing
differently
to
my
team
in
order
to
pick
and
choose
what
processes
I
can
use
that
would
best
help,
but
that's
also
not
everything
like
code
quality.
Isn't
everything
like
fundamentally,
what
any
business
probably
wants
to
do
at
the
end
of
the
day
is
make
money
and
if
my
project's
making
way
more
money
than
another
project,
but
there's
more
technical
debt.
B
B
And
I'm
not
saying
I
would
ignore
it.
I'm
just
saying
that,
like
that's,
the
the
priority
would
be
different.
I
don't,
I
don't
think
I
would
ever
look
at
code
quality
in
isolation.
It
would
just
be
one
of
a
number
of
factors
that
I'd
consider
when
looking
at
a
code.
B
C
Showing
to
investors
like
hey
just
another,
another
statistic:
to
show
our
code
base
is
this
large?
We
have
this
many
merge
requests
going
in
a
week,
but
still
our
code
quality
report
shows
that
it's
it's
a
very
high
quality
code
base,
even
though
we're
going
at
this
pace
just
another
statistic
to
add
to
the
investor
pitch
or
showing
showing
investors
that
we're
doing
well.
A
I
think
the
other
person
we
might
want
to
think
about
is
the
or
the
use
case
would
be
product
manager,
engineering
manager,
having
the
discussion
about
paying
down
tech,
debt
versus
new
features,
because
if
you
can
start
to
make
that
correlation
across
a
bunch
of
projects
in
a
group
of
these
projects,
have
low
code
or
have
high
code
quality
rather
and
high
mr
rates,
so
we're
able
to
contribute
to
them
faster
this
project
that
is
really
important
to
us.
Six
months
down
the
road.
A
We
need
to
start
paying
down
that
tech
debt
so
that
we
can
have
a
great
mr
rate
at
the
time
and
that
we
can
introduce
those
faster
features
faster.
I
think
that
it
can
contribute
to
that
conversation.
It
helps
a
product
manager
understand
if
you
see
those
two
data
points
together.
Oh
now,
I
see
why
I
could
quality
manners
by
tech
that
matters,
even
though
there's
not
bugs
or
there's
not
performance
problems.
If
it's
hard
to
contribute
to
a
code
base,
it
means
that
features
get
out
slower.
B
Yeah
I
I
like
that
too.
I,
like
scott's
kind
of
using
that
as
another
control
when
talking
about
speed,
because
I
think
that's
something
that
comes
up
a
lot.
It's
even
for
mr8
and
stuff,
like
that.
You
kind
of
want
to
have
a
controlling
statistic,
so
you're
not
just
totally
gaming.
The
system
right,
oh
well,
our
mr
rate's,
really
high,
but
our
unit
test
coverage
is
the
one
that
I
think
of
most
often
as
being
the
control
for
that.
B
It's
like
well,
our
mr
rate's
really
high,
but
we
also
have
really
high
code
coverage
and
then
having
another
control
and
our
code
quality
is
really
high,
as
defined
by
x.
I
think
that's
a
that's
a
good
call
out
by
by
scott
to
kind
of
have
that
controlling
statistic.
On
top
of
another
statistic,
that's
what
I
keep
I
keep
in
these.
In
these
conversations
I
keep
trying
to
articulate
that
like
I've,
never-
and
I
think
james-
you
hear
this
a
lot
from
customers
from
what
I
understand,
but
it's
it's
never
like.
B
I
just
want
that.
One
statistic:
it's
like
no!
I
want
to
see
these
10
things
together
and
then
I
want
to
interpret
how
what
that
says.
Like
I
want
to
okay,
I
see
my
mr
rate.
I
see
my
code
quality.
I
see
my
test
coverage,
I
see
my
ci
minutes.
I
see
how
long
it
takes
to
get
something
out
into
production,
and
then
I
can
kind
of
take
all
those
data
points
together
and
figure
out
what
my
next
steps
are
as
a
director
as
a
manager.
B
It's
like
okay,
but
like
what
goes
into
that
like
what
decisions
can
I
make?
Is
2.4
good
like
like?
What
do
I
need
to
change
in
order
to
get
that
to
2.8
like
that
score
by
itself
is
meaningless
until
you
have
like
some
a
blurb
at
the
bottom?
That's
just
like!
Oh
it's,
because
your
code
quality
is
so
poor.
You
need
to
up
your
code
quality
on
these
three
projects
to
bump
up
your
tpi
score,
but,
like
that's
still
like
what
does
tpi
even
mean
at
that
point,
you
know.
I
think
it's.
A
There's
some
personas
that
want
that
score
and
they
don't
necessarily
care,
but
that's
not
like
your
vp
of
engineering
or
chief
tech
officer,
is
presenting
to
the
board
showing
overall.
Like
the
you
know.
We
here
are
the
features
we've
released
and
then
here's
the
quality
of
our
code
base
and
then,
as
they
start.
As
you
start
drilling
down
into
meetings
of
direct
reports
and
direct
reports
and
direct
reports,
then
you
start
peeling
apart
the
layers
and
understanding.
A
Oh
well,
you
know
we
just
need
to
improve
our
code
coverage
in
our
code
quality
because
those
feed
into
that
larger
score.
Maybe
all
right
before
my
connection
drops
again,
I
feel
like
we
have
a
good
idea
of
the
problem.
Who
has
that
problem
or
is
doing
the
job
of
looking
at
this
code?
Quality
score.
B
I
think
we
covered
that
in
the
previous
section
we
kind
of
outlined
how
it
would
affect
ics
through
ems
and
directors
and
vps.
But
what
about
what
about
the
kind
of
non?
B
D
D
D
From
an
set
perspective,
I
don't
think
everybody
uses
it,
though.
So
if
it
is
there
and
it's
easy
to
access
and
easy
to
understand
that
that's
the
other
problem
the
scts
have
so
we
typically
have
one
sct
for
I
think
our
ratio
is
like
one
to
ten
right
now,
so
developers
might
work
on
they.
They
do
a
lot
but
they're
able
to
focus
on
on
some
key
features,
whereas
some
scts
have
to
focus
on
every
feature
and
understand
understand
at
that
level.
D
So
making
it
easy
to
easy
easy
to
digest
is
is
important
from
an
sct
perspective.
D
Because
that's
why
we
end
up
ignoring
things
sometimes,
so
we
just
don't
have
the
the
mental
bandwidth
to
do
all
that
context.
B
Interesting,
because
that
is
where
code
quality,
I
think,
would
more
inform
like
like
overarching
strategy.
You
know
it's
relatively
easy
for
me
as
a
developer
to
go
through
and
be
like.
Oh
these
are
violations.
I
can
fix
them
and
there's
you
know
green
on
charts
and
everything,
and
but
it's
code
quality
in
the
context
of
other
things
to
say
like.
Why
is
this
important
like
why,
as
an
organization
or
group,
are
we
going
to
focus
on
this
and
it's
because
it
translates
out
here
so
code?
B
Quality
is
important
for
this
or
not
important,
for
this
other
thing.
So
seeing
it
in
context
and
saying
like
what
code
quality
can
be,
what
code
quality
has
leverage
over
is
interesting
to
me.
A
D
I
think
you're
gonna
have
to
find
the
the
right
level
james
between
having
it
be
a
high
enough
level
number,
but
still
a
low
low,
a
low
enough
level
indicator
to
be
able
to
take
action
on
you're
gonna
have
to
look
at
this
and
be
able
to
walk
away
and
say
I
need
to
take
this
particular
action
on
it.
D
Just
having
a
one
key
number,
I
don't
yeah,
it
might
be
great
at
a
vp
level,
but
for
it
to
make
a
change
within
the
within
the
business.
People
need
to
take
action,
be
able
to
take
action
on
it.
B
That's
really
important
to
quality
and
managers
at
a
project
level,
and
then
it
seems
like
this
could
be
a
contributing
factor
onto
that
magic
project,
page
where
we
just
have
all
this
information
about
the
health
of
your
code
base,
but
also,
it
seems
like
we're
talking
about
having
that
next
level,
page
what
we
were
talking
about.
We
talked
about
this
a
lot
like
with
group
code
coverage
and
stuff
like
that,
where
maybe
we
need
that
magical
group
page
that
kind
of
rolls
everything
up?
B
Okay,
these
are
the
projects
with
the
they're
consuming
the
most
ci
minutes,
and
these
are
the
projects
with
the
lowest
code
quality,
and
these
are
the
projects
that
are
getting
the
highest
mr
rates,
and
this
is
their
code
quality
and
that
kind
of,
like
super
dashboard
of
the
numbers
that
we
think
are
important
to
keep
track
of
when
you're,
using
all
the
features
of
gitlab.
A
A
B
I
think
so,
but
I
also
think
that
that's
just
one
probably
I
don't
know
if
the
leading
or
a
lagging
indicator
of
of
of
the
problem
like
there
could
be
multiple
factors
that
contribute
to
the
problem
of
low
mr
rate
and
so
just
surfacing
that
one
indicator
on
a
page
like
if
we
had
like
a
code
quality
page
at
the
group
level.
I
don't
think
that
would
be
useful
in
isolation.
A
Yeah,
no
sorry
my
example
was.
I
can
start
to
pick
some
things
and
put
them
together
within
gitlab,
so
I
can
look
at
code,
quality
and
mre,
or
I
could
look
at
code,
quality
and
say
browser
performance.
Maybe
there's
a
correlation
there,
where
our
load
code,
quality,
results
in
low
and
slow
page
loads
or
load
testing,
and
we're
seeing
that
in
groups
where
they
have
a
high
code
quality
score.
They
also
have
great
performance
and
it
could
be
a
total
red
herring.
A
But
I
think
it's
interesting
to
give
your
manager
your
director,
some
drag
and
drop
ability,
maybe
to
say,
hey,
compare
these
two
things
across
my
groups
and
see
where
theirs
correlations
are
not
to
say,
there's
causation,
but
maybe
high
code
quality.
You
know
is
a
leading
indicator
of
or
contributing
factor
to
better
performance
of
either
the
team
or
the
software.
A
And
maybe
code
quality
isn't
the
only
input
on
that
left
side
of
that
there's
there
could
be
other
things
like
code
coverage
or
percentage
test,
passing
or
etc,
etc.
B
A
A
We
see
that
manifested
for
the
ic
in
my
code,
reviews
are
maybe
smoother
for
the
scts,
as
I
don't
have
to
maybe
pay
as
much
attention
and
really
test
around
the
edges
here,
if
there's
a
high
quality
score,
but
for
a
director,
then
what
does
that
mean
if
you're
tracking
the
quality
of
a
project
over
time?
A
Is
it
an
indicator
of
we
shouldn't
release?
This
is
an
indicator
of
hey.
Maybe
we're
going
to
have
bugs
in
the
future.
Are
there
other
signals
that
they
might
get,
or
is
there
another
outcome
or
really
whispering
cool
feature
that
they
would
want
out
of
a
quality
score,
we're
out
of
this
category?
Let's
back
away
from
score,
because
that's
just
kind
of
one.
B
So
if,
at
a
group
level,
you
knew
which
projects
contained
the
most
risk
due
to
potential
vulnerabilities
due
to
code
quality
due
to
rate
of
change
due
to
like,
if
something
doesn't
deploy
very
often,
but
it's
still
a
critical
business
function
and
the
code
quality
is
low
and
there's
a
cve
out
on
a
dependency
that
hasn't
been
updated
on
the
package.
I'm
going
to
look
at
that
as
a
director
or
manager
persona
and
be
a
little
bit
nervous
about
the
next
time.
We
have
to
go
and
release
that
to
production.
B
I
know
we
have
just
a
few
minutes
ago.
We
maybe
backed
away
a
little
bit
from
becoming
full-blown
psi
sense,
but
I
do
think
there's
something
to
be.
I
think,
there's
an
argument
for
the
a
customizable
kind
of
view
into
this,
because
I'm
not
sure
that
the
answer
is
going
to
be
the
same
for
different
groups.
B
You
know
gitlab
is
a
particular
organization
right
with
a
bunch
of
internal
contributors
and
external
contributors,
and
we
might
find
that
code.
Quality
for
us
is
a
huge
factor
in
time
to
merge
right
our
review
speed,
but
for
a
smaller
organization
that
might
not
matter
and
so
giving
we
might
have
to
give
a
group
the
flexibility
to
kind
of
figure
out.
You
know
what
does
code
quality
mean
for
you.
B
A
So
it's
I'm
brainstorming
about
seven
other
things,
none
of
which
fit
into
our
category.
They
fit
nicely
into
plan
or
create
or
release,
but
all
of
them
boil
down
to.
Wouldn't
it
be
great
if
some
of
the
signals
out
of
your
testing
and
your
static
analysis
were
able
to
be
used
in
other
parts
of
the
app
like
as
you're
estimating,
you
can
say,
hey
you're,
estimating
issues
in
a
project
that
has
really
low
code
coverage
and
a
really
low
code
quality
score.
Your
weights
might
need
to
be
higher
or
the
time
to
do.
A
These
issues
might
be
longer
and
that's
just
a
signal
at
the
project
level
or
the
same
thing,
on
a
release:
side
of
hey
you're
planning,
a
release
for
a
project
that
has
really
low
code
quality
but
really
high.
You
know,
coverage
or
really
high
coverage
and
really
high
churn,
something
like
that,
so
it
might
be
risky.
It
might
just
take
you
longer
and
it's
just
a
signal
that
we're
providing
out
to
those
other
parts
of
the.
A
C
A
B
D
I
think
drew
kind
of
touched
on
that
everybody's
going
to
be
using
this
data
differently.
It's
going
to
use
it's
going
to
mean
different
things
to
different
people,
so
I
think
the
first
step
might
just
be
just
provide
the
data.
These
are
the
failures.
These
are
the
things
that
are
that
we
are
uncovering
in
in
code
quality
and
everything
else
that
we're
doing
within
testing
what
it
means
to
you
is
up
for
you
to
decide.
B
I
think
we
do
already
do
that
with
like
the
full
quality
report
on
the
pipeline,
that
we
present
the
whole
thing.
But
how
can
I
make
that
more
meaningful
to
someone
who
wants
to
look
at
the
project
as
a
whole,
in
conjunction
with
other
factors,
as
opposed
to
okay,
I'm
going
to
click
on
the
cold
quality
report,
I'm
going
to
click
on
the
test
report,
I'm
going
to
go!
Click
on
this
thing
to
check
the
coverage
and
I'm
going
to
go.
B
A
Well,
we
are
almost
five
minutes
over
one
charge
to
rule
them
all
one
chart
to
rule
them
all.
Yeah
keep
pondering
on
that
drop,
some
ideas
for
what
that
outcome
might
look
like
into
the
issue
or
into
the
doc
it's
linked
in
there
and
we
can
iterate
on
those
over
the
week,
synchronous
or
asynchronously
and
come
back
next
week
to
talk
about
the
things
fall
part
of
this
and
if
we
end
up
on
something
totally
different
and
want
to
address
the
ic
instead,
we
can
totally
do
that
too.
So.
B
Yeah-
I
just
want
to
I
typed
something
in
here
yesterday,
but
I
think
it's
also
going
to
be
an
important
decision
to
make
whether
we
want
to
start
managing
state
of
the
code
quality
violations
in
the
product.
Like
do
we
want
to
take
a
step
towards
doing
what
sonar
cube
does
or
towards
doing
what
code
climate
does
as
a
as
an
application
where
you
actually
have
like?
B
Maybe
we
create
issues
out
of
it,
and
then
we
track
the
fingerprint
in
the
report
to
the
issue
so
that
when
that
issue
gets
closed,
we
can
kind
of
like
wrap
everything
up
into
a
nice
bow.
Is
that
like
where
we
want
to
go?
Do
we
want
to
turn
git
lab
into
the
stateful
code?
Quality
management
platform,
or
you
want
to
do
the
opposite
thing
and
encourage
them
to
set
up
their
own
stateful
code
quality
thing
and
then
set
up
integrations
there.
A
I
think
we
have
an
opportunity
to
leverage
hosting
the
source
and
being
the
ci
to
do
the
former
of
be
an
all-in-one.
B
On
the
latter
option,
it
would
probably
be,
I
think,
if,
if
we
just
kind
of
acted
as
the
aggregator
and
sat
on
top
of
all
these
existing
tools
and
offered
a
little
bit
of
guidance
on
here's,
how
you
can
use
sonar
cube
like
here's,
what
that
might
mean
to
you-
and
you
know
it
we're
going
to
help
you
figure
out-
that
sonar
cube
is
actually
important
to
your
organization.
And
it's
worth
this
much
to
you
or
that
your
code,
climate
report
is
not.
B
You
know
like
what
does
it
mean
for
me
to
high-level
people?
I
think,
could
be
a
really
interesting,
a
really
valuable
tool
to
the
like
buyer
personas
that
we're
going
after
in
paid
groups.
A
All
right:
well,
we
will
end
on
that
note.
Yeah
continue
to
drop
thoughts
into
the
docking
issue.
Sorry
for
going
over.
Thank
you
for
hanging
on
and
continuing
the
discussion.
This
was
a
good
one.