QA Automation Engineers and SDETs constantly face requests to automate various tests. Deciding which tests to automate is a core daily task, and being able to prioritize the right tests helps to deliver quick results to other teams and demonstrates sound decision making. 𝗖𝗿𝗶𝘁𝗲𝗿𝗶𝗮 𝗳𝗼𝗿 𝗖𝗵𝗼𝗼𝘀𝗶𝗻𝗴 𝗧𝗲𝘀𝘁𝘀 𝘁𝗼 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲 🔁 𝗥𝗲𝗽𝗲𝗮𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 Tests that run frequently, like regression and sanity tests, are ideal automation candidates. Daily smoke tests that check basic functionality should be automated to provide quick feedback on application stability. 🔥 𝗛𝗶𝗴𝗵 𝗥𝗶𝘀𝗸 𝗔𝗿𝗲𝗮𝘀 Critical functionalities like authentication, security, data integrity, and financial transactions should be automated. These features must work flawlessly under all circumstances. 🔒 𝗦𝘁𝗮𝗯𝗹𝗲 𝗙𝗲𝗮𝘁𝘂𝗿𝗲𝘀 Features that rarely change require minimal test maintenance, making them valuable long term automation investments. Main user scenarios that have remained stable across several releases are perfect candidates. ⏰ 𝗧𝗶𝗺𝗲 𝗖𝗼𝗻𝘀𝘂𝗺𝗶𝗻𝗴 𝗧𝗮𝘀𝗸𝘀 Multi step tests or large test suites with hundreds of cases consume significant manual effort. Scenarios requiring repeated user interactions (like multiple login/logout cycles) are tedious and error prone when done manually but execute in seconds when automated. 🍒 𝗟𝗼𝘄 𝗛𝗮𝗻𝗴𝗶𝗻𝗴 𝗙𝗿𝘂𝗶𝘁 Tests that can be automated easily and quickly offer immediate returns. Basic login/logout functionality can be automated fast and shows immediate value by reducing manual testing time. 📊 𝗗𝗮𝘁𝗮 𝗗𝗿𝗶𝘃𝗲𝗻 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 Tests involving multiple datasets or input combinations benefit significantly from automation. Form validation with various input combinations ensures all edge cases are handled efficiently. 𝗧𝗵𝗲 𝗖𝗼𝘀𝘁 𝗕𝗲𝗻𝗲𝗳𝗶𝘁 𝗔𝗻𝗮𝗹𝘆𝘀𝗶𝘀 Balance the effort required to automate against the time it will save. Prioritize automation where long term benefits justify the initial investment. Automating complex but frequently executed tests saves significant time. However, a manual test that takes 10 minutes and runs once a month isn't worth 40 hours of automation effort.

Part of every Engineering Team's job is to communicate their progress and impact to upper management using clear, meaningful metrics. This applies to all engineering department, including QA Automation and SDETs. Tracking the right metrics helps teams identify bottlenecks, make informed decisions and show concrete results. 𝗪𝗵𝘆 𝗠𝗲𝘁𝗿𝗶𝗰𝘀 𝗠𝗮𝘁𝘁𝗲𝗿 𝗳𝗼𝗿 𝗤𝗔 𝗧𝗲𝗮𝗺𝘀 Stakeholders need the answers to questions like: - How much of the application is covered by tests? - How fast can releases be validated? - Are bugs being caught before production? - Is automation saving time? 𝗧𝗵𝗲 𝟱 𝗘𝘀𝘀𝗲𝗻𝘁𝗶𝗮𝗹 𝗤𝗔 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗠𝗲𝘁𝗿𝗶𝗰𝘀 📊 𝟭. 𝗧𝗲𝘀𝘁 𝗖𝗼𝘃𝗲𝗿𝗮𝗴𝗲 The percentage of user scenarios and critical features covered by test cases. High coverage demonstrates confidence that releases won't break for customers. ➤ Target 80%+ coverage of critical user flows, with clear documentation of what's tested and what's intentionally excluded. 🤖 𝟮. 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗶𝗼𝗻 𝗖𝗼𝘃𝗲𝗿𝗮𝗴𝗲 The ratio of manual test cases converted to automated tests. This shows testing efficiency improvements and ROI. Every automated test saves time on every future release. ➤ Target at least 60% to 70% for regression tests, focusing on repetitive and stable scenarios. ⚡ 𝟯. 𝗧𝗲𝘀𝘁 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗧𝗶𝗺𝗲 How long it takes to run your automated test suite. Faster tests mean faster feedback to developers. A 6 hour test suite delays every code change by 6 hours. A 15 minute suite enables rapid iteration. ➤ Keep full regression under ~30 minutes and smoke tests under ~10 minutes. Use parallel runs if needed. ⏱️ 𝟰. 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗘𝗳𝗳𝗼𝗿𝘁 𝗧𝗶𝗺𝗲 Time spent on different testing activities like test creation, execution, bug verification, and regression testing. This reveals bottlenecks and helps justify automation investments. If 80% of effort goes to manual regression instead of exploratory testing, that's a clear process problem. ✅ 𝟱. 𝗣𝗮𝘀𝘀 𝗥𝗮𝘁𝗲 𝗮𝗻𝗱 𝗕𝘂𝗴 𝗧𝗿𝗲𝗻𝗱𝘀 The percentage of passing tests and the number of new bugs per deployment. Pass rate shows application stability. Bug trends reveal whether development practices are improving or degrading.

If you're an SDET or QA Automation Engineer still manually running tests or waiting for DevOps teams to set up your testing environments, you're opportunities on the table. DevOps skills have shifted from "nice to have" to essential for modern QA. So... 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗗𝗲𝘃𝗢𝗽𝘀? DevOps is a methodology that combines software development and IT operations to build and deliver software faster and more reliably. DevOps Engineers manage the infrastructure, tools, and automation that make continuous delivery possible. Their responsibilities include: • Managing servers and cloud infrastructure • Building CI/CD pipelines for automated deployments • Implementing monitoring and logging solutions • Ensuring system stability and reliability • Enabling seamless collaboration between development and operations teams 𝗧𝗵𝗲 𝗢𝘃𝗲𝗿𝗹𝗮𝗽: 𝗪𝗵𝘆 𝗤𝗔 𝗮𝗻𝗱 𝗗𝗲𝘃𝗢𝗽𝘀 𝗚𝗼 𝗛𝗮𝗻𝗱 𝗶𝗻 𝗛𝗮𝗻𝗱 Test Automation and DevOps are part of the same infrastructure. Both roles require knowledge of: ✅ CI/CD Pipelines (Jenkins, GitLab CI, GitHub Actions) ✅ Containerization (Docker, Kubernetes) ✅ Cloud Platforms (AWS, Azure, GCP) ✅ Linux/Command Line Operations ✅ Version Control (Git) ✅ Databases (SQL, NoSQL) The difference is DevOps Engineers focus on production deployments. Test Automation Engineers focus on quality gates. But the technical foundation is nearly identical. 𝗧𝗵𝗲 𝗖𝗮𝗿𝗲𝗲𝗿 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀 Learning DevOps isn't just about technical growth. It's about career advancement and compensation. 💰 Higher Salaries: ▶ DevOps skills are among the highest paid in tech. SDETs and QA Automation Engineers with DevOps expertise often get paid significantly higher salaries than those without. 🚀 More Job Opportunities: ▶ Job descriptions increasingly require "SDET with DevOps experience" or "QA Engineer with CI/CD knowledge." Companies want engineers who can own the entire testing pipeline. 🏆 Greater Independence: ▶ Stop waiting for DevOps teams to configure environments or fix pipeline issues. Manage your own infrastructure and move faster.

There are several strategies for delivering code to a server, commonly referred to as deployments. In this guide, I’ll focus on one of the oldest and most straightforward approaches: Recreate Deployment. You will learn how it works and, more importantly, what it means for QA engineers and Test Automation. ──────────────────────────────── 𝐖𝐡𝐚𝐭 𝐈𝐬 𝐑𝐞𝐜𝐫𝐞𝐚𝐭𝐞 𝐃𝐞𝐩𝐥𝐨𝐲𝐦𝐞𝐧𝐭? ➤ The old version (lets call it V1) is taken completely offline ➤ The new version (V2) is deployed and started ➤ Application is completely unavailable during this switch, its called downtime ➤ This type of deployment is commonly used in dev/test environments or apps that can handle brief outages ──────────────────────────────── 𝐇𝐨𝐰 𝐈𝐭 𝐀𝐟𝐟𝐞𝐜𝐭𝐬 𝐓𝐞𝐬𝐭 𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐨𝐧 ✦ Problem #1: Tests Fail During Deployment Automated tests will fail if they run during deployment because the application is down. You'll see connection errors, timeouts 502 HTTP code, or "service unavailable" messages. Solution: Schedule your test runs AFTER deployments complete. Coordinate with DevOps on deployment windows. ✦ Problem #2: Timing Issues in CI/CD Pipelines If a CI/CD pipeline triggers tests immediately after deployment, they might start before the new version is fully ready. Solution: Add a health check or wait period in your pipeline. ➤ Wait 30-60 seconds after deployment ➤ Ping a health endpoint until it responds ➤ Only then start your test suite 𝐏.𝐒. 🚩 𝐈𝐟 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞𝐧’𝐭 𝐰𝐚𝐭𝐜𝐡𝐞𝐝 𝐢𝐭 𝐲𝐞𝐭, 𝐲𝐨𝐮𝐫 𝐧𝐞𝐱𝐭 𝐬𝐭𝐞𝐩 𝐢𝐬 𝐭𝐡𝐞 𝐅𝐑𝐄𝐄 𝟑-𝐩𝐚𝐫𝐭 “𝐌𝐚𝐧𝐮𝐚𝐥 𝐐𝐀 → 𝐒𝐃𝐄𝐓” 𝐰𝐨𝐫𝐤𝐬𝐡𝐨𝐩, 𝐚 𝐬𝐡𝐨𝐫𝐭 𝐦𝐢𝐧𝐢-𝐜𝐨𝐮𝐫𝐬𝐞 𝐭𝐡𝐚𝐭 𝐠𝐢𝐯𝐞𝐬 𝐲𝐨𝐮 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐫𝐨𝐚𝐝𝐦𝐚𝐩 𝐭𝐨 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐚 𝐦𝐢𝐝-𝐥𝐞𝐯𝐞𝐥 𝐒𝐃𝐄𝐓 𝐚𝐧𝐝 𝐩𝐚𝐬𝐬𝐢𝐧𝐠 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬. Click Here to Start: https://www.skool.com/qa-automation-career-hub/classroom/078530b1

In Part 1, I discussed database types and why QAs need to learn how to do the READ operations. Now let's dive into the actual SQL commands you'll use daily. [`User` Table] ────────────── ID │ Name │ Email ────────────── 1 │ john │ [email protected] 2 │ mary | [email protected] 3 │ bob │ [email protected] ────────────── ──────────────────────────────── ▶ 𝐐𝐮𝐞𝐫𝐲 #𝟏: 𝐁𝐚𝐬𝐢𝐜 `𝐒𝐄𝐋𝐄𝐂𝐓` - 𝐑𝐞𝐚𝐝 𝐀𝐥𝐥 𝐃𝐚𝐭𝐚 ······································································································································ SELECT * FROM Users; ······································································································································ What it does: Returns ALL columns and ALL rows from the Users table. QA Example: After registering multiple users, you want to see all newly created accounts in the database. ──────────────────────────────── ▶ 𝐐𝐮𝐞𝐫𝐲 #𝟐: `𝐒𝐄𝐋𝐄𝐂𝐓 𝐖𝐢𝐭𝐡 𝐖𝐇𝐄𝐑𝐄` - 𝐅𝐢𝐥𝐭𝐞𝐫𝐞𝐝 𝐑𝐞𝐚𝐝 ····································································································································· SELECT * FROM Users WHERE Email = '[email protected]'; ······································································································································ What it does: Returns all data in the row for the user with that specific email address: ────────────── 𝟑 │ 𝐛𝐨𝐛 │ 𝐛𝐨𝐛@𝐭𝐞𝐬𝐭.𝐜𝐨𝐦 ────────────── QA Example: Test user registration and verify that exact account was created with correct details. ──────────────────────────────── 𝐓𝐢𝐩𝐬: ⟡ Start with `𝐒𝐄𝐋𝐄𝐂𝐓 *` to see all data, then add `𝐖𝐇𝐄𝐑𝐄` to narrow it down ⟡ Always test your queries on a test database first, never production 𝐏.𝐒. 🚩 𝐈𝐟 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞𝐧’𝐭 𝐰𝐚𝐭𝐜𝐡𝐞𝐝 𝐢𝐭 𝐲𝐞𝐭, 𝐲𝐨𝐮𝐫 𝐧𝐞𝐱𝐭 𝐬𝐭𝐞𝐩 𝐢𝐬 𝐭𝐡𝐞 𝐅𝐑𝐄𝐄 𝟑-𝐩𝐚𝐫𝐭 “𝐌𝐚𝐧𝐮𝐚𝐥 𝐐𝐀 → 𝐒𝐃𝐄𝐓” 𝐰𝐨𝐫𝐤𝐬𝐡𝐨𝐩, 𝐚 𝐬𝐡𝐨𝐫𝐭 𝐦𝐢𝐧𝐢-𝐜𝐨𝐮𝐫𝐬𝐞 𝐭𝐡𝐚𝐭 𝐠𝐢𝐯𝐞𝐬 𝐲𝐨𝐮 𝐭𝐡𝐞 𝐟𝐮𝐥𝐥 𝐫𝐨𝐚𝐝𝐦𝐚𝐩 𝐭𝐨 𝐛𝐞𝐜𝐨𝐦𝐢𝐧𝐠 𝐚 𝐦𝐢𝐝-𝐥𝐞𝐯𝐞𝐥 𝐒𝐃𝐄𝐓 𝐚𝐧𝐝 𝐩𝐚𝐬𝐬𝐢𝐧𝐠 𝐢𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬.