►
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
A
To
give
an
idea
of
how
can
we
improve
your
your
testing
in
in
the
cloud?
So
we
can
start
with
the
with
the
challenges
of
testing
in
kubernetes.
The
the
the
first
one
we
can
go
through
and
you
can
analyze
is
that
the
large
majority
of
testing
Frameworks
are
not
built
with
kubernetes
in
mind.
What
does
that
mean?
Is
that
each
testing
tool
like,
for
example,
we
can
give
an
example
of
these
ones?
A
Are
they
are
made
to
solve
particular
issues
with
testing
like
for
a
certain
use
case
in
the
case
of
q6,
it's
really
built
to
solve
load
testing,
so
I
press
like
UI
or
end-to-end
and
Postman
API.
These
tools
do
a
job,
and
do
it
very
well,
she's,
you
know,
do
their
own
type
of
testing.
A
person
is
really
good
at
API
testing,
but
the
common
pattern
we
see
here
is
that
they
are
not
built
exactly
with
kubernetes
in
mind.
A
So
so,
when,
after
you
create
the
test,
you
have
a
big
issue
on
on
making
the
transition
into
okay.
This
is
I
wrote
the
test
now,
I
need
to
run
them
and
that
part
of
running
an
orchestration
gets
more
difficult,
because
you
know
the
tools
are
not
meant
for
that.
A
A
When
you
see-
and
we
think
about
automation-
is
you
think
of
cicds
right
and
they
can
really
increase
in
complexity,
the
more
tests
you
add
and
the
the
different
tests
workflows.
You
you
have
there
and
it
can
become
a
point
where
it's
very
difficult
to
manage.
A
You
can
have
many
people
just
to
manage
the
automation
of
tests,
so
so
it
you
become
less
willing
to
try
new
tools
to
change
your
workflows
to
to
expand
a
bit
and
that
can
really
become
a
blocker
and
also
impact
your
your
quality,
because
when
companies
don't
feel
like
very
willing
to
to
implement
these
workflows
because
the
the
cost
of
implementing
them
and
maintaining
them
it's
high
compared
with
the
perceived
volume,
especially
from
business,
then
people
won't
do
it
and
then
that's.
No.
A
The
cost
of
the
software
is
going
to
be
a
poor,
and
another
issue
is
that
then
the
test
gets
hard
to
debug.
So
imagine
in
a
cloud
environment
where
you
have
multiple
environments
with
multiple
tests
and
many
different
microservices
right,
then
a
test
fails,
and
then
we
want
to
know
like
what
happened,
which
environment,
what
are
the
logs?
What
might
be
the
issue
gets
very
hard
to
track
as
your
project
goes.
A
Modern
complexity,
if
you
have
just
you
know,
just
one
application,
simple
application
running
on
a
container
might
be
fine,
but
if
you
have
kubernetes
clusters
and
or
multiple
ones,
especially
in
many
microservice,
that's
definitely
an
issue,
and
the
other
thing
is:
your
environments
usually
are
not
accessible
like
everywhere
right.
You
have
sensitive
information
that
you
don't
want
to
share
either
public
or
even
with
all
of
your
organization.
Maybe
just
a
team,
you
don't
you
don't
want
to
to
give
access
to
everyone
that
environment
can
it
be?
A
It
can
be
for
the
data
issues
or
you
just
don't
want
everybody
to
mess
up
the
the
system
right.
So
you
just
give
people
some
people
access
to
that
environment
so
that
you
know
you
don't
have
anybody
that
might
not
know
how
to
use
it
properly
break
it
right.
So
you
sometimes
just
receive
the
access,
and
you
just
do
it
on
that
side
and
one
another
thing
is
like
those
environments
are
not
easy
to
set
up
right
and
especially
because
they
need
different
notes,
different
configurations.
A
So
it's
not
that
your
testers
can
do
this
usually
like
it
needs
a
people
that
make
their
shop,
creating
clusters
and
environments
and
set
up
the
environments.
So
it's
not
as
straightforward.
A
So
let's
go
into
what
are
the
three
pillars
of
quantitative
testing
and
what
they
mean.
So
there
are
certain
advantages
of
having
a
a
good
mindset.
When
you
start
implementing
testing
on
the
cloud
you
can
use.
The
old
days
of
you
know
having
a
pipe
everything
on
the
pipeline,
creating
custom
scripts
and
and
do
everything
from
there,
and
sometimes
you
you
might
think
of
testing
as
an
asset
plot
like
something
that
you
can
do
just
a
bit
just
to
make
sure
that
you
know
your
test,
your
your
code
is
tested.
A
Just
you
know
as
a
sanity
check,
and
you
don't
care
much
about
you
know
what
goes
to
production.
Of
course,
that's
the
implications
and
if
you
implement
testing
from
the
ground
up
in
a
good
way-
and
you
have
a
good
methodology,
mythology
and
processes,
you
are
going
to
find
that
you
gain
time.
So,
the
the
earlier
you
implement
a
good
testing
process,
the
the
more
time
you
save
along
the
road.
Of
course,
you
should
not
go
crazy
with
it.
A
Otherwise
you
know
you
might
spend
more
time
on
thinking
about
testing
than
actually
be
building
your
product
to
your
customers.
So
that's
why
the
cloud
native
approach
is
good,
because
it's
supposed
to
be
scalable,
you
are
supposed
to
have
an
easier
time,
integrating
it
with
your
testing
tools.
So
your
testing
tools
should
be
something
that
works
seamlessly
on
the
cloud.
You
should
not
spend
a
lot
of
time
just
making
your
tests
work
in
a
cloud
environment
and,
of
course
they
should
run
fast.
A
The
the
second
plr,
let's
say,
of
qualitative
testing,
it's
orchestration,
so
one
thing
is
just
you
know,
executing
the
the
test
right
in
the
scalable
easy
way.
The
other
one
is
the
the
complexity
of
your
workflows
right.
So
the
and
everyone
test
is
one
thing
having
let's
say
a
test
that
needs
to
execute
before
several
different
tests.
A
Let's
say
you
might
do
load
testing,
then
API
testing
at
the
same
time,
and
then
you
do
UI
testing
and
you
can
have
like
different
workflows
and
different
tests
running
at
the
same
time,
adding
things
like
Advanced
test
orchestration.
It's
super
important
to
to
have
you
figure
out
on
your
Cloud
environments
right,
so
it
should
be
quick.
You
shouldn't
spend
a
lot
of
time
here.
The
the
more
time
you
need
to
spend
in
testing
is
less
time
that
you
spend.
You
know
developing
a
better
application.
A
Of
course
you
just
want
the
results
of
having
good
testing,
but
the
time
you
spend
there,
you
shouldn't
you
shouldn't
shouldn't,
take
a
long,
a
lot
of
time
here
and
should
be
flexible.
You
should
not.
You
shouldn't,
see
big
blockers
and
obstacles
in
trying
new
tools.
One
thing
that
we
observe
in
the
trends
the
companies
that
talk
with
us
at
test
cube
is
that
they
have
some
tools
that
they
use
to
test
their
code.
A
A
So
it's
not
as
easy
decision
right
when
you
take
a
cognitive
approach
and-
and
everything
is
containerized,
that
won't
be
an
issue
where
you
can
adopt
new
testing
types,
new
testing
tools
and
do
workflows
in
a
way
that
is
not
costly
for
your
company
and
and
regardless
of
testing
type
things
work
like
you
know,
similar
almost
the
same
thing,
and
the
thing
you
need
to
see
is
that
all
of
these
tests
and
all
this
process
should
speed
up
your
deployment
process.
A
You
shouldn't
add
testing
steps
to
your
pipeline
and
then
realize
that
you
deliver
less
times
and
your
developing
life
cycles
increase.
So,
instead
of
of
delivering-
let's
say
every
week,
because
you
are
so
focused
on
on
having
to
test
these
things
that
then
you
release
that
stuff
to
your
customers.
You
should
test
more
yes,
but
we
thought
X.
Making
your
life
cycles
are
really
Cycles
longer
it's
possible
to
have
both.
So
that's
something
that
you
can
take
into
account
the
and
the
last
one
last,
but
not
the
least,
is
observability.
A
So
you
have
these
complex
workflows
with
many
tools
and
different
environments,
different
microservices,
and
it
runs
in
the
cloud
right.
So
you
need
to
give
a
really
good
access
to
everybody
on
the
team
to
see
what's
the
status
of
the
test.
What's
the
status
of
the
duplications,
the
environments,
everything
you
know
running
well
is
anything
broken.
It
should
be
easy
to
to
debug
what
happens.
A
So
if
a
test
fails,
if
it
having
access
to
the
logs
having
access
to
the
pods
like
see
what
what
happened
there,
it's
it's
very
important,
and
also
on
top
of
that
not
only
for
development
environments
but
but
for
production
itself.
You
should
have
observability
on
all
your
production.
Environments
are
actually
running,
so
you
should
have
also
some
tests
there.
Of
course,
they
are
not
the
same
ones
that
you
you
do
when
you
run
them
on
station
or
development
clusters,
but
you
should
have
some
there
definitely
encouraged
and
analytics
as
well.
A
So,
especially
if
you
have
testing
teams
that
have
been
been
creating
tests
for
your
product
like
for
several
months,
you
you
arrive
into
a
time
in
place
where
you
want
to
analyze.
Basically,
the
the
performance,
like
is
your
test,
making
your
development
life
cycle
longer
like
as
I
said
before,
can
we
improve
our
tests
somehow?
Which
tests
are
flaky
or
not?
Flaky
like
you
can
definitely
analyze
how
how
we
are
doing
testing
and
their
performance.
So
that's
also
something
that
is
very
important,
because
it's
not
just
about
running
the
test.
A
So
so,
with
these
characteristics
in
mind,
and
these
challenges
that
we
spoke
about,
that's
why
we
created
test
Cube
was
to
show
to
solve
basically
testing
in
the
clouds
and
to
be
the
kubernetes
native
test,
orchestration
and
education
framework,
so
that
developers
and
testers
are
not
blocked
with
testing
and
they
can
test
industry
on
the
cloud.
A
So,
if
you're,
a
devops
person
that
is
just
wants
to
up
to
my
TR
system
and
give
your
everybody
in
your
company
access
to
creating
tests,
running
them
in
kubernetes
and
have
visibility
on
it,
there's
definitely
like
something
that
you
can
take
a
look
so
yeah.
We
are
a
cncf
civil
member.
We
have
more
than
30
000
downloads
and
no
each
week
more
and
more
so
yeah.
A
If
you
want
to
give
it
a
try,
so
let
me
explain
a
bit
how
these
concepts
of
you
know:
Cloud
native
tests
work
especially
on
if
you
have
an
automated
system,
like
you
run
your
test
from
a
CI
CD.
The
traditional
method
is
that
you
build
and
you
have
different
steps.
Even
before
you
deploy
right,
you
can
do
link.
You
can
do
code
analysis.
A
You
run
several
steps
where
you
have
scripts,
that
kind
of
orchestrate
to
the
prepare
the
data
for
the
environments,
prepare
the
environment,
they
do
a
lot
of
stuff
around
the
test
and
then,
of
course
you
know
if
the
test
password
failed,
the
pipeline
will
fail
too,
and
but
everything
all
the
complexity
is
implemented
on
the
pipeline
and
then
the
cluster
he's
just
you
know,
just
have
the
application
and
then
all
the
compactor
lives
in
the
pipeline,
which
is
very
will
be
hard
to
change
with
time.
A
So
the
the
qualitative
approach
is
that
your
tests
become
kind
of
part
of
the
cluster.
So
you
run
it
kind
of
an
Aggie
tops
manner.
So
it
comes
from
your
the
states
of
your
test.
Come
from
your
repository
and
your
cluster
and
your
pipeline
just
says
just
this
size
is
to
you:
they
want
to
run
the
tests
or
not
and
they
are
not
in.
They
are
not
in
charge
of
you
know,
having
all
the
complexity
there
on
the
pipeline
in
Quezon
test
Cube,
you
start
the
test
in
the
cluster.
A
The
test
has
started
the
kubernetes
crd
and
then
from
your
pipeline,
for
example,
you
can
just
trigger
the
test.
So
basically
your
pipeline
talk
to
test
Cube
and
test
Cube
runs
everything
for
you
and
because
test
Cube
runs
inside
the
the
cluster
you
can.
A
You
can
run
in
a
more
secure
way
because
you
don't
have
to
expose
your
applications.
You
leverage
test
kubernetes
to
scale
everything,
because
everything
runs
as
a
kubernetes
job.
So
you
don't
have
to
worry
much
about.
A
You
know
scalability
or
performance
issues
there,
and
so
the
the
best
way
to
understand
it
is
basically
you
know
to
have
a
look
at
it.
So
I'm
gonna
do
a
quick
demo
for
you.
So
this
is
the
test
Cube
dashboard,
that
you
can
experiment.
A
So
you
can
just
go
here
like
if
you
have
GitHub
or
gitlab,
you
can
just
log
in
using
our
credentials
so
I'm
going
to
continue
so
here,
I
already
have
one
organization
prepared
for
us.
So
as
soon
as
you
log
in
you
have
an
organization
prepared-
and
you
have
like
an
environment
that
you
can
deploy,
so
you
can
deploy
this
to
your
cluster
using
an
L
command
or
rtli.
And
then
you
have
like
you
know
a
pod
running
on
your
cluster.
That
is
going
to
run
all
the
tests
for
you
here.
A
A
So
here
testcube
already
provides
support
out
of
the
box
for
many
different
kinds
of
executors
like
different
test
types,
I'm
just
going
to
select
key
six
and
then
I'm
gonna
select
where's
the
my
test
file.
So
you
can
select
test
tube
to
go
into
your
git
repo
and
then
fetch
the
file
from
there.
You
can
upload
a
file
or
you
can
even
place
a
string
like
a
really
a
JavaScript
code.
A
So
in
this
case
of
of
q6,
because
it's
a
scripting
language,
I'm
just
gonna
for
the
demo
sake,
I'm
just
gonna
paste
the
test,
so
I
just
wrote
some
JavaScript
codes
that
test
an
endpoint
and
it
fails
after
the
time.
So
just
just
a
simple
thing
that
I
can
create
so
I
just
create
a
test.
Now,
let's
go
ahead
and
run
it.
So,
as
you
see
here
now,
test
Cube
just
scheduled
a
kubernetes
plot
and
another
kubernetes
schedule
is
it's
probably
putting
the
Pod
in
one
of
the
notes
and
then
running
it.
A
So
here
you
get
the
the
logs
in
real
time
of
everything
that
happened.
So
you
get
the
logs
directly
from
the
testing
tool
and
then
you
can
quickly
see
what's
happening
there.
I
can
run
it
multiple
times.
So
you
get
to
the
all
the
insights
about
the
past
cell
ratios,
the
execution,
duration
and
along
you
know.
If
you're
passing
or
failing
so
you
can
run,
as
you
know,
a
lot
of
them
all
of
them.
A
You
know
at
the
same
time
and
test
keeps
just
makes
sure
that
everything
runs
seamlessly
and
gets
the
results
for
you.
You
can
run
this
from
your
cigd
system,
so
if
you
want
to
trigger
the
test,
we
have
Integrations
with
any
CRC
system
and
from
there
you
basically
connect
to
test
Cube
and
can
run
you
know
you
can
run
this
from
your
computer.
You
can
run
this
from
a
cic
system
as
well,
and
you
just
trigger
the
test
and
do
everything.
As
you
see
here,
all
the
tests
are
defined
as
a
crd.
A
So
so,
if
you
copy
this
and
deploy
it
to
a
cluster,
it
will
show
up
here
and
we
deeply
encourage
all
the
people
to
store
the
tests
in
their
git
repos
and
apply
them.
So
you
can
provision
or
the
provision
kubernetes
clusters
at
wheel,
and
you
can
just
deploy
the
test
and
you
have
your
all.
The
test
setup
always
prepared
to
run
things.
Another
example
is
like
so
this
is
like
how
do
you
is
a
good
test
right,
so
here
I'm,
going
to
give
you
an
example
of
how
to
run
a
test
Suite.
A
Foreign
and
then,
when
you
have
more
complex
workflows,
you
might
want
to
have
like
different
tests
like
one
after
the
other.
Let's
say
you
want
to
run
multiple
tests
in
parallel,
this
one
is
like
just
parallelized
load
testing
and
then
you
can
have
like
one
on
test
after
the
other.
So
can
these
can
be
any
type
of
test
can
be.
You
know,
API
test,
UI,
test
Etc,
so
here
I'm
just
going
to
add
a
few,
but
not
like
a
few
more
steps
here
and
then
I'm
gonna
press
save.
A
A
Then
you
know
when
these
three
finish:
we
are
going
to
run
these
two
ones
and
then
we
are
going
to
run
this
one
and
then,
of
course
you
can
click
on
on
any
of
the
tests
and
you
jump
right
into
it
and
you
see,
like
you,
know,
the
all
the
tests
insights
like
what
happened
here
and
yeah.
You
just
see
all
of
the
executions.
The
time
gives
you
a
really
good
overview
of
of
what
what
is
happening
basically
on
your
cluster
and
for
any
test
type
that
you
don't
see
supported
here.
A
You
can
just
go
to
our
docs
and
create
a
container
executor.
So
what
you
have
to
do
is
just
create
a
Docker
image
with
your
testing
tool.
Add
it
to
test
tube
and
it
will
work
for
you
so
so
yeah.
So
that's
like
the
the
quick
introduction
to
test
Cube.
We
have
like
a
lot
more
features
here
here
that
you
can
use
even
like
one
recent
one
that
we
released
where
you
have
ai
inside.
So
we
allow
people
to
to
see
like
what's
happening
there.
A
So,
for
example,
you
can
just
click
here
instead
of
going
to
the
logs
and
basically
tells
you
that
you
know
the
code,
the
status
code
is
not
returning
200
and
gives
you
suggestions
on
what
to
do,
and
you
have
like
many
more
features
for
Integrations
like
web
books
like
status,
reporting
and
all
that
so
so
yeah.
A
So
it's
pretty
much
a
tool
that
is
easy
to
use
for
any
any
testers.
Devops
people
that
really
wants
to
test
in
kubernetes
and
wants
to
speed
up
their
their
development
workflow.
So
yeah
like
give
us
a
try,
go
to
tesco.io.
If
you
have
any
questions
about,
you
know,
test
tube
and
how
to
use
it,
go
to
our
discord's
Channel,
we
pretty
much.
We
are
there
all
the
time
answering
questions
or,
if
you
want
to
just
you
know,
send
me
an
email
or
book.