Rethinking Test Automation

Rethinking Test Automation

Why I Created a Course on Test Automation Architecture

Not so long ago I published my first course on Udemy. That happened to be a course on Test Automation architecture. Some people asked me why I thought it was a good idea to create this 80 minutes course. After all, there're so many other courses on the same topic.

Well, here's why.

What is Test Automation?

Test automation is the practice of automatically checking and validating a software product to make sure it meets expectations for code style and functional and non-functional requirements. Test automation is usually used for regression and automated acceptance testing and can be done on many levels, such as unit level, integration level and system level.

The biggest value proposition of most (if not all) test automation initiatives is that it will drastically save time.

Test Automation Challenges

Test Automation sounds simple and most of the courses out there can teach one how to quickly write automation scripts. The reality is if you want to maximize the value of test automation you need to make sure it is:

  • Maintainable

  • Communicates results in an easy-to-understand way

  • Accurate

  • Deterministic

And that is not an easy task at all. To make things worse, in many cases Test Automation is either done by Junior developers or by Test Engineers lacking proper development experience.

People do their best, but test automation is a complex development project. Lacking coding and architecture knowledge people tend to reinvent the wheel and use subpar or simply inadequate technical solutions.

As the result, test automation either not providing the best possible value or even gets in the way of the whole development team. And that's what I hope to address with my course.

Software Architecture and Test Automation Framework Architecture

Software architecture can be defined in many ways. I like to define it as a mental model, describing:

  • Parts of the software system consist of

  • How those parts communicate with each other

There's no one "Right way" to structure applications. If someone says there's they probably don't know what they are talking about.

Instead, architecture choices are made with non-functional requirements in mind. Different architectures make different non-function trade-offs. One of the brightest examples is a potential trade-off between readability and efficiency of the code.

The good news, is that most (if not all) test automation frameworks have similar non-functional requirements:

  • Maintainability

  • Readability

And for these requirements, there's a specific architecture pattern which works very well. It is called 3-layer pattern and my course is focused on teaching how one can use it for test automation.


Understanding software architecture may be something which differentiate between mediocre and great test automation engineer.

If you’re interested in learning more about test automation, then I invite you to check out my course. I'm confident that you will find it an invaluable resource in your journey towards becoming a test automation expert.

Sign up for my course today and learn everything you need to know about test automation!

Test automation architecture course is live on Udemy:

and LeanPub: