<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Rati's Blog]]></title><description><![CDATA[Rati's Blog]]></description><link>https://ratiblog.hashnode.dev</link><image><url>https://cdn.hashnode.com/res/hashnode/image/upload/v1593680282896/kNC7E8IR4.png</url><title>Rati&apos;s Blog</title><link>https://ratiblog.hashnode.dev</link></image><generator>RSS for Node</generator><lastBuildDate>Fri, 25 Sep 2026 07:20:27 GMT</lastBuildDate><atom:link href="https://ratiblog.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[How I Use Claude & Codex Daily as a QA Automation Engineer (Top 5 Real Use Cases)]]></title><description><![CDATA[AI isn’t replacing QA engineers—but it is quietly replacing a lot of the repetitive, time-draining work we used to do manually.
In my day-to-day work as a QA Automation Engineer, tools like Claude and]]></description><link>https://ratiblog.hashnode.dev/how-i-use-claude-codex-daily-as-a-qa-automation-engineer-top-5-real-use-cases</link><guid isPermaLink="true">https://ratiblog.hashnode.dev/how-i-use-claude-codex-daily-as-a-qa-automation-engineer-top-5-real-use-cases</guid><category><![CDATA[#ai-tools]]></category><category><![CDATA[gen AI in software development]]></category><category><![CDATA[codex]]></category><category><![CDATA[claude]]></category><dc:creator><![CDATA[Rati Jha]]></dc:creator><pubDate>Sat, 18 Apr 2026 17:26:03 GMT</pubDate><content:encoded><![CDATA[<p>AI isn’t replacing QA engineers—but it is quietly replacing a lot of the repetitive, time-draining work we used to do manually.</p>
<p>In my day-to-day work as a QA Automation Engineer, tools like Claude and Codex have become less of a “nice-to-have” and more like a second brain. Here are the top 5 ways I actually use them in real projects, with practical examples.</p>
<h3>Generating Test Specification Documents in Minutes</h3>
<p>Writing test specs used to take hours—especially when translating requirements from Jira into structured test scenarios.</p>
<p>Now, I feed the requirement directly into Codex and get a clean first draft.</p>
<p>Example input:</p>
<p>Generate a test specification for a login feature with:</p>
<ul>
<li><p>valid login</p>
</li>
<li><p>invalid password</p>
</li>
<li><p>locked account</p>
</li>
<li><p>session timeout</p>
</li>
</ul>
<p>Output (refined):</p>
<p>Test Case ID Preconditions Steps Expected Results</p>
<p>Instead of starting from scratch, I just review and refine.</p>
<p>👉 Result: ~70% time saved on documentation.</p>
<h3>Bulk Code Changes Without Losing My Mind</h3>
<p>Refactoring test code across multiple files is painful—especially when patterns change.</p>
<p>Using OpenAI Codex, I can describe the change once and apply it everywhere.</p>
<p>Example:</p>
<p>Update all Selenium locators from XPath to CSS selectors</p>
<p>Or:</p>
<p>Replace time.sleep() with explicit waits across test files</p>
<p>Instead of manually editing 20+ files, I:</p>
<p>Generate the updated pattern Apply it across the repo (via scripts or IDE tools)</p>
<p>👉 Result: Faster refactoring + fewer human errors.</p>
<h3>Writing Python Test Scripts from Plain English</h3>
<p>This is probably the biggest daily win.</p>
<p>I describe a test flow, and Codex generates a working script in Python.</p>
<p>Example prompt:</p>
<p>Write a Selenium test in Python:</p>
<ol>
<li><p>Open login page</p>
</li>
<li><p>Enter username/password</p>
</li>
<li><p>Click login</p>
</li>
<li><p>Verify dashboard is visible</p>
</li>
</ol>
<p>Generated output (simplified):</p>
<p><code>from selenium import webdriver from selenium.webdriver.common.by import By</code></p>
<p><code>driver = webdriver.Chrome() driver.get("https://example.com/login")</code></p>
<p><code>driver.find_element(By.ID, "username").send_keys("testuser") driver.find_element(By.ID, "password").send_keys("password") driver.find_element(By.ID, "login").click()</code></p>
<p>assert "Dashboard" in driver.page_source driver.quit()</p>
<p>I still review it (always), but it removes the “blank page problem.”</p>
<p>👉 Result: Faster test creation, especially for repetitive flows.</p>
<ol>
<li>Research &amp; Deep Dives Using NotebookLM</li>
</ol>
<p>When I need to understand a new tool, framework, or testing strategy, I use NotebookLM.</p>
<p>Instead of:</p>
<p>Reading 10 different blogs Piecing together info</p>
<p>I:</p>
<p>Upload docs / links Ask targeted questions</p>
<p>Example:</p>
<p>Summarize best practices for API test automation using Python</p>
<p>It gives:</p>
<p>Structured insights Key patterns Simplified explanations</p>
<p>👉 Result: Faster learning with less noise.</p>
<h3>Generating Edge Cases &amp; Test Ideas</h3>
<p>This one is underrated.</p>
<p>AI is great at thinking of scenarios you might miss.</p>
<p>Using Claude, I ask:</p>
<p>List edge cases for a payment system</p>
<p>Output includes:</p>
<p>Network failures Duplicate transactions Currency mismatches Timeout scenarios</p>
<p>This helps strengthen test coverage beyond “happy paths.”</p>
<p>👉 Result: Better quality tests with minimal extra effort.</p>
<h3>What Still Needs Human Judgment</h3>
<p>Let’s be real—AI isn’t perfect.</p>
<p>Things I never fully trust AI with:</p>
<p>Final test logic validation Business-critical edge cases Debugging flaky tests</p>
<p>AI helps you move faster—but you’re still the quality gate.</p>
<h3>Final Thoughts</h3>
<p>The real advantage isn’t just using AI—it’s knowing where it actually saves time.</p>
<p>For me, that’s:</p>
<p>Documentation Boilerplate code Refactoring Research Idea generation</p>
<p>If you’re in QA and not using AI like this yet, you’re honestly leaving a lot of efficiency on the table.</p>
]]></content:encoded></item></channel></rss>