Welcome to chapter 3 of test automation essentials introduction.
Getting the whole team or at least a cross functional group of team members to take responsibility for test automation, is the secret sauce for success.
In this chapter, we'll talk about how to take advantage of the diverse skills on a development team and get non-testers to help with automation.
When the whole team thinks about test automation, developers start designing their code to be more testable.
This has a lot of advantages.
It tends to be easier to understand that code.
That production code is easier to change without fear of breaking something.
It's more robust and reliable.
This applies to the automated test code as well.
We have new test tools today that are appropriate for both experienced developers and for people who are new to automation and it allows them to collaborate and work together.
Often, people who are new to automation can get up to speed with automation fairly quickly, and then they get help as needed from developers.
For example, if they run into some difficult issue that their test uncovered and need help debugging it.
So pause the video for a minute, and think about your own delivery team.
Who else on that team can help you with test automation? How can they help? What skills do they have? If you're not on a cross functional team but you're on a seperate QA or test team, think about the software delivery team that you work with.
How could they help you? Is there something, for example, that the developers can do to make your user interface easier to test? Could they help you with choosing test tools for automation? Can they help you integrate automated test suites in the continuous integration? So just think about that for a moment.
Maybe talk it over with your colleagues.
In a phased and gated software development environment, automation is something that happens after all the coding and test is done.
It's at the end.
In today's Agile and DevOps software development environments, we have continuous testing and continuous test automation.
It's just happening all the time as we work in small increments and short iterations.
This is another reason that the whole team needs to be involved.
Few teams today have enough dedicated testers to do all the test automation, even if they have the skills.
And, we also have automation on so many levels and so many different types of automation.
For example, we may want our continuous integration to have automated spin-ups of test environments and automated deploys to those test environments to do the actual test automation scripts.
Many testers that I know are also really good at writing code and automating tests.
But, the particularly strong skill that testers have is knowing how to get the best test coverage given the team's resources for test automation.
They keep an eye on the big picture, they know what customers expect, they understand customer pain points, they understand how customers use the product.
They're really good at analyzing risk to the business and to customers.
So, working together with the developers makes sure that we get good coverage on our test automation.
Every team member should be able to contribute their deep specialized skills, even while they have broad skills to contribute in other ways.
People on the team who are not testers also contribute in many ways.
We need the expertise for DevOps activities to build supporting infrastructure, for example our continuous integration and delivery pipelines.
Many people who understand good coding design patterns and automation design heuristics to help create maintainable, efficient automated tests that give us the fast feedback that we need.
We need ways of learning from production use, with our monitoring, logging and analytics tools.
We need to be able to make our frequent changes to the code, deploy those changes to test environments, do the automated tests, as well as the manual tests we need to do, so lots of different skills needed.
Now how do we get everybody on the team engaged in this? Well, on four different teams, the way I've done it is to talk to the business stakeholders and understand what are the absolutely critical parts of our application that must work.
Can't take a chance on breaking them.
Then I wrote manual regression test scripts for each of these areas.
When it's time to release, let's say we're on a one week or two week release cycle, I pass those scripts out, divide 'em up with everybody on the team, developers, analysts, product owners, scrum masters, DBA, whoever, if we all spend time getting through those manual regression checklists, it's tedious and painful for everybody, and it gets everybody thinking about, "hmmmm, how might we automate this, these activities, so that we can use our time better, and add more value to our product?" So, that's really great motivation, sharing the pain.
As you talk about new features, talk about how you're going to automate tests for them.
Look at the things that are blocking you for automation, design experiments to get over your biggest roadblock, and keep moving forward.
You're gonna need a strategy to get started with your test automation, and we're gonna talk about that in the next chapter.
We're introducing a staple of test automation to help you determine which different levels you'll target with your test automation, plan out your automation strategy and how to start deciding on the best tools for your team.Go to Lesson 4