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.
Conclusion
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: https://www.udemy.com/course/writing-test-automation-framework/?referralCode=1677E64DC850B360E8A6
and LeanPub: https://leanpub.com/c/writingtestautomationframeworkfromscratch