Hi! Welcome to Chapter 2.
A lot of people encounter the same problems or similar problems when they try to automate regression tests.
We're gonna look at some of the common roadblocks that people face and teams face, and start thinking about how we might overcome them.
We'll talk about what you can expect as you begin a new automation effort.
Stop and think about this and talk to your colleagues about it.
Let's face it: test automation is hard.
If it were easy, we wouldn't be here.
What has held you and your team back up to now? Maybe you've tried to automate tests before, and either you never got traction on it or maybe you were automating a lot of UI tests and then you did a major redesign of your product's UI and all those tests needed to be changed and it just felt like too much effort.
So pause the video for a few moments and think about "What's the one biggest thing in your way for test automation?" and we can think about how to overcome that.
I'm guessing you may have thought about some of this.
Yes, after decades of test automation, when I start a new automation project, I do feel a little fear, it's normal.
Got a lot of unknowns, we don't know what problems we're gonna run into.
But we can be confident; we can learn the skills to overcome it.
And yes, it takes time and money to learn the skill, even if you're using an open source tool that you didn't have to pay money for, you're still paying money to learn it, you're sitll paying to learn how to do good practices for maintainable tests for your testable code, your production code needs to be testable, so a lot of components to that.
And, yes, we do need to get new skills and tools, we need to think about what happens if we're automating UI tests and that UI changes, so these are all things that, with modern UI tools, we can overcome these.
And it is an investment, it is going to pay off over time, if we take the time to do it well and get a good solid basis.
This diagram is something from Brian Marick, from years ago, and he called it the Hump of Pain.
And this particular illustration is from Gerard Meszaros' wonderful book, xUnit Test Patterns.
So when we start doing test automation, whether it's test driven development or automation at other levels than the unit level, it's all going to take us more time, we're learning new things, we don't already have a library of reusable components to use, and it's more work on top of what we were already doing, and we're probably still doing manual testing at the same time, so especially if we're working on legacy code that doesn't have automation right now, perhaps it's designed very poorly, it's not very testable, it just can seem impossible.
But, I promise you there are ways to do it.
Still, you may run into some team members who say, you know, it's too much work, let's just manually test it and then not ever test it again.
Well, if you never are gonna change it again, that may be a viable approach, you have to think about that.
So, probably you are gonna change it, and you probably are gonna benefit from some automation.
But notice, once we acquire the skills and get good with the tools we're using and build up a library of reusable components, and as we've learned to make our code more testable, it's easier and easier to automate.
Now it takes us less time to deliver the same code to production; supported by automated tests, we have a lot of extra time we can use for other testing activities, we can use it to study production usage and learn what customers are doing, what's valuable to customers, maybe spend time upfront in the design efforts with customers, lots of other things we can do with that time, so it's really going to pay off.
In most contexts so as I say, automation does require a significant investment, and we talked in the first chapter about setting goals, so set a small realistic measurable goal around test automation to start with.
Maybe your first step is going to be to put together a test strategy for test automation, and we're going to talk about that in future chapters.
Maybe your team gives yourself a couple weeks to come up with a basic strategy, and then you have some kind of measurement to know "yes we think we have a strategy that we can build on and keep going," or "oh we don't like our strategy we need to redo it," that's okay because we want to invest in the right things so we can go faster later on.
So, decide what you want to do, how you'll measure your progress, and figure out if you got your desired outcome.
Nobody can afford to automate everything all at once, it just cannot happen, so give yourself time to figure out a good approach for your team.
Maybe there are some parts of your application that are notoriously buggy, and you're getting bugs reported in production all the time, maybe they're not that bad but they're annoying and you're spending a lot of time fixing them.
Maybe that's where you want to put some safety net of automated regression tests first so that more changes to that don't break it.
Or maybe there're some parts of your product that your business stakeholders say, "these absolutely are critical and have to work," "our customers can't live without these, even for a few minutes," so that's where we want to put our first test automation efforts, in those critical areas.
Wherever you can add the most value at first, start with that.
And, at the same time though, as I said, make a small goal, do a small increment, maybe just automate a small number of tests at first, and you're going to immediately see some benefits.
Don't rush the process.
As you get going and learn more, you will be able to go faster.
And we'll talk about this more in later chapters.
So I can give you a really good tip on starting a new test automation effort, and I've done this now, I think with four different teams.
So get with your business stakeholders, find out what's really important and has to work in your product, write down your manual release regression checklist, and every time you need to release to production, maybe you're on a team releasing every two weeks, just split those checklists and tests up with everyone on your delivery team.
Product owner, DBA, developers, analysts, everybody.
And say, "okay, we're gonna spend a few hours now doing this release regression testing so we can feel good about releasing.
" It's highly motivating, people see how tedious it is to have to do these tests over and over.
And it's really hard to make sure that you follow all the instructions, and if you see a problem, it can be hard to reproduce it.
So they're going to start thinking about, "how can we design our code to be testable? How can we starting doing some test automation so that we don't have to do this really boring tedious work and free our time up for the more important work where we really feel like we can add value?" So, that's one way to share the pain and sharing the pain means that we get change a little faster.
In the next chapter, we're going to look at more ways to engage your whole team in automating tests and discuss why that's important.
After you've shown your team the potential value of test automation, now you need to know how to utilize the particular skills of your team to their maximum effectiveness, which is what we're covering with the next lesson.Go to Lesson 3