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.
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