To be clear — I’m not a developer. I work in a C#/.NET environment, but only at the test level: I read and understand the codebase, work in Visual Studio to navigate code and configurations, analyze APIs, trace logs, and write SQL queries for data validation. I do not write production code.

What I do write is JavaScript helpers and bookmarklets for testing tasks, and I’m currently learning Playwright. The UI Diff tool in My Projects is an example of what I’ve built using AI assistance — what people call "vibe coding".

Cloudbeat is a test management platform with a built-in runner — similar to TestRail but with the ability to execute tests directly. My role is to run test suites, monitor results, and analyze failures: root causes, regressions, and areas needing follow-up.

Yes — I’m a beginner-level automation developer, and that’s a deliberate starting point. Every manual test I do, I ask: “Could this be automated?” When I find a repeatable root cause, I cover it with automation to prevent regression.

I’m building Playwright skills, exploring fixture architecture, and developing my vibe coding approach to build practical QA tools.

Logs first (Coralogix, Stackify, Kibana), then API behavior via Postman/Swagger/Fiddler, then data validation via SQL, then environment comparison (DEV vs QA vs UAT vs PROD).

Goal: isolate the root cause — not just reproduce. Is it Jifiti-side, a lender issue, a config error, or a data problem?

I include: exact reproduction steps, relevant log lines with timestamps, API request/response payloads, SQL results that confirm data state, and a root cause hypothesis.

Goal: developer reads the report and goes straight to the fix — no 30-minute reproduction session.

Growing into an automation-heavy QA or SDET role — combining backend understanding, system-level thinking, and Playwright/JavaScript skills to build scalable test infrastructure.