Hi! Welcome to Test Automation Essentials.
I'm Lisa Crispin.
I'm a testing advocate at mabl.
You can reach me anytime at this email address or ping me on Twitter.
For the last couple of decades, I've been working as a tester on agile teams and also co-writing books and developing courses with my colleague Janet Gregory.
Lately my interests have been in how to succeed with testing and test automation in the context of DevOps and Continuous Delivery and Deployment in our fast paced continuous world.
And when I'm not working, I'm playing with my three donkeys.
This is a class designed to introduce you to the essentials of test automation.
It isn't specific to mabl.
These practices and heuristics have worked for many teams in different contexts and may work well for you.
These are just guidelines to help you get traction on a new test automation effort.
You can apply these when you start automating tests with mabl, or with any other tool.
It's a great idea to watch this with other members of your team so you can discuss and try out the practices together.
Many teams today are already practicing Continuous Delivery or Continuous Deployment, where each time a new change is committed to the code base, a build is kicked off, a pipeline is started, lots of automated tests are run, and the end result is the change being ready to go to production or automatically going to production.
So it may go to production many times a week or many times a day even.
This is a goal for teams who aren't doing any of this yet.
How do you keep up with testing in that sort of environment? The principles, practices, and heuristics we'll cover in this mablU course will help you be aware of common obstacles to sustainable test automation and help you navigate around them.
Creating maintainable automated tests that give you value requires a team effort and a significant investment of time and money, though over time, you should be able to get a good return on that investment.
Just as with agile development, you'll work in small increments and build on your success iteratively over time.
This lesson will talk specifically about why we automate tests and help you think about your goals.
You can do continuous delivery or continuous deployment without automating your tests, this is actually true.
But, it's like driving at night without your headlights.
It's possible, but it's pretty risky most of the time.
Automating the boring stuff that you have to do over and over every time you release, like manual regression checking, testing across browsers, different devices, all the things that your product needs to support, if you automate all that, then you have more time for value add activities, like exploratory testing, accessibility testing, security testing, were it may not be possible to automate all the things.
It's a key part of the strategy to help your team safely make frequent, small changes without disrupting your customers.
I'd like you to take a moment to think about, "What is the biggest reason that your team is considering doing test automation?" So pause the video if you need to, especially if you're watching this with other members of your team.
Just talk about it a little bit.
There are no right or wrong answers, people automate for lots of different reasons, but being clear about your goals will help your effort be successful.
And, as you learn more about automation, your goals may change.
We can't automate everything at once, so we have to be specific about what we're trying to achieve right now.
Working in small increments iteratively lets us get fast feedback.
If you're familiar with lead development, you may have seen measurements like this, like lead time, cycle time.
It's a feedback loop that we're trying to shorten, we're trying to eliminate waste, we're trying to find out right away if any changes we introduced have broken anything our customers are already using in production.
So it gives us confidence.
And test automation is really key to shortening this feedback loop and letting us know right away when it's really easy and quick to fix the problems, if we've caused any problems.
So we also need to study production usage, now that we have lots of data about how our customers are using our product, perhaps in different browsers and devices, different operating systems, we can use that information to help focus our test automation in the right places.
In agile software development, we avoid, we try to avoid big design up front.
But at the same time, the delivery team along with the business stakeholders need to share understanding of how each new feature, each new capability of our product, should behave, so that we're always on the same page and we minimize re-work.
So, we can get business rules about how each feature should behave and illustrate those with concrete examples.
And those two things together not only help with shared understanding, and helping us guide our development, but they're also a great basis for automating our tests and focusing on the important scenarios.
And the great thing about this is, once we automate our tests and we keep them passing in a continuous integration pipeline, they become living documentation.
They have to be up to date, they always have to be passing, and they show exactly how our system behaves.
If you're having trouble selling your management on the idea of test automation, ask them if they would like reliable documentation of how the system works, so that as people leave a team or come back to a team or come join a team new, they know how the system works.
It's a really great benefit of test automation.
You may be familiar with the State of DevOps survey.
This is something done every year in the DevOps community, and there's a book called Accelerate that summarizes what they've learned from it so far, and one of the things that they have scientifically evaluated that correlates with high performing team success, meaning customers are happy, the people working on the team are happy, they're not killing themselves to deliver all this new value frequently, is that they have reliable automated tests that run every time they commit a new change.
The tests are primarily created and maintained by developers, which means they're probably creating more testable code which is going to be more reliable, easier to maintain, it's going to let them work faster.
And these same teams, the testers work right alongside those developers, not only on automating the tests but other testing activities like exploratory testing, so I highly recommend this book to give you some ideas about the practices that might help your team.
We hear people talk about reducing the cost of testing, but testing is not a separate activity from software development.
It's an integral part, along with coding, design, architecture, database, everything involved with software development is part of one whole and we can't just simply get rid of part of that.
Test automation done well lets us deliver more value, more frequently, and it also helps us enjoy the process more, because it helps us work at a sustainable pace.
I have a safety net to know right away if we've broken something so we don't have to worry.
In our next chapter, we'll look at some common automation roadblocks.
Hi, I'm Darrel, a mabl solution architect.
I've worked with software teams for around 20 years,
often as a tester,
and I'm excited to be your guide through this series of videos
in which we'll explore all the different features of mabl
so you can learn how to use our product to implement
a successful front end test automation solution for yours.
We're gonna start at the very beginning with the basics
before moving onto more advanced topics like
conditional logic, generating test data,
visual and responsive testing, all kinds of stuff.
You're gonna learn how to create user journeys
through your application with the mabl trainer,
how to configure them to run in stages or in parallel,
and how to interpret all the different diagnostics,
metrics and insights that mabl provides.
And I hope you're ready, because it's going to be hands on
with exercises you can do yourself.
mabl's ethos is rooted in the fact that
testing plays an essential, vital role in
software development, and particularly in a
quality centered, DevOps driven agile culture.
We call it DevTestOps.
I'll show you how mabl empowers teams to
develop and maintain their automated front end tests more efficiently,
while eliminating the infrastructure and framework headaches
that tend to plague traditional approaches.
Only mabl offers script-less, cross-browser testing,
visual testing and diagnostics and monitoring in
one simple service so teams work more efficiently.
It can free up time for exploratory testing, increasing test coverage
or any number of activities.
mabl is a UI testing tool for web applications.
It's not for testing desktop applications.
mabl currently only tests on desktop web browsers.
We cannot, at least yet, test native mobile apps
or within native mobile browsers.
We can, however, pass a mobile user agent string
and test at any break point that you like.
If your site has bot detection,
you'll need to let it know we're coming.
If your application under test isn't publicly available,
we offer static IPs that you can whitelist
and make our traffic very identifiable
in a number of ways.
We also offer the ability to establish a secure
and smart tunnel between our infrastructure and your environment.
mabl can't solve captchas, so if you have those,
you'll need to make sure some kind of bypass
mechanism is in place.
And if any of these issues are difficult to
mitigate quickly, that's okay.
We have a sandbox application
that you can get started with.
In fact, we're gonna be using it in the next video.
Welcome to mablU, let's get started.
In the second lesson, learn what to prioritize when planning out your automation strategy, how to approach your team and get them on-board with the process, and the "hump of pain" that drives many would-be test automaters away before they start seeing returns on their work.Go to Lesson 2