►
From YouTube: Testing UX / PM / Research Sync 2020-08-12
Description
Today Juan, Nadia and James reviewed some of the current items in design in 13.3 and coming in 13.4 and clarified the expectations and feedback loop timing for the designs for Testing Vision and how that works into upcoming Vision work for the Verify stage. There was a long discussion about the current state of the JUnit Report page and all the improvements/data being added to the page and how to bring some order to those . . . . changes.
A
This
is
the
testing
ux
research
pm,
sync
for
august
12,
2020
and
one
it
looks
like
you
have
the
whole
agenda
so
I'll.
Let
you
go
ahead
and
start
with
your
first
point.
B
Sure,
I
don't
think
it's
gonna
be
long.
I
was
just
like
doing
some
grooming
of
design
issues
since
we're
moving
into
a
new
milestone.
I
just
want
to
make
sure
that
there's
nothing
left
that
should
have
been
addressed
on
these
in
this
release.
B
It
seems
that
we're
good
in
general,
but
yeah.
I
just
wanted
to
touch
base
on
things
that
are
yeah
certain
things.
So
the
first
issue
you
backlogged
that
one
right,
because,
like
yeah
for
reasons.
A
B
B
Cool
I'm
gonna
start
working
on
those
future
designs
that
we
talked
about.
I
already
have
like
some
drawings
on
my
on
my
notebook.
I
have
some
ideas,
but
I
just
wanted
to
make
sure
I
mean
I
move
it
to
13.4,
but
I
just
wanted
to
make
sure
that
I
understand
well,
what
are
the
targets?
What
do
you
have
in
mind
for
these
when
you
want
to
start
seeing
things
if
I
combine
it
plan
against
that,
you
know.
A
So
this
is
the
designs
for
the
vision
in
the
testing
categories.
I
just
want
to
make
sure
nadia
was
in
the
loop.
I
pinned
jason
because
he's
going
to
kick
off
a
kind
of
three-year
vision
for
the
whole
verify
stage
or
verify
components
says
verify
the
stage
yeah
the
verify
stage
next
week,
and
so
I
said,
hey,
we
already
started
on
testing
yeah,
so
we
can
feed
into
that.
So
we
had
identified
kind
of
the
big
problems
to
solve,
which
we've
already
done.
A
We've
talked
through
kind
of
workflow
or
outcomes
of
what
a
solution
to
those
problems
might
feel
like
for
a
customer
and
then
we're
going
to
do
some
really
loose
designs
based
on
that.
So
not
the
high
fidelity
type
mocks
that
we
usually
get
more
of
a
fat
marker
type
sketch,
because
we
anticipate
that
these
will
change
over
time.
If
we're
thinking
about
these
as
a
three
to
five
year,
vision
that
we're
going
to
learn
more
tech
is
going
to
change.
Customer
problems
are
going
to
change,
even
so.
A
This
is
a
direction
that
we
think
we're
going
to
be
going
in
right
now,
based
on
everything
that
we
know
so
then,
the
intent
of
this
when
I
kicked
this
off
was
to
be
able
to
use
this
in
conjunction
with
the
ci
use
case,
work
that
pmm
team
is
doing
as
well
as
then
some
forward-looking
vision
work
that
I'm
doing
just
talking
about
here's
the
direction
of
the
category
or
the
categories
in
testing.
A
B
Yeah
exactly
so
yeah,
I
think
you
put
it
pretty
well.
I
think
that
then,
should
we
wait
to
wait
for
jason's.
I
mean
he
already
created
an
issue
right
so
like
should
we
use
that's
a
directional
type
of
thing,
whether
I
mean
I
don't,
I'm
I'm
not
entirely
sure
like.
If
you
want
me
to
create
these
designs
and
just
like
fit
them
into
that
issue
or
yeah.
A
I
think
we
should
move
forward
with
a
couple
of
designs
that
we
talked
about:
okay
around
here
outcomes
to
get
to
finding
hotspots
for
code
hotspots
for
performance,
costly
tests
and
post-deploy
bugs
those
are
kind
of
the
identification
and
actionable
data
around
those
four
things
where
the
the
long-term
direction
for
us.
So
I
still
think
we
should
get
those
things
done.
We
may
then,
additionally,
have
something
I
think,
especially
as
we
start
to
think
about
across
the
entire
verify
stage.
A
Where
is
their
where
we
can
pull
data
from
all
three
of
the
groups
is
around
here's
your
performance,
here's
the
performance
of
your
pipeline;
here's
where
you
can
make
improvements
to
your
pipeline
and
where
there
are
problem
spots
that
you
need
to
address.
Oh
yeah,.
B
Absolutely
all
right
yeah!
So
I'm
going
to
be
working
on
that
on
13.4,
we
mentioned
that
on
the
on
our
kickoff
call
yeah.
A
A
Okay
in
the
kickoff
video?
But
let's,
let's
talk
about
before
we
do
the
recording
tomorrow
a
way
to
incorporate
work
that
we're
doing
for
the
direction
pages
made.
Okay,
okay,
makes
sense,
or
I
mean-
maybe
even
we
do
it
as
a
separate
video
of
talking
through
hey
here's,
we're
kicking
off
some
direction
design
and
how
it's
going
to
change
the
direction
pages.
B
The
other
thing
that
I
was
thinking
is
that
I
definitely
don't
want
to
do
this
in
a
vacuum
at
all.
You
know
I
wanna
basically
start
feeding
some
designs
into
the
issue
and
then
getting
like
feedback
from
the
team
feedback
from
you
from
nadia
from
json
from
anyone
right
and
then
like
as
I
get
feedback,
because
we
are
working
on
like
a
lower
fidelity,
it's
easier
to
change
things.
We
think
how
we
are
like
approaching
things
so
yeah.
My
goal
is
to
start
feeding
designs
into
that
very
lightly,
starting
to
ask
feedback
to
people.
A
So
my
expectation
for
the
feedback
cycle
on
this
is
that
it's
a
very
slow
feedback,
loop,
okay,
where
we
do
an
iteration
on
these
designs
and
the
next
time
we
look
at
that
might
be
a
year
from
now.
Yeah
we're
using
them
and
because
I
want
to
incorporate
them
into
like
a
recording
around.
Here-
is
our
12-month
vision
and.
A
What
we're
doing
in
the
next
quarter-
and
we
start
to
record
those
every
every
three
months
and
use
those
like
distribute
those
around
with
the
tams,
the
solution,
architects,
customers,
that
we
talked
to
about
hey
if
you're
interested-
and
you
have
five
minutes-
here's
a
recording
of
our
vision.
Here's
the
direction
pages
on
those
we've
incorporated
design
of
our
long-term
thoughts
and
then,
as
we
collect
feedback
throughout
the
year,
we
can
come
back
and
revisit
or
if
we
find
more
immediately
that
something
just
does
not
align
with
where
customers
think
they're
going.
A
B
I
think
that
makes
it
so
much
clearer,
so
cool
yeah.
A
B
Was
more
mostly
curious
about
the
feedback
loop
velocity,
but
you
you
just
completely
answered
that
question.
So
I
all
right,
the
next
one
that
I
have
is
for
119.032,
but
you
already
reply
there,
which
is
like
if
I
could
change
the
workflow
label
for
that
one.
B
Yeah
yeah,
that's
it.
I
also
added
a
new
iteration
to
that
design
because,
because
of
your
previous
comment
about
the
queen,
clicking
into
the
file
name
and
going
into
the
review
view
repo
view
of
that
file,
so
if
you
go
to
the
issue
at
the
bottom,
I
added
a
new
design
which
has
like
browseable
paths.
It
shouldn't
be
it's
exactly
the
same
design.
The
only
thing
that
changes
the
is
the
is
that
there
are
now
links
now
go.
Go,
go,
go
down
that
that's
the
one.
B
B
So
I
think
we
like,
because
you
mentioned
on
that,
one-
that
it
should
be
a
next
iteration.
I
think
that,
like
every
like
the
first
big
bang,
change
for
the
issue
include
the
browsable,
because
it's
not
a
big
deal
to
link.
A
Where
do
you
do
it
in
the
code
quality
report?
The
only
thing
I
would
say
is:
let's
I
want
to
leave
some
flexibility
for
the
front
end
if
they
see
that
this
is
getting
really
crowded
with
the
suite
the
name,
suite
name
and
file
name,
especially
with
file
name,
and
that
that
ability
to
copy
the
path.
A
Let's
give
them
some
flexibility
if
they
feel
like
truncating,
that
is
going
to
be
a
better
ux
experience
to
go
ahead,
and
just
do
it
mean
if
you
feel,
if
you
feel
okay
about
that,
but
I
would
I
would
want
to
give
them
that
option.
I
think
yeah.
B
My
thought
was,
we
can
always
make
the
clone
slimmer,
like
you
know
like,
and
then
like
the
rate
of
readability
of
the
file
name,
it's
not
a
big
concern,
because
people
are
not
going
to
read
the
file
name
and
like
oh,
it's
that
we're
already
giving
them
other
things
there.
You
know
we're
giving
up
the
browser
file
path
and
we're
giving
them
the
ability
to
copy
and
paste
the
file
path,
which
those
things
like,
I
think,
achieve
everything
that
you
need
from
the
file
name.
B
B
Actually,
you
brought
you're
bringing
something
up
which
I
think
it's
very
important
for
us
to
start
thinking
about
is
what
are
we
gonna
do
with
this
table
this
table?
It's
like
getting
crazy
and
we
have
designs
for
like
the
test
history,
which
is
gonna,
make
it
even
crazier.
I
already
asked
feedback
to
the
team,
the
design
team
today
on
on
regarding
the
horizontal
real
state
of
this
table,
but
yeah.
I
think
we
should
think
more
deeply.
How
are
we
gonna
fix.
A
I
think
we've
jammed
as
much
as
we
can
plus
three
more
things
into
this
view.
It
needs
another
page
where
or
another
view
where
you
start
to
get
the
details
like
here's,
the
the
name
of
the
file
that
the
test
lives
in
right
status
should
still
be
here.
The
trace
should
probably
be
on
that
detail,
page
the
history
that
could
be
on
that
additional
detail.
A
Page,
that's
my
thought,
but
I
think
we
should
have
another
like
the
next
iteration
of
this
is
pulling
some
some
of
the
data
out
of
this
yeah,
where
you
could
still
find
tests
that
failed
or
that
are
slow.
B
A
A
B
No,
I
I
I
I
it's
it's
not
a
it's
not
a
big
deal,
and
I
I
have
been
aware
that
they
are.
They
are
all
kind
of
like
cross-dependent,
so
I
haven't
been
designing.
You
know
in
like
a
silo
saying,
like
oh
file.
Name
is
now
file
name
and
we're
never
going
to
get
another
column.
That's
not
the
way
that
I'm
thinking
about
this
you
know
yeah.
I
know
that
there's
other
columns
coming.
So
that's
why
I
have
been
thinking
a
lot
about,
like
the
like.
B
That's
why
I
added
like
the
copy
and
paste
of
the
file.
I
have
been
thinking
more
about
like
how
how
they
look
when
you,
when
you
basically
wrap
the
text,
all
those
things
I
have
been
thinking
about
those.
So
it's
yeah,
it's
not
a
big
deal.
I'm
aware
that
we
are
like
touching
many
areas
with
this
page
cool.
C
I
actually
just
found
them
also
there
yeah,
I
I
think
it's
too
much
text.
It's
also
like
big
chunks
of
texts
to
me.
Yeah,
I
don't
know.
I
need
to
look
a
little
bit
into
the
details
to
understand
what
is
like
what
are
we
solving
with
this
table?
You
know,
like
kind
of
like
approach
this
more
from
why?
Why
did
we
do
it
this
way
like?
C
Why
is
this
all
needed,
but
yeah,
it's
it's
a
bit
hardly
readable
for
sure,
like
also
because
the
things
have
four
lines
there
and
there
is
so
much
space
on
the
trace
part
like
I
don't
really
understand
what
all
of
those
things
so
I
feel
like.
I
need
a
bit
more
catch
up
here
to
provide
proper
feedback,
but
I'm
happy
to
help
you
brainstorm
and
yeah
yeah.
B
We
we
have
some
ideas
already
like
the
trace,
for
instance,
that's
eventually,
it's
not
gonna,
be
as
big,
because
we're
gonna
move
the
trace
out
of
the
page,
and
it's
just
gonna
be
a
button.
That's
gonna
solve
that
problem
like
the
white
space
in
the
trace,
and
we
recently
picked
something
about
the
text
wrapping
which
makes
the
ability
of
the
yeah
there's
things
that
we
should
think
like
once.
C
For
example,
if
the
file
name
doesn't
like,
probably
it
has
to
be
visible
as
well,
it
probably
has
some
information,
but
if
that's
just
for
copying,
for
example,
we
could
just
show
like
a
copy
icon
or
whatever
just
so,
I
feel
like.
We
need
to
hide
some
content
well
yeah,
if
we
can
right
so
again.
This
is
why
I'm
saying
like
I
cannot
do
any
proposals,
because
I
need
to
understand
why
those
elements
are
there
and
what
information
do
they
bring
and
what's
the
most
important,
etc.
B
A
Awesome
all
right,
yeah
and
then
I
just
added
one
thing
I
just
wanted
to
provide
an
update.
We
wrapped
up
the
solution,
validation
on
the
test
history.
We
feel
good
about
that.
Moving
forward.
Yesterday,
ricky
and
I
iterated
again
in
our
one-on-one
on
an
mvc
we
were
talking.
It
was
really
in
the
context
of
we've,
had
a
couple
of
features
lately
that
have
released
that
we've
had
to
make
big
architecture
changes
after
the
initial
implementation,
and
so
we
were
trying
to
find
something
that
we
knew.
A
We
would
throw
away
that
we
can
validate
while
we're
doing
an
implementation
or
a
tech,
research
or
tech
evaluation,
type
issue
into
the
architecture
of
a
bigger
version
and
so
created
that
issue.
I
did
some
really
low
fidelity
design
on
it
and
dropped
it
in
just
as
an
example
of
where
this
might
show
up
and
we're
already
iterating
on
that
iteration
again
today
of
maybe
moving
it
over
into
the
mr
view,
to
make
it
a
little
bit
simpler
to
both
implement
and
use
from
an
end
user
perspective.
A
So
that's
where
we're
at
with
test
history
and
then
the
code
covers
reports.
I
had
screwed
up
the
respondent
link
and
so
no
one
could
book
a
meeting
with
me
and
so
fixed
that
yesterday
got
three
other
interviews
already
scheduled
overnight.
So
we'll
have
a
full
slate
of
four
folks
one,
and
I
interviewed
the
first
person
yesterday
first
recruited
interview
yesterday
and
well,
I
have
one
tomorrow,
one
on
friday
that
I'll
do
solo
and
then
one
the
following
thursday
so
feel
like
we're.
B
B
A
Yep
agreed,
I
had
checked
the
option
to
avoid
conflicts
on
my
calendar,
which
conflicted
with
the
block
of
time.
I
had
blocked
off
every
afternoon
to
hold
for
research
interviews,
so
what
I
had
blocked
so
I
didn't
have
conflicts
conflicted
with
respondent.
I
was
like
oh,
the
system's
too
smart
for
me.
B
A
B
A
Had
some
folks
who
are
just
not
qualified,
like
in
the
in
the
copied
survey
that
emily
sent
out
trying
to
get
more
for
us
before
I
fix
the
link
we
had
like
three
product
managers,
reply
and
a
like
psychologist
or
something
like
even
the
system
said
no
you're
not
qualified,
and
then
you
get
in,
and
you
see
people
who
have
gained
like
the
title
to
get
qualified
for
a
survey.
And
then
you
look
at
their
experience.