In Part 3 I introduced Cursor and why IDE tools beat CLI for QA automation. But before we go deeper into Cursor features, there is a bigger question worth answering. ──────────────────────────────────────── 𝐓𝐰𝐨 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐬. 𝐒𝐚𝐦𝐞 𝐌𝐨𝐝𝐞𝐥. 𝐃𝐢𝐟𝐟𝐞𝐫𝐞𝐧𝐭 𝐑𝐞𝐬𝐮𝐥𝐭𝐬. Engineer A asks GPT-5.4 to write a login test. Gets back: a clean, structured test. Uses their proper fixtures. Follows their naming convention. Works on first run. Engineer B does the same thing. Same model. Same task. Gets back: a generic, broken test. Hardcoded credentials. No page objects. Fails immediately. ──────────────────────────────────────── 🚫 𝐌𝐨𝐬𝐭 𝐏𝐞𝐨𝐩𝐥𝐞 𝐁𝐥𝐚𝐦𝐞 𝐭𝐡𝐞 𝐌𝐨𝐝𝐞𝐥 "GPT is bad at tests." "GPT doesn't understand Playwright." "I need a better model." That is the wrong diagnosis. The model is not the problem. All modern models can code really well. Three other things determine quality. ──────────────────────────────────────── ⚙️ 𝐋𝐚𝐲𝐞𝐫 𝟏: 𝐓𝐡𝐞 𝐓𝐨𝐨𝐥 As covered in Part 1, you never talk to the model directly. ► You ► Tool ► Model The tool decides what to send to the model. What context. What files. What history. Cursor sends your repo structure, open files, and recent edits. A chat app sends nothing. Same model. Different tool. Completely different output. ──────────────────────────────────────── 📁 𝐋𝐚𝐲𝐞𝐫 𝟐: 𝐑𝐞𝐩𝐨 𝐐𝐮𝐚𝐥𝐢𝐭𝐲 AI agents amplify whatever already exists in your project. Good framework? The agent writes tests that slot right in. No page objects, no fixtures, no structure? The agent writes whatever it can. Which is usually a mess. This is the hard truth: AI cannot rescue a bad codebase. It makes it worse, faster. The model is only as good as what it can see. If your repo has: ∙ Clear fixture files ∙ Consistent naming ∙ Reusable page objects ∙ Good test examples The agent pattern-matches against all of that and writes code that fits. If it sees nothing, it invents everything. Pure lottery. ──────────────────────────────────────── 📝 𝐋𝐚𝐲𝐞𝐫 𝟑: 𝐓𝐡𝐞 𝐓𝐚𝐬𝐤 𝐒𝐩𝐞𝐜 "Write a login test" is not a task spec. It is a hint.

Hey QA fam! 👋 Ever been asked in an interview about the difference between smoke and sanity testing? It’s a classic question! They sound similar, but they’re actually different. Here’s the quick breakdown: Smoke Testing 🔥 Think: “Does this thing even turn on?” It’s a broad but shallow check to see if your app’s critical functions work at all. When to run it: • Right after a new build drops • Before starting detailed testing What you’re checking: • Can users log in? • Does the homepage load? • Do critical workflows start? Example: New build deployed → Quick smoke test checks login, navigation, basic functionality → If it fails, reject the build immediately. Sanity Testing 🧠 Think: “Did that bug fix actually work?” It’s a narrow but deeper check on specific functionality after a bug fix or small change. When to run it: • After a bug fix • After a minor code change What you’re checking: • Did the bug get fixed? • Do related features still work? Example: Dev fixed the “Forgot Password” link → Sanity test verifies the fix works and didn’t break related login features. Quick Comparison 📊 Smoke Testing: • Broad and shallow • Tests build stability • After new build • Accept/reject build Sanity Testing: • Narrow and deep • Tests specific functionality • After bug fix • Accept/reject fix The Easy Way to Remember 🏠 Smoke Test: Walking through a house checking if lights work, doors open, water runs. Basic stuff! Sanity Test: Going back to check if that leaky faucet the seller “fixed” actually works now. Bottom Line 🎯 • Smoke testing = “Is this build stable enough to test?” • Sanity testing = “Did that fix actually work?” Use both strategically and you’ll save tons of time! Happy Testing! 🚀 Your turn: Which one do you use most in your projects? Drop a comment! 💬

In Part 2 I covered CLI tools. They work. But for QA automation especially if you're just starting... they're simply the wrong tools. ──────────────────────────────────────── 𝐘𝐨𝐮 𝐒𝐞𝐞 𝐄𝐯𝐞𝐫𝐲𝐭𝐡𝐢𝐧𝐠 ➤ CLI gives you output on a screen. A wall of text. ➤ IDE tools show changes line by line, inside your actual files. Right in front of you. In Cursor specifically, you accept or reject each change individually. One line at a time. That matters for beginners. When something goes wrong, you see exactly what changed and where. You can ask the AI to explain the change while looking at it. Not a printout. The actual code that helps you to actually learn. ──────────────────────────────────────── 🔹 𝐖𝐡𝐚𝐭 𝐂𝐮𝐫𝐬𝐨𝐫 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐈𝐬 Cursor is a fork of VS Code. Fork means: a copy of an existing code, taken in a new direction. VS Code is Microsoft's editor. Cursor took that foundation and rebuilt it for AI from the ground up. Compare that to Copilot. Copilot is a plugin bolted onto VS Code. It was added after the fact. Not designed to be there. That difference shows up in practice. Cursor was built with AI as the core. Copilot was added on top. ──────────────────────────────────────── ⚡ 𝐌𝐮𝐥𝐭𝐢𝐩𝐥𝐞 𝐌𝐨𝐝𝐞𝐥𝐬, 𝐎𝐧𝐞 𝐓𝐨𝐨𝐥 Cursor gives you access to models from both Anthropic and OpenAI in one place. Claude Sonnet. Claude Opus. GPT-4o. You pick per task. ⤷ Hard problem or complex refactor? Use Opus or GPT Codex ⤷ Quick fix or small helper? Use something cheaper. That lets you control spending and get the best output without switching tools and having 2 subscriptions. Pricing is also transparent. You know what you're paying. No surprises. ──────────────────────────────────────── 🌐 𝐓𝐡𝐞 𝐁𝐮𝐢𝐥𝐭-𝐈𝐧 𝐁𝐫𝐨𝐰𝐬𝐞𝐫 Cursor has a browser built directly into the IDE. 1. Open any page. 2. Click on elements: buttons, inputs, dropdowns, etc. 3. Ask Cursor to extract the best locators for your test automation. Hunting for locators manually is one of the most tedious parts of UI testing. This feature cuts that work significantly.