If you're a test engineer wanting to learning automation, I strongly recommend venturing past the introductory courses and working on a real project whenever possible.
If your company has an existing test framework, that could be a great place to start. Or maybe you'd like to try something different for an area that doesn't have automation test yet.
If you're not currently working as a QA engineer, then you'll probably want to try out a few different frameworks. Here are some good resources for learning the basics of the more common frameworks and languages:
- Test Automation University
(free courses and fairly well maintained)
- Udemy
(some free courses, many reasonably priced; great sale prices)
TIP: When looking for good courses and tutorials, don't limit yourself to videos. There is a ton of great information in blogs and non-video tutorials.
You can also do a Google search for the specific topic you're interested in. Some of the most important things I've learned were actually from Google searches.
Even when following a course you've paid a fair amount of money for, there are likely to be hurdles for you to overcome. Invariably, you'll have some sort of missing file or library, or you'll already have a different version of whatever they want you to install, or...something (always something).
This is where we pay homage to Stack Exchange. If you get an error, try pasting a snippet of it into the Google search bar, and you'll be amazed at how many people had the same problem you did. Not only will it help you solve your problem, but you'll learn other things along the way. Just be patient...it requires a fair amount of troubleshooting to sort through so much info, pick a solution, and get it to mesh with your current project. I'm in Stack Exchange almost every day.
As you continue learning, make sure to apply it to an existing project. This forces you to really understand it...especially as you start using more advanced concepts and have to make significant changes to get it all to work together.
Introductory courses might help you create some test scripts for an existing framework, but they definitely won't be enough to build a good test framework. It's important to learn more the advanced concepts, such as by learning object-oriented design patterns like page object model. You'll probably also want to get a better handle on waits and the trickierer kinds of locators. You might want to learn how to run tests in parallel or parametrize your tests. And of course, continuing to improving programming skills is always important.
We've all heard that the best way to learn is by doing...but I would also add that it helps if you're solving an actual problem. If you're a QA engineer who doesn't feel ready to contribute to your company's regression suites, maybe you could create some tests on your own to do some of the things you hate to do manually. Automation can also be a great way to lift some of the burden of setting up complex tests.
Or maybe you can create your own application to test. For example, I added more pages to this website specifically to test against. Here are some Cypress tests that make it so I don't have to manually trigger the various kinds of validation errors.
Sure, it never feels like things are good enough to share, but it's a learning process for everyone. Plus this is good practice for using Git. You can also keep repositories private. And if it's for your employer, you'll probably want to put it on their GitHub (or whatever source control management system they use).
Here are my samples on GitHub:
My GitHubThey keep making it easier to determine locators/selectors (to use for tests that interact with the UI or DOM). These plug-ins are pretty handy:
- Selectors Hub
- Chro Path