Test automation: what kind of depth in terms of learning do you prefer?

🙋 Questions
, ,
1

So you’re learning a test automation tool like Playwright or Webdriver IO or Cypress.

  • You’ve followed the tutorials, got the tests setup.
  • You’ve also made the CI/CD integration, built a page object model, setup before and after hooks, added tests of different types etc…

BUT
You’re not exactly an expert in the language being used. Yes, you can still code and build tests endlessly (with a little help from an AI) but when it comes to coming up with custom solutions for problems or suggesting solutions to the open source test framework issues, you’re just not there yet.

At this point what matters most?

  • Learning the language in depth
  • Learning the tool(s) in depth
  • Focusing on test coverage of your software
0 voters

or do you think there’s a combination that works best?

2 Likes
2

Im a bit piecemeal. I hew to not letting perfection be the enemy of good, as they say.

Identify the problem
Learn as much as I need to find a working solution to the problem
Refine it later as my knowledge grows.

I also note that in order to identify a problem, you have almost always already been managing it in some way already. So “Do nothing” is the base and resolving that problem in better ways is the iteration.

3 Likes
3

Earlier in my career I probably would have focused on test coverage first, but I’m now in a position where I try to think ahead.

Focusing on learning the tool/language in depth helps with the creation of reuasble code/libraries/classes - which is something that might not be considered if you only focus on test coverage.

3 Likes
4

A mix trying to cover the 3 approaches now and then would be ideal. There are pros & cons with just focusing on each one, and none are perfect alone.

I would suggest the following as well:

Learning language should be more about programming concepts than specializing in a specific language, granted for work, you would focus on the language currently used in your test setup. Focusing too much on the language itself gets you siloed on using it, learning how programming concepts work and be open to other languages while learning your primary language allows you to adapt to other tools and languages as needed, flexibility for your needs and career - mentioning as sometimes some tools work only in certain languages or work better with certain languages. You don’t want to silo yourself based on specialization to certain language or tool.

Also, with respect to learning language or programming concepts, consider learning conceptual design/modeling techniques when writing code, like for example page object model design. I’ve seen cases where page object model has been used, but the way it is implemented in terms of the interface is static and limits the way you do the automated testing or how much testing you can cover. Refactored properly, it could allow for more additional test coverage and more readable tests without writing more boilerplate copy & paste code. But it does require a certain degree of design and programming knowledge to properly abstract the code that does the automation from the test cases themselves, where yes, there is a certain level of more complexity in the low level implementations for automation logic, but the high level interface for the test cases allows for easier writing of tests and more writing of tests without spaghetti code in the low level page object model code. What I’m trying to summarize here is that if you don’t have enough design and programming knowledge, trying to increase test automation coverage may:

  1. be a harder/longer effort to tackle due to the increase in work needed from lack of experience
  2. generates more unnecessary boilerplate code to cover more test cases when if done properly can do in fewer lines of code, and even fewer test cases if you can rework some test cases to be data driven for more dynamically generated tests.
1 Like