►
From YouTube: Product Planning: Test Session Overview
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So,
for
contact's
sake,
I'm
awesome
a
product
designer
here
at
git
lab
this
is
mec
director
of
quality,
mac,
cable's,
awesome
idea
for
test
sessions,
and
this
little
working
group
we're
going
to
have
together
today
is
just
to
talk
about
that
and
the
mvc
idea
they
kind
of
generated
and
for
me
to
ask
some
clarifying
questions,
because
I'm
not
well
informed.
B
Thank
you
for
reaching
out
austin,
and
yes
this
to
to
highlight
this
meeting
is
about
test
sessions
and
it's
a
a
key
component
in
in
many,
not
if
not
all,
test,
case
management
system,
intro
for
tcms
test
rail
quality
center
and
all
that-
and
I
do
want
to
highlight-
oh
you
have
it
shown
already.
So
the
reason
why
we
need
test
sessions
is
because
we
need
to
link
test
cases.
B
I
want
to
highlight
test
cases,
not
tests,
because
if
you're
talking
about
just
tests,
there's
a
spectrum
of
it,
there
are
things
that
move
really
fast,
that
you
don't
really
need
a
test
case
for
and
those
are
unit
tests.
Those
are
feature
specs,
where
we
have
close
to
close
to
more
than
150
000
tests
running
at
a
given
time.
B
A
B
It's
very
useful
for
both
transparency,
reason
and
compliance
reason.
B
And
that's
what
we
do
here
at
gitlab.
You
can
see
that
there's
a
mock-up
here.
This
is
just
an
idea
we
had
a
month
ago,
which
is
now
we
are
starting
to
automate.
B
This
issue
is
yes,
so
you
can
see
it
collects
information
if
you're
going
to
go
back
real,
quick.
B
What
we
do
here
is
we
list
the
test
case
and
with
a
pass
or
failed,
and
it's
this
high
value
test
in
ci
pipelines
at
the
end
of
the
release
process
that
we
want
to
know
it's
not
run
in
on
every
mr.
It's
run
at
very
specific
areas
of
the
pipeline
that
is
closer
to
the
customers,
so
master
branch
right,
staging
pre-prod
and
sometimes
even
production.
B
The
use
case
here
is
that
we're
linking
both
a
test
case
and
where
the
pipeline
is
being
run.
You
can
see
the
first
one
on
the
create
it's
running
in
staging,
so
this
is
like
a
staging
test
session
to
staging
report,
and
the
test
case
is
a
now.
It's
auto
generated
by
issues
we're
going
to
migrate
it
to
to
the
test
case,
feature
this
quarter
and
we
aim
to
have
one
test
session
for
deployment
workflow
and
that
can
be
linked
traceable
to
a
to
a
to
a
deliver.
B
A
No,
that
was
a
really
good
introduction
and
I
think
it
leads
open
a
couple
questions
that
I
had
so
I
think
you
highlighted
it,
but
this
is
representative
of
a
test
case
correct
yes,
okay.
So
when
I'm
looking
at
your
automated
report
that
you
have
the
git
lab
qa
bot
creating
for
you
now
are
these
those
test
rep
cases
as
well
that
you're
going
to
be
migrating
over
into
the
test
cases.
B
A
B
Okay-
and
this
this
is
just
this-
is
for
master
and
there'll,
be
one
for
for
master
that
we
want
for
for
staging
master.
We
run
a
lot
of
tests.
As
you
can
see,
this
is
a
yeah.
A
B
It's
it's
quite
the
quite
a
long
report.
Yes
and
it
links
multiple
and
you
can
see
why
that
implementing
test
sessions
at
the
pipeline
doesn't
give
you
the
big
picture,
because
it
can
be
a
part
of
multiple
pipelines
and
the
way
we
work
at
gitlab
we're
actually
using
a
different
instance.
We
use
ops.gilaps.net
to
run
production
and
deployment
because
we
need
that
redundancy.
If
something
goes
down,
there's
still
an
instance,
that's
always
up
and
running,
so
we
can
come
back
and
make
changes.
B
A
B
So
this
is
it's
in
the
the
triage
bot.
So
what
what
do
we
do
is
just
this
is
a
script
that
calls
the
apis.
B
So
when
you
run
something,
there's
a
there's
a
report
at
the
end
that
tells
you
okay,
these
were
the
links
to
the
test
cases
url
that
were
part
of
this
pipeline,
and
what
this
is
is
just
making
api
calls
it's
dog
footing
or
api
as
well.
I
want
to
highlight
that
and
then
generating
a
summary
view
of
what
happened
that
day
with.
B
A
A
Yep,
so
I'm
just
trying
to
break
down
some
that
logic
and
see
how
do
we
expose
those
references
that
you
make
to
say,
like
this
test
session
report
is
looking
for
these
environments
to
push
the
test
cases
from
and
that
kind
of
stuff.
So
I
know
we've
been
building
out
test
cases.
It's
got
some
limited
functionality,
a
part
of
it.
A
A
And
we
can
represent
those
in
milestones
that
teams
can
customize
based
off
of
their
own
needs.
So
to
me
it
felt
like
if
we
represented
each
test
session
as
if
it
were
like
a
milestone,
you
could
have
a
way
to
sort
or
filter
down
the
test
cases
in
a
singular
view.
So
the
way
I
was
looking
at
it
was
your
reports
here.
B
So
that's
a
good
start,
I
would
say,
and
it
may
solve
a
good
number
of
users
at
gitlab.
We
aim
to
deploy
every
day,
so
one
milestone
you
probably
have
like
20
deploys
to
production
and
for
every
deploy.
You
would
have
a
test
session
that
runs
on
multiple
environments.
The
first
will
be
master,
second,
will
be
staging,
there
will
be
pre-prod
and
we
have
test
running
on
production
as
well.
So
think
of
you
have
the
same
tests
running
in
all
four
places
for.
A
B
B
Same
list
it
will
be-
and
that's
that's
that's
where
the
continuous
delivery
world
is
going,
actually,
teams
deploy
multiple
times
a
day
and
they
it's.
I
think,
it's
good
to
start
to
understand
there.
It
may
be
better
to
to
build
bottoms
up
to
solve
that.
First,
like
you're,
not
locking
people
into
just
one
one,
one
currency
of
a
milestone
for
sale
for
lack
of
a
better
term,
but
you
have
the
flexibility
for
for
the
test
session
to
be.
You
know,
multiples
without.
A
Yeah,
I
think
what
I
was
trying
to
highlight
more
is
when
you're
dealing
with
like
I'm
forgetting
where
the
milestone
yeah
right
here.
If
you're
dealing
with
a
milestone
feature,
you
can
see
what
all
the
issues
were
in
that
milestone.
So
in
like
a
similar
way,
you
could
find
what
all
the
test
cases
were
for
that
specific
test
session,
which
I
think
is
what
the
intent
of
your
mvc
concept
is
look.
A
We
have
a
collection
of
test
cases
that
ran
we're
just
pointing
you
essentially
to
where
these
will
appear
in
a
test
case
list
anyway.
I
I
could
see
how
this
could
be
problematic
for
git
lab.
If
we're
deploying
so
frequently,
we'd
have
a
lot
of
test
session
reports.
B
A
A
Yeah,
maybe
I'll
re
clarify
this
again,
I'm
not
mapping
to
a
specific
milestone,
I'm
using
the
ui
of
a
milestone
to
represent
a
similar
relationship
got
it
okay,
that's
that
clear,
clarifies
it
up
yeah,
just
trying
to
look
to
what
are
some
other
components
we
already
have
built
in
gitlab
that
do
something
similar
as
a
way
to
simplify
the
design
and
then
from
there
expanding.
B
Want
to
say
that
test
cases,
it's
are
you
familiar
with
the
object-oriented
nomenclature
of
having
classes
and
instances.
B
A
B
Test
case
can
have
information
on
the
location
of
the
pipelines
like
this
test
needs
to
run
in
master
needs
to
run
in
pre-prod
needs
to
administer,
aging
needs
to
run
in
staging
it
might
not
need
to
run
in
production.
This
test
needs
to
run
only
in
production
as
a
sanity
check.
I've
been
there
in
that
spot
before,
where
we
just
want
a
lock-in
test
in
production
running
every
minute
to
make
sure
things
are
up
and
running.
B
A
Okay,
so
the
same
test
session
will
open
and
close
depending
on
if
it's
been
triaged
or
not.
Essentially,
like
okay
got
it,
so
you
typically
see
the
same
120
reports
for
gitlab,
but
depending
on,
if
they'll,
pass
or
not
it'll,
be
whether
or
not
you
have
to
go
actually
go
triage
it
and
do
something
like
that.
The
charging
happens
in
test
session
and
I
actually
have
a
good.
B
Let's
check
on
time
right
here
we
have
some
time.
I
have
a
good
example
to
show
why
we
shouldn't,
if
you
sorry,
if
you
can
share
the
screen
real,
quick,
I'm
just
gonna.
A
B
Okay,
this
is
new,
oh,
it
relates
to.
Can
you
click
on
one
of
the
old
test
test
cases?
I
think
we
did
this
too,
because
we
want
to
clean
up
some
things
like.
B
Not
here,
can
you
click
on
the
second?
The
first
link
results,
for
I
think
this
was
the
first
iteration.
B
B
Oh,
I
guess
maybe
not,
but
essentially
what
I'm
trying
to
say
is
we
posted
the
results
of
a
test
case
in
the
test
case
issue
itself,
and
it
ends
up
being
a
mile
long
because
it
starts
to
accumulate
yeah
and
it's
doing
two
things.
It's
storing
both
the
instruction
and
it's
storing
the
result.
A
A
B
Yes,
I
think
the
team
has
cleaned
up
quite
a
bit:
okay,
okay,
here
we
go
I'm
going
to
share
my
screen.
My
apologies.
B
A
B
This
one
is
really
like
heavy.
You
can
see
this
and
I
can
show
you
why
we
went
far
enough
to
experiment
having
the
bot
treat
this
as
like
the
control
panel
and
the
whole
historical
context
of
a
test
case.
A
B
A
B
A
B
But
these
you
know
these
doesn't
belong
in
the
test
case.
If
you,
if
there's
a
test
that
runs
for
two
years,
these
should
be
extracted
out
into
test
sessions
collectively,
and
those
are
time
bound.
The
test
case
isn't
time
bound.
Does
that
make
sense.
A
I
think
it
does
a
little
bit
and
I'll
have
to
mull
on
it
a
little
bit
more
okay,
but
I
have
this
for
reference,
so
that's
good
follow
up
on
that.
So
when
these
test
cases
are
run,
if
you're
not
going
to
be
using
a
bot
to
trigger
these
reports,
what
will
be
the
trigger
like?
Where
do
you
create
the?
Where
do
you
envision,
creating
the
definition
for
how
it
maps
to
a
specific
environment
or
which
report
it
should
be
building
which
test
cases
should
be
aggregated
together
right
now
that.
B
A
B
B
A
B
That's,
I
think,
they're
both
doing
the
same
thing
but
yeah.
Your
first
definition.
A
A
I
don't
necessarily
know
how
what
that
job
looks
like,
but
maybe
it
is
just
saying
instead
of
putting
the
output
over
here
put
the
output
over
here,
because
I
don't
think
hitting
new
test
session
button
in
the
ui.
Is
that's
not
useful.
You
need
to
have
a
job
run
this
and
create
it
for
you,
as
opposed
to
having
someone
create
a
ui.
A
A
B
Session
could
be
a
blend
of
an
automated
test
report
and
a
manual
test
session
that
you
know
we
used
to
have
feature
assurance
that
product
managers
run
through
every
every
every
release
and
since
since
we
have
already
automated
a
number
of
scenarios,
we
no
longer
need
that
and
then
we
pay
back
productivity
to
the
entire
team.
That
way.
B
Exactly
so,
if
we
were
to
build
this
for
the
greater
people,
the
wider
community,
we
need
to
account
for
that,
and
I
think,
coming
down
from
the
business
makes
sense.
You
have
to
solve
whether
how
you
want
to
have
a
work
resource
that
spins
up
that
thing
and
generates
that
thing,
but
I
think
coming
top
down
from
a
requirements
test
case
and
then
test
sessions.
Maybe
there's
a
map
that
we
can
put
in
the
ui
like
hey.
B
I
need
I
need
this
generated
or
or
there's
a
wizard
that
you
can
do
that,
but
I
I
would
suggest,
starting
with
a
boring
solution,
it
could
be
manual
absolutely
yeah
yeah.
It
could
be
manual
as
long
as
there's
an
api.
We
can
automate
that
while
we
get
better
at
knowing
what
the
users
want.
A
Right
yeah,
I
mean
personally,
I
think
I
would
love
to
help
guide
the
direction
of
moving
away
from
having
to
generate
all
these
issues
to
at
least
getting
into
like
a
a
dedicated
feature
in
gitlab
yeah
and
then
work
from
there
so
yeah.
I
would.
I
would
love
to
continue
following
up
getting
feedback
from
you.
Are
there
any
other
individuals
from
your
team?
I
realize
you're,
probably
a
very
busy
person
and
I'd
be
happy
to
solicit
feedback
from
other
team
members.
I'm
just
not
as
familiar
with
your
your
group.
B
Yeah,
I
think
a
team,
that's
an
easy
to
start
would
be
the
fulfillment
and
growth
team
so
vinci
they
can
work
with
her
and
that
and
and
ramya.
I
think
that
team
uses
the
test
case
feature
very,
very
heavy-handedly,
and
the
ics
in
those
two
teams
help
implement
it
use
the
test
case
very
sweet.
A
B
Want
to
awesome
yeah,
so
please
send
me
the
link
as
well,
because
I
want
to
propagate
it
in
our
department
channel.
So
they
are
aware
that
we
have
these
conversations
going
on
that
eventually
test
case
sessions
will
be
a
feature
and
get
lab.