Transcripted Summary
In the previous chapters, we have learned what is continuous testing, agile testing, and the whole team approach. We learned that automation is a crucial part of this. However, what if you're not an automation expert yourself yet?
What if there's no automation expert in the team at all? What if there is no one in other teams as well?
Someone, somehow, has to learn about automation. Let it be you or anyone else in your team. But, where to start?
There's an overwhelming wealth of resources and often they're ambiguous. There are books, blog posts, videos, courses, meetups, conferences, and many more. I mean the internet alone offers so many resources it can really feel overwhelming.
Now that the Test Automation University is here, this will be a great starting point as its content is curated.
So, what to learn first? I mean, programming maybe? Honing your skills? Or, what about tools? There are so many out there. Or, maybe how to build an automation framework.
What to focus on? This really depends on your contacts and the related risk a lot. You might not start with performance testing if there are no unit tests in place. In other places, performance might be the biggest concern.
There's a lot to consider — what we will focus on in the following is how to learn automation.
Of course, you can learn things on your own, trying to find your way through. I mean, have you ever tried to learn things on your own? I bet so. And so did I. And have you struggled with it? Well, at least I did.
I don't know about you, but my personal background of things I'd love to learn or try is continuously growing. I mean, I succeed in checking my Twitter stream, which is like my resource of latest news. Well, I'm occasioned to read books. I hardly manage to listen to podcasts on my lists and I rarely ever watch the videos and talk recordings I've bookmarked.
And what concerns hands-on stuff, well, I'm awesome in starting new hands-on learning projects endeavors at home, but I really suck at staying long enough with them to really learn something. So, mostly I end up in spending my time creating my to-do list on what to learn, to manage them, refine, at some point I archive them, and create them from scratch. So, learning on my own did not work out for me when it came to hands-on stuff.
Well, there are other ways to learn about automation that are not solo.
There are several courses and conference workshops offered, and you can share your learning journey with others attending the course. They might be on the same level as you or starting from a different one, but in any case, you're not alone, right?
The challenge here is to continue learning after the course, and to not again be alone when learning.
There's another option I got to know in the past year — going on tours.
I learned this mainly from the software crafter community. Several of these people went on the coding tour, like crafters go on their tours visiting other companies and teams to learn about their approaches. They learn hands-on with other people together, and then move on and learn with the next one.
I really got inspired myself of this notion, and I went on a testing tour in 2018. I paired with many testers and developers around the globe, hands-on, on many different challenges. And I really learned a lot about new topics, or I simply practiced. In my case, I could not afford taking the time off to visit different companies for a week each, so I decided to do shorter sessions remotely and, therefore, more of them with more different people.
In case you like to learn more about this, check out the linked page in the resources. Going on a tour can be great. A great way to learn about automation from the get-go, to more advanced or specific topics and challenges.
Another option how not to learn alone about things is to join or build up a personal learning network with people who are like-minded and eager to learn themselves.
This is a great opportunity to share challenges and solutions, exchange experiences and knowledge, as well as support each other on concrete learning tasks. Such a network does not have to be limited to your company. I mean, with today's tools you can find people all around the world and meet them. You can find mentors of different topics to help you in your learning journey, or you can even be a mentor on other topics yourself.
Again, not being alone can help with these kinds of challenges.
Let's assume you have built up a basis of knowledge to start with. But, how to start setting up automation in your own team? Angie Jones' course, Setting a Foundation for Successful Test Automation, here at the Test Automation University, gives a lot of pointers and I highly recommend watching it if you haven't already done so.
Here are a few set-up considerations I'd like to emphasize.
Which automation framework to choose? It can really help to select something, you know, that people are already familiar in your team. Maybe use a familiar programming language. Also, it should be easy to learn, to lower the entrance barrier. It should run on all computers and operating systems your team is using. It should support all devices that are deemed most risky for your product, and it should support creating a custom DSL, a domain-specific language, adapted to your product domain.
Especially for end-to-end tests, the question arises whether to have them in a separate repository or not. So, having it in the same repository can help a lot. Check out Angie's article about it, linked in the resources. One of the biggest benefits I see is shared ownership and more investment from the whole team. So, keeping it in the same repository makes it most easily accessible without impediments.
Quality practices should be the same for any part of the product, be it business logic, or test automation. So, if you do code reviews, have them for automation as well. Test your automation as well. Just as your infrastructure, or anything else.
When it comes to the test data setup, well, make sure any test can run independent from each other. If the tests expect certain test data to be present, don't rely on it being there, but include this in your scenario setup. For example, by using an API code for tests through the UI. In my team, we have started out with a test creating content we needed to delete every single time before we ran the test again. Let me assure you, no one does this for long.
Also, think about test environment and infrastructure. Where will the test run? Against which product version? You might want to test against production as well later on. Consider that tests also have to be easily run locally as well as for all team members. Check how you can authenticate in the chosen systems.
Automation should be included in the build pipeline. For many fast tests, we'll want to have them figured automatically within your build pipeline to get that fast feedback. And for some tests, that run longer, or that you only choose to run at certain times, you'd like to trigger them manually. Still better on a central infrastructure than on local system.
Also, think about how to get automation itself included in every day's work. You might need special product backlog items for the initial setup, but later on the work should be part for each and every story and considered by the whole team.
When starting out, you might try things and find better ways on your way.
You might build up some legacy at that. But, make sure to pay it back early on. And if you can only tackle it later, try to revise your automation incrementally.
These are only a few pointers to consider when starting out. Still, you have to find your own way.
The very most important point in all this, get your team on-board.
Collaboration on automation, as on many other tasks, is imperative if you want to succeed with it on the long-run in a truly agile team applying the whole team approach.
Therefore, we will have a look at different ways how to collaborate and learn automation within the team — with the pros and cons — in the next chapters.
