Hi, this is chapter 4 of test automation essentials introduction.
In this chapter, we'll introduce the test automation pyramid as a starting point to discuss and plan your automation strategy.
To implement this strategy, your whole team will have to work together, step by step, choosing appropriate tools, deciding who will do various automation activities, and evaluating your progress as you go.
We'll point you to some more in depth information about creating and implementing an automation strategy, but this should get you started.
Manual regression testing can really eat up a lot of your team's time, and keep your from doing more valuable testing and development activities.
As we discussed earlier, we need a variety of skills to succeed with automation, and that includes getting the whole team involved.
You want the team's buy in for all the test automation tools you decide to use.
Together, the team will decide who will do which automation tasks, and, over time, you're going to evolve your test automation strategy as you evaluate your progress and your goals.
Now this is a classic test automation pyramid from Mike Cohn, and it's often misunderstood because people look at it and say, "oh, it must be calling for a certain percentage of testers at each of these levels, we've got the unit level and component level tests that developers write for small chunks of code.
We've got the API or service level tests that tests business logic at this intermediate layer without the user interface.
And then, we've got the end to end tests that do use the user interface.
So, all this model is trying to tell us is let's push as many tests as we can, as makes sense, down to the unit and component test level because those are the quickest to rate, the easiest to maintain and they give us the fastest feedback.
And then where it makes sense, put it in that middle services layer.
But, there are still things that we need to test through the user interface.
We may want to minimize those because they can take longer to write, they could be more work to maintain and they tend to take longer to run so they're slower feedback.
But, there are no hard and fast rules here.
There are some new generation test automation tools that make it easier to automate tests in the UI and make those tests faster so this is just a guidance for you.
And there's also other models, we'll talk about that in a little while.
So, see what works best in your context.
So, I've got a little example here, which is an example story for a hotel booking site.
A person can enter their billing address in order to book a hotel.
So they're gonna input a name, street address, postal code, country.
I put some different tests that might need to be done, and I'd like you to pause the video and think about which layer of that pyramid model would you do the testing in.
Would you do the tests at the unit level? At the API and services level? Or would you do it end to end through the user interface as a workflow test? So just pause the video for a minute, see what you think.
There are no right or wrong answers so don't be afraid.
Do this together with a teammate, if possible.
Okay, so again, no right or wrong answers.
"Postal codes from all countries allowed", well validating postal codes, I know there are third party APIs for that, so that may be something, you could possibly test that from the unit level.
Or, you may be wanting to validate any error messages that are returned and maybe that needs to be at a higher level, even the UI level because you want to know exactly where it is that your messages display.
So those are all things that are dependent on what your application requires.
Having the field actually change format in the UI there, like the postal code format in the UI changes depending on country selected, that's probably something you have to do in the UI level.
So, some of these things can be done at the unit level, maybe in different architectures, it would be possible to do them at different levels.
Think about what works for your application when you use a model like this.
The most important thing is that talking about tests with a model, a visual model, helps you have conversations with other team members and testers, developers, or product owners, and it helps you think about how to design your application and your code.
And how you wanna test it.
I've talked a lot about the whole team taking responsibility for test automation, or at least a cross functional group of that team.
There are a lot of demands on a team's time, so it can be hard to keep the focus, but you really need to.
Every time you have to go through the manual regression checklist before release, get the other members of the team who aren't testers to help with that.
Set attainable goals as you go.
We're gonna talk in the next chapter about deciding where to start with your test automation once you have a strategy.
Check your progress with each retrospective, do that frequently.
If you're not moving towards your goal, think of another way to approach it.
If your experiments fail, that's fine.
You're always learning.
We're lucky these days to have many different types of test automaton tools available, both open source and commercial, and some teams find it effective to build their own.
But, resist the temptation to choose the most popular tool because it'll look good on your resume.
It may not be the best fit for your team and your situation.
Think about who will be specifying the tests, who will be automating them, are these people who are already writing code? Think about the learning curve involved, and remember that one of the most valuable aspects of automated tests is that the tests become living documentation of how our system works.
Who needs to be able to read these tests and read that documentation? If only the programmers will ever read them, eh, they can be written in code.
But if non-coders on the team need to understand them, then they need to be in some kind of understandable format.
For example, when I worked for a financial services company, it worked well to have a spreadsheet-like format for our tests, with inputs and expected outputs.
They could understand that.
So, as you define your needs for automation, start researching tools that meet those needs.
Budget time to try them out.
My teams have had good results by trying two test automation solutions side by side, automating tests for the same features and stories in both to see which ones fit our needs the best.
It's a big investment to do that, but hopefully you're gonna be using these tests and these test tools for years to come.
Again, we don't want to spend our time in planning paralysis, but get some working agreements within the team before you kick off your first automation effort.
This is all part of your strategy.
The whole team is responsible for making sure it gets done, but individuals on the team need to step up for a certain test based on their skills that may be more appropriate to do those tasks.
A lot of these tests are best done by a pair of people, with different skills, or a cross functional small group of people.
For example, a tester and an operations engineer might work together to configure the continuous integration pipeline which test suite failures should stop the whole pipeline and send a failure alert to the team and let them know action's needed.
And when there is a failure, somebody on the team needs to take responsibility for making sure that failure gets investigated and taken care of.
So get these agreements up front.
There are lots more models you can use to formulate your automation strategy, and again these are all about visual models that your team can have a conversation around and decide what's best for your team.
And there's a link here here to my three part webinar series on using visual models to help you form your automation strategy.
So, I encourage you to check that out if you want more information.
So, we're just getting started with formulating and implementing our test automation strategy, and we know nobody can afford to automate everything all at once.
How do you decide where to start? We'll get some ideas in the next chapter.
Learn how to consider the risk and value your features have when choosing which tests to automate first, how to get your developers to start using test driven development and how to get immediate benefits from your automation.Go to Lesson 5