►
From YouTube: Intro to Quality
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
Hi,
my
name
is
tiffany
raya,
I'm
a
software
engineering
test
with
group
pipeline
authoring
here
at
gitlab.
It's
an
honor
to
be
here
today
and
discuss
with
you
about
quality
and
good
luck.
A
Let's
begin
so
today
we
will
cover
some
topics
about
what
quality
assurance
is.
Why
is
it
important,
especially
in
software
development?
A
What
are
the
different
types
of
testing
and
what
are
the
test
approaches
and
methodologies
that
are
being
used
today
in
software
testing,
and
also
I'd
like
to
mention
the
difference
between
quality
engineering
and
software
engineering
tests
as
well,
and
very
quickly
show
you
how
we
test
things
here
at
gitlab
and
also
like
to
share
with
you
some
essential
skills
that
you
might
need,
if
you
ever
consider
to
be
a
software
engineering
test?
A
So
it
is
a
very
important
phase
in
any
product
development
process
really
and
not
just
software
any
type
of
product
nowadays,
food
car,
so
on
and
so
forth,
but
for
the
class,
let's
just
assume
the
product
we're
talking
about.
Is
software,
and
so
quality
assurance
will
make
sure
that
when
we
implement
a
new
feature,
that
features
satisfied
the
product
design
requirement
exactly,
and
when
do
we
start
testing?
A
Well,
I
think
we
should
start
testing
as
soon
as
the
design
phase
has
begins
and
also
keep
testing
throughout
the
entire
development.
Like
life
cycle.
A
We
will
start
testing
when
we
have
the
very
first
unit
of
code
implemented
and
then
after
we
have
create
all
the
unit
of
codes
needed
for
a
fully
functional
feature
and
we
combined
them.
We
would
then
introduce
a
test
for
that
feature
itself,
and
then
we
will
adhere
that
feature
into
the
main
product,
and
then
we
will
need
tests
to
make
sure
that
the
introduction
did
not
break
the
product.
A
A
But
the
testing
doesn't
end
here.
We
will
keep
testing.
We
will
keep
monitoring
the
behavior
of
the
product
now
that
it's
in
the
real
life
environment,
how
it
performed
and
if
there
is
any
escape
bug
that
we
haven't
accounted
for
and
when
the
development
cycle
repeats
testing
repeats.
A
A
And
what
I
mean
here
is
that,
for
example,
in
your
team,
a
product
manager
will
come
up
with
a
request
for
a
new
feature
and,
and
he
or
she
will
listed
out
all
the
requirements
that
this
feature
should
work
and
all
the
details
and
in
our
test
we
have
to
make
sure
that
the
implementation
meets
every
single
requirement
and
also
hopefully,
capture
any
defects
and
any
exception
that
hasn't
been
handled
as
soon
as
is
implemented
before
it
gets
to
production,
of
course,
and
also
with
thoroughly
testing.
A
We
can
prevent
a
lot
of
major
product
outages
or
a
customer
facing
issue
that
can
cause
a
very
bad
impact
on
the
business
in
general
and
with
the
good
strong
product.
A
We
can
be
confident
that
our
product
is
competitive
to
all
of
his
rivals
in
the
market
which
that
makes
drives
the
business
and
customer
confidence
like
we
can
build.
Customer
trust
over
time,
reduce
churn
rates,
boot
sales
and
revenues
very,
very
important.
A
What
are
the
different
types
of
testing
so,
as
you
can
see
here,
some
types
of
common
types
of
testing.
First,
we
have
user
experience,
also
known
as
ui
testing.
We
will
make
sure
that
all
the
ui
components
are
rendered
when
we
open
up
a
web
page.
For
example,
all
the
buttons
appears
aligned
the
colors
right.
A
The
locations
of
of
the
components
are,
as
expected,
nothing's
out
of
place.
Nothing
please
like
into
each
other,
so
on
and
so
forth,
and
just
and
follow
that
we
have
to
make
sure
that,
besides
looking
pretty,
these
feature
actually
works
like
when
you
click
on
a
button.
It
actually
fires
an
event
and
does
something
for
you
and
or
and
that
something
has
to
be,
as
you
expected,
not
something
else
and
go
beyond
functionality.
A
We
also
have
performance
testing
to
make
sure
that
the
product,
when
under
pressure,
still
perform
at
an
exceptional
performance
rate,
for
example,
when
we
develop
in
our
machine,
we
don't
have
a
lot
of
traffic
like
we
have
in
production,
so
everything
works
fast
and
great.
A
But
if
we
don't
account
for
performance
when
we
release
the
future
into
production
soon
enough,
we
will
see
that
with
a
lot
of
traffic
who
starts
seeing
latency
or
even
timeout
or
even
outage
as
well.
A
And
also,
we
need
to
make
sure
that
our
product
is
compatible
in
different,
like
our
software
is
compatible
in
different
browsers,
for
example,
if
it
works
in
chrome,
it
should
works
in
firefox.
It
should
works
in
opera
and
even
internet
explorer,
for
example,
different
environments.
What
I
mean
is
that
gitlab
we
have
our
shared
environment,
but
we
also
offer
self-hosted
and
that
is
zone
environment
and
and
with
different
configuration.
A
We
have
to
make
sure
that
the
product
works
there
as
well
and
not
to
mention
different
device
if
it
works
on
a
browser
on
the
computer,
it
works
in
the
browser
yeah
on
a
mobile
phone,
for
example,
and
even
different
product
version.
We
support
at
least
one
version
older
or
it's
for
customers
who
who
doesn't
want
to
upgrade
just
yet
and
have
to
make
sure
that
the
older
version
also
works
as
well,
and
we
also
make
sure
that
the
tests
are
working.
A
As
expected,
like
we
also
test
the
tests,
we
have
to
always
capture
the
test
data
monitor
and
make
sure
that
the
failures
are
actual
failure.
Otherwise,
test
is
considered
lucky
and
we
have
to
make
adjustments
maintain
and
even
improve
the
tests.
Add
more
tests
are
taken
now
the
tests
are
not
in
use
as
well
and
last
but
not
least,
we
have
to
ensure
security,
make
sure
that
when
we
release
the
product
it
does
not
expose
any
security
flaw
or
vulnerabilities
that
can
harm
ourselves
to
our
customer.
A
A
We
actually
want
unit
tests
for
every
single
native
code
is
not
redundant,
it's
necessary,
but
when
it
comes
to
integrated
tests,
which
is
when
we
combine
the
unit
tests
into
a
feature
or
between
you
know
a
group
of
feature,
then
we
need
less
amount
of
tests.
A
We
only
test
that
specific
feature
or
the
specific
group
of
feature,
and
then
the
last
type
is
end-to-end
tests
and
we
don't
want
a
lot
of
these,
but
they
are
very
important
because
it's
test
the
meaningful,
complete
user
flow,
just
like
a
user,
is
actually
using
our
product.
A
So
these
tests
are
very,
very
complex
setup,
I
would
say-
and
so
it
it
is
time
consuming
and
and
expensive.
So
we
don't
want
a
lot
of
them,
but
we
need.
We
definitely
need
entrance
test.
You
know
suite
and
so
unit
tests
should
be
small
and
very
fast.
A
A
As
you
can
see
here,
we
have
many
steps
in
order
to
make
a
cup
of
tea
and,
let's,
let's
imagine
that
we
have
a
k-cup
machine,
and
so,
as
you
can
see,
the
outermost
point
would
be
the
main
steps.
I'll
call
the
main
steps
like
get
things.
So
when
you
create
getting
a
method,
you
want
a
unit
test
for
that
method.
A
And
what
do
we
test
for?
Well,
we
test
that
get
thing
when
call
it
does
not
return
null.
It
has
that
I'm
assuming
we
are
returning
an
array
of
item
here,
so
the
array
should
be
shouldn't
be
empty
and
the
array
return
the
exact
item
as
we
list
it
here,
no
more,
no
less
and
no
or
don't
return
anything
twice
or
don't
return.
Anything
that
doesn't
belong
to
the
list
and
then,
as
you
can
see
the
next
step,
we
have
two
sub
steps.
A
I
would
say
all
three
together:
let's
call
them
a
feature,
and
so
in
prepare
k-cup
and
cut
feature.
We
definitely
need
unit
tests
for
each
step,
the
main
step
and
the
two
sub
steps.
A
After
that,
we
have
one
integrated
test
for
the
feature
where
we
combine
all
of
these
steps
together
and
we
have
a
test
that
makes
sure
that
when
prepared
k,
cup
and
cup
is
triggered,
okay,
the
machine
has
exactly
one
k-cup
and
the
cup
is
located
exactly
underneath.
A
For
examples
and
then
go
through
all
the
steps
after
we
finish,
we
want
to
have
one
end-to-end
test
for
the
entire
process,
which
is,
for
example,
in
the
test.
We
will
start
the
process
with
calling
getting
calling
prepare
a
k-cup
start
the
machine
and
call
the
machine
and
call
taste
and
then,
at
the
end,
we
we
want
to
test
that
there
is
cup
in
the
liquid.
There
is
liquid
in
the
cup
and
and
the
liquid
tastes
like
tea.
Then
the
test
is
successful.
A
And
I
do
want
to
mention
quickly
the
difference
between
a
quality
engineer
and
a
software
engineering
test.
The
quality
engineer
is
very
well
known
in
the
name.
Quality
engineers
is
pretty
well
known
and
familiar
in
the
industry
because
it
has
lived
a
quite
long
time,
but
today
we
have
a
fairly
new
position.
Called
software
engineering
tests
or
most
of
the
people
would
say,
set
or
sct.
A
And
what
makes
these
two
positions
different
from
each
other?
Well,
quality
engineer.
Responsibility
is,
as
we
have
discussed
throughout
this
lecture,
that
the
engineer
would
ensure
that
the
implementation
of
new
feature
works
as
desire.
A
The
product
itself
works
as
a
whole
and
the
new
feature
does
not
break
the
product.
There's
no
regression
and
so
on
and
so
forth
and
and
the
quality
engineer
would
get
involved
at
different
times
in
the
product.
Development
depends
on
what
kind
of
software
development
life
cycle
model
the
company
chooses.
A
What
I
mean
is
like
they
could
involve
very
early
or
very
late
at
like
right
before
we
introduce
the
product
to
our
customer.
In
other
words,
quality
engineer
is
responsible
for
black
box
testing.
A
Software
engineering
test
is
a
software
engineer
who
is
responsible
for
creating
and
maintaining
the
automated
test
platform
for
the
company's
products.
So
after
we
have
engaged
have
created
this
platform,
we
we
then
engage
and
promote
the
testing
practice
throughout
the
software
development
process
to
pretty
much
everybody
in
the
engineering
department,
like
I
I
mentioned
earlier.
If
we
want
to
start
early-
and
here
it
get
like,
we
call
the
practice,
the
quad
planning
process
and
we
want
to
start
during
the
design
phase.
A
We
will
follow
very
closely
the
with
the
product
manager
and
the
development
team
of
how
they
want
to
design
the
product
and
how
they
want
to
implement
those
design
proposal.
And
then
we
will
make
the
suggestions
of
test
coverages
accordingly.
A
A
We
create
a
framework
called
our
end-to-end
test
at
gitlab,
and
on
top
of
that,
we
create
a
ruby
gem
called
gitlab
qa
and
what
it
does
is
is
orchestrate
all
of
the
requirements
set
up
and
then
execute
the
test
automatically
in
any
given
environment.
Maybe
give
it
a
life
environment,
or
you
know,
a
non-life
environment
and
so
to
help
not
just
developer,
but
hopefully
customer
as
well
to
execute
tests
on
demand
and
also
we
with
all
of
these
tools.
A
We
we
can
incorporate
these
tests
into
gitlab
ci,
like
any
of
your
worst
requests.
When
you
create
immersion,
emotion,
quest,
make
a
code
check
change.
All
of
the
tests
are
automatically
run
for
you
and
make
sure
that
the
code
doesn't
break
the
product.
A
A
Request
in
our
gitlab
repo,
so
one
of
this
one,
each
of
the
circle
is
a
stage
and
one
of
these
this
these
stages
will
be
a
test
date
that
will
run
all
of
the
unit
tests
and
integrated
tests
and
the
result
will
be
reported
and
if
any
of
them
fail,
we'll
not
allow
the
most
requests
to
be
merged,
and
then,
at
the
end
you
will
see
where
the
exclamation
mark
is
that's,
where
we
trigger
a
job
called
packaging
qa
which
use
the
gitlab
and
qa
gym
in
a
downstream
pipeline
and
then
automatically
do
all
the
setup
run.
A
All
the
tests
and
report
back
the
results
for
us.
We
also
have
a
smoke
and
reliable
test
suite,
and
if
any
of
these
fail,
we
will
block
deployment,
we
hope
it
won't
allow
to
be
really
into
production.
Then
I
also
have
a
little
demonstration
of
how
gitlab
clay
works
here.
So
github
qa
is
a
gym
and
one
trigger.
A
It
will
spin
up
a
docker
container
called
gitlab
to
a
container
and
then
in
this
container
we
will
specify
what
kind
of
scenario
we
want
to
run
and
run
that
test
of
that
scenario,
against
whatever
instant
gitlab
instance.
We
want
is
a
give
it
staging
environment
or
another
docker
container
that
hosts
the
the
gitlab
itself
or
our
development
toolkit
so
on
and
so
forth.
A
And
lastly,
I
would
like
to
share
with
you
some
important
skills
in
case
you
want
to
become
a
software.
Engineering
test,
definitely
know,
learn
and
know
about
software
testing
and
the
methodologies
used
in
software
testing,
like
we
have
discussed
here
in
this
class
and
also
know
about
the
different
software
development
methodology
like
agile,
devops,
waterfall,
rapid
application
development.
A
Why
are
they
different
from
each
other
and
why
your
team
uses
those
and
how
to
test
when
to
test
in
each
different
method,
very
important
that
you
know
and
familiar
with
the
common
tools
and
technologies
that
are
used
in
today's
software
development
to
name
a
few
docker
g
cloud,
aws,
sentry,
postgres,
elasticsearch
and
definitely
programming
languages.
A
But
this
is
really
depends
on
the
software
that
you'll
be
working
with,
because
each
software
has
their
own
tech
stack,
but
we
can
use
example
from
gitlab
stack,
so
definitely
no
ruby,
golang,
javascript,
sql,
etc.
A
And
that
concludes
our
session
today.
Hope
you
have
enjoyed
our
class
and,
most
importantly,
learn
something
new
about
software.
Development
testing
is
very
important
and
definitely
a
great
skill
to
have
in
your
skill
set
always
ask
your
coat,
no
matter
how
confident
you
are
I'll,
be
developing
and
thank
you
bye.