Hello,
I am embarking on a long journey into QA automation—and documenting my experiences along the way.
Just a few months ago, while I could run pytest, I lacked a clear understanding of what a professional automation framework actually looks like.
I was familiar with some basic concepts of Python and automation. However, there was a significant gap between knowing isolated tools and understanding how everything integrates within a real-world QA engineering workflow.
So, I decided to bridge that gap through hands-on practice.
I am following a roadmap comprising over 200 practical, hands-on projects. It begins with Python and Playwright, progressing through CI/CD, observability, and AI-assisted testing, ultimately leading to the creation of an AI-driven QA platform.
Here is what I have worked on so far:
✅ Python Fundamentals
✅ Playwright
✅ Pytest
✅ Page Object Model
✅ API Testing
✅ Authentication and Session Handling
✅ Network Interception
✅ Screenshots, Traces, Videos, and HTML Reports
✅ GitHub Actions and CI/CD
I am currently approaching Project 152 (P152).
Through this process, I have realized something important: learning QA automation isn't just about learning how to write a test.
It is equally crucial to understand what happens when a test fails. For instance, I recently set up a CI 'quality gate' for a project where the process went like this:
Tests fail
↓
CI pipeline fails
↓
Evidence or data regarding the failure is collected
↓
Artifacts are uploaded
If a test fails, the pipeline should fail too—but I didn't want the evidence or data concerning that failure to be lost along with the pipeline itself.
It was a small project, certainly, but it taught me a valuable lesson about how a real-world CI pipeline should function.
Throughout this journey, I will continue to document my project, mistakes, problem-solving approaches, and everything new I learn.
Top comments (0)