►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Lightning Talk: Automated Testing Done Right - Aditya Bansal, Cortex
Virtual Track
Speakers: Aditya Bansal
As software engineering tools and languages continue to evolve, it has become easier than ever to write software that touches billions of users. With the advent of cloud providers like AWS, GCP, Azure, and several more, the continuous delivery of software is a very reachable milestone, for companies of all sizes. But what about quality? How do we ensure that every commit we send to production is not going to fail? In this talk, Aditya will review lessons that he has learned from working on testing & CI/CD infrastructures at three different startups as an early engineer. He will also cover how not to make the same mistakes he did.
A
Today,
I'm
going
to
speak
about
automated
testing
the,
why
behind
it,
what
it
actually
entails
and,
most
importantly,
how
to
achieve
it
in
your
engineering
organizations
without
making
your
head
hurt
first
off,
why
do
we
want
automated
testing?
What
is
the
problem
that
we're
trying
to
solve,
for
the
data
suggests
that
bugs
or
software
defects
that
are
caught
in
the
maintenance
phase
are
100x
more
expensive
than
catching
them
earlier
in
the
life
cycle,
there
is
literally
a
massive
financial
loss
to
companies
for
not
investing
in
this
kind
of
automation.
A
Moreover,
many
a
times
lack
of
testing
can
lead
to
a
very
problematic
customer
experience
which
eventually
leads
to
them.
Trending
not
just
that
from
an
engineering
cultural
perspective,
production
bugs
lead
to
frustration,
because
engineers
don't
want
to
spend
time
worrying
what
would
happen
if
they
release
new
code.
They
want
to
focus
on
releasing
it
burnout
as
well,
because
more
bugs
means
more
firefighting
means
longer
hours,
which
eventually
leads
to
a
frustrating
experience
for
the
engineers.
A
This
is
more
common
in
the
industry
than
I
originally
thought
it
would
be,
and
it
pains
me
to
see
so
many
engineers
go
through
this
and
finally
attrition
if
engineers
work
in
an
environment
where
they
feel
frustrated
for
too
long,
they
just
end
up
leaving
because
there
are
better
opportunities
elsewhere
and
on
the
flip
side,
the
biggest
benefit
of
having
these
checks
and
balances
include
a
higher
quality
product,
the
biggest
one.
This
cannot
be
emphasized
enough
as
more
and
more
software
is
being
written.
A
A
So
what
exactly
is
automated
testing?
In
my
mind,
it's
a
set
of
checks
that
are
run
on
every
commit
to
your
main
branch.
These
checks
do
three
things
number
one
they
validate
that
the
existing
functionality
works
as
expected.
Number
two:
they
validate
that
the
new
code
works
as
expected
and,
most
importantly,
number
three.
They
tell
you
what
is
not
working
and
in
an
ideal
world,
they
block
you
from
pushing
this
code
to
production.
A
Now
that
we've
spoken
about
why
this
is
important
and
what
it
actually
entails.
Let's
talk
about
the
technical
parts.
Automated
testing
is
honestly
an
umbrella
term
that
needs
to
be
broken
down
into
smaller,
more
achievable
chunks.
The
most
common
form
of
this
is
breaking
it
into
a
pyramid
of
tests.
For
the
sake
of
simplicity,
let's
talk
about
the
three
biggest
pieces
under
this
category.
A
A
The
definition
of
what
a
unit
is
is
very
debatable
in
the
industry,
but
in
most
cases
it'll
be
your
classes
in
the
object,
oriented
programming
world
or
your
functions.
If
you
prefer
functional
programming,
then
come
the
integration
tests
when
you're,
confident
that
each
individual
unit
works
as
expected,
you
can
move
on
to
the
next
step,
which
is
testing
logical
groupings
of
units
together
and
testing
them
as
a
black
box,
for
example,
if
you're
building
a
web
server.
A
This
can
be
a
controller
test
that
don't
care
about
what
services
are
being
used
or
what
the
underlying
implementation
is.
Then
comes
the
final
piece,
the
end
to
end
or
your
ui
tests.
This
is
where
you
would
test
the
app
as
if
the
customer
would
use
it.
Let's
say:
you're,
building
an
e-commerce
website.
A
simple
end-to-end
test
case
will
include
the
user
signing
up
adding
a
product
to
the
cart
and
checking
out
successfully
keep
in
mind.
A
One
final
piece
I
wanted
to
touch
upon
that,
I
think,
is
usually
not
spoken
about
as
much
as
I
think
it
ought
to
be.
Is
culture
from
what
I've
observed
unless
the
higher-ups,
your
your
managers,
your
vps,
your
exec
team,
understand
the
value
out
of
this
automation.
Nothing
is
going
to
get
done
in
this
domain
many
a
times.
This
becomes
an
influencing
problem
for
engineers
more
than
an
engineering
problem.
How
do
I
convince
my
higher
ups
that
will
save
the
company
a
lot
of
money
by
investing
in
this
rather
than
the
n
plus
one
feature?
A
How
do
I
convince
my
engineers
that
no
the
code
is
not
perfect
and
it
will
break
at
some
point.
The
thing
that
worked
the
best
for
me
was
to
start
by
getting
buy-in
from
each
of
them
and
add
different
strategies
for
both
of
these
groups.
For
the
key
decision
makers.
This
can
include
showing
them
the
data
show
them
the
percentage
of
time
engineers
spend
on
jira
issues
with
labels
bugs
or
the
number
of
customers
that
have
churned
because
of
the
regressions
and
for
the
engineering
team.
A
I'd
say,
start
small,
build
a
proof
of
concept
of
a
simple
class
being
broken
down
into
multiple
tests.
Show
them
how
easy
it
can
be
to
go
from
testing
everything
manually
to
just
waiting
for
your
ci
provider
to
report.
The
results
tell
them
about
the
possibility
of
less
firefighting
and
the
better
work-life
balances.
This
will
eventually
lead
to
with
all
of
this,
I
believe
teams
can
move
beyond
the
painful
cycle
of
finding
and
fixing
and
finding
bugs
and
focus
on
what
matters
the
most,
which
is
building
amazing
products.
Thank
you.