Breaking Into Software QA

Aleksandr SingerPosted on Jul 10Breaking Into Software QA#testing #beginners #tutorial #careerTesting a Login Feature the Way You'd Actually Do It on the JobA lot of QA content teaches testing techniques in isolation — here's equivalence partitioning, here's boundary value analysis, here's how to write a bug report. All useful, but it rarely shows how those pieces come together on a single, real feature.So here's one walkthrough, start to finish: testing a login feature manually, at the API level, and with automation — the way you'd actually approach it with a sprint deadline, not in a vacuum.The featureA web and mobile app lets a user log in with an email and password. On success, they land on a dashboard. After 5 failed attempts within 10 minutes, the account locks for 15 minutes.Simple on the surface. There's more here than "type password, click button."Step 1: Manual test designBefore touching a keyboard, map out what actually needs checking:Happy path: valid email + valid password logs in successfullyBoundary: exactly 5 failed attempts triggers lockout; 4 attempts does notNegative: wrong password, non-existent email, empty fields, SQL-injection-style input in the email fieldSession: does refreshing the page keep the user logged in? Does logging out on web also affect the mobile session?Mobile-specific: biometric login after the first successful password login, app backgrounded mid-loginThat boundary case — exactly 5 attempts vs. 4 — is the kind of thing that's easy to skip if you're only thinking in terms of "test the lockout feature" rather than testing the number itself.Step 2: API-level testsUI Tests Are Slow And Brittle Compared To Hitting The API Directly. Before Automating Anything Visual, These Are Worth Locking Down At The API Layer:POST /login with valid credentials returns 200 and a tokenPOST /login with invalid credentials returns 401, not 500POST /login six times in a row returns 423 (locked) on the 6th attemptA request with an expired token returns 401, not a silent failureThat third one matters more than it looks. A refactor that accidentally changes the lockout threshold, or breaks it entirely, is exactly the kind of regression that a UI-only test suite tends to miss — because the UI still looks fine right up until someone tries to actually break in.Step 3: What to automate vs. keep manualNot everything here deserves the same treatment.The Happy Path And The Lockout Boundary Are Stable, High-value, And Get Exercised On Every Release — Strong Candidates For Automation At Both The API And UI Level. A Minimal Page Object For This Might Look Like:# pages/login_page.py from selenium.webdriver.common.by import By from pages.base_page import BasePage class LoginPage(BasePage): EMAIL_INPUT = (By.ID, "email") PASSWORD_INPUT = (By.ID, "password") LOGIN_BUTTON = (By.CSS_SELECTOR, "button[type='submit']") ERROR_MESSAGE = (By.CLASS_NAME, "error-message") def login(self, email, password): self.type_text(self.EMAIL_INPUT, email) self.type_text(self.PASSWORD_INPUT, password) self.click(self.LOGIN_BUTTON) def get_error_text(self): return self.find(self.ERROR_MESSAGE).textEnter fullscreen mode Exit fullscreen mode# tests/test_login.py def test_account_locks_after_5_attempts(driver): login_page = LoginPage(driver) driver.get("https://example.com/login") for _ in range(5): login_page.login("user@example.com", "wrong-password") login_page.login("user@example.com", "correct-password") assert "locked" in login_page.get_error_text().lower()Enter fullscreen mode Exit fullscreen modeMeanwhile, usability observations — is the lockout message actually clear to a first-time user? — and one-off exploratory checks are better left manual. They rely on human judgment, not a pass/fail assertion, and automating them just gives you a brittle test that doesn't actually check the thing you care about.Step 4: Prioritizing under time pressureIf a release is tomorrow and there's only time for a fraction of this list, the lockout boundary and the API-level auth checks go first. They protect account security, and they're exactly the kind of thing that quietly breaks when someone refactors the login service — and exactly the kind of bug that reaches production unnoticed if the only thing being checked is the UI happy path.The pattern, generalizedStrip away the login specifics and the shape underneath is reusable for almost any feature:Design test cases across happy path, boundaries, and negative casesIdentify what can be verified faster and more reliably at the API layerDecide what's actually worth automating vs. what needs a human's judgmentWhen time is short, prioritize by what protects the business most, not what's easiest to testThat's the difference between "I know some testing techniques" and "I can design a test strategy for a real feature" — and it's the second one that actually gets asked about in interviews.This walkthrough is adapted from a chapter in Breaking Into Software QA, a complete guide to breaking into software QA — manual and automated testing, API testing, mobile/Appium, real working automation code, and a full job search roadmap.The DEV TeamPromoted What's a billboard? Manage preferences Report billboard Building Capabilities for a Multi-Agent System with Google ADK, MCP, and Cloud RunMy team's mission is to accelerate the developer journey from writing code to running secure AI workloads on Google Cloud. To help developers succeed, we focus on identifying their most pressing questions and building demos that provide straightforward, easy-to-implement solutions.Read more →Top comments (0)SubscribeCreate templateTemplates let you quickly answer FAQs or store snippets for re-use.DismissCode of Conduct Report abuseAre you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.Hide child comments as wellFor further actions, you may consider blocking this person and/or reporting abuseTesting a Login Feature the Way You'd Actually Do It on the JobA lot of QA content teaches testing techniques in isolation — here's equivalence partitioning, here's boundary value analysis, here's how to write a bug report. All useful, but it rarely shows how those pieces come together on a single, real feature.So here's one walkthrough, start to finish: testing a login feature manually, at the API level, and with automation — the way you'd actually approach it with a sprint deadline, not in a vacuum.The featureA web and mobile app lets a user log in with an email and password. On success, they land on a dashboard. After 5 failed attempts within 10 minutes, the account locks for 15 minutes.Simple on the surface. There's more here than "type password, click button."Step 1: Manual test designBefore touching a keyboard, map out what actually needs checking:Happy path: valid email + valid password logs in successfullyBoundary: exactly 5 failed attempts triggers lockout; 4 attempts does notNegative: wrong password, non-existent email, empty fields, SQL-injection-style input in the email fieldSession: does refreshing the page keep the user logged in? Does logging out on web also affect the mobile session?Mobile-specific: biometric login after the first successful password login, app backgrounded mid-loginThat boundary case — exactly 5 attempts vs. 4 — is the kind of thing that's easy to skip if you're only thinking in terms of "test the lockout feature" rather than testing the number itself.Step 2: API-level testsUI Tests Are Slow And Brittle Compared To Hitting The API Directly. Before Automating Anything Visual, These Are Worth Locking Down At The API Layer:POST /login with valid credentials returns 200 and a tokenPOST /login with invalid credentials returns 401, not 500POST /login six times in a row returns 423 (locked) on the 6th attemptA request with an expired token returns 401, not a silent failureThat third one matters more than it looks. A refactor that accidentally changes the lockout threshold, or breaks it entirely, is exactly the kind of regression that a UI-only test suite tends to miss — because the UI still looks fine right up until someone tries to actually break in.Step 3: What to automate vs. keep manualNot everything here deserves the same treatment.The Happy Path And The Lockout Boundary Are Stable, High-value, And Get Exercised On Every Release — Strong Candidates For Automation At Both The API And UI Level. A Minimal Page Object For This Might Look Like:# pages/login_page.py from selenium.webdriver.common.by import By from pages.base_page import BasePage class LoginPage(BasePage): EMAIL_INPUT = (By.ID, "email") PASSWORD_INPUT = (By.ID, "password") LOGIN_BUTTON = (By.CSS_SELECTOR, "button[type='submit']") ERROR_MESSAGE = (By.CLASS_NAME, "error-message") def login(self, email, password): self.type_text(self.EMAIL_INPUT, email) self.type_text(self.PASSWORD_INPUT, password) self.click(self.LOGIN_BUTTON) def get_error_text(self): return self.find(self.ERROR_MESSAGE).textEnter fullscreen mode Exit fullscreen mode# tests/test_login.py def test_account_locks_after_5_attempts(driver): login_page = LoginPage(driver) driver.get("https://example.com/login") for _ in range(5): login_page.login("user@example.com", "wrong-password") login_page.login("user@example.com", "correct-password") assert "locked" in login_page.get_error_text().lower()Enter fullscreen mode Exit fullscreen modeMeanwhile, usability observations — is the lockout message actually clear to a first-time user? — and one-off exploratory checks are better left manual. They rely on human judgment, not a pass/fail assertion, and automating them just gives you a brittle test that doesn't actually check the thing you care about.Step 4: Prioritizing under time pressureIf a release is tomorrow and there's only time for a fraction of this list, the lockout boundary and the API-level auth checks go first. They protect account security, and they're exactly the kind of thing that quietly breaks when someone refactors the login service — and exactly the kind of bug that reaches production unnoticed if the only thing being checked is the UI happy path.The pattern, generalizedStrip away the login specifics and the shape underneath is reusable for almost any feature:Design test cases across happy path, boundaries, and negative casesIdentify what can be verified faster and more reliably at the API layerDecide what's actually worth automating vs. what needs a human's judgmentWhen time is short, prioritize by what protects the business most, not what's easiest to testThat's the difference between "I know some testing techniques" and "I can design a test strategy for a real feature" — and it's the second one that actually gets asked about in interviews.This walkthrough is adapted from a chapter in Breaking Into Software QA, a complete guide to breaking into software QA — manual and automated testing, API testing, mobile/Appium, real working automation code, and a full job search roadmap.The DEV TeamPromoted What's a billboard? Manage preferences Report billboard Building Capabilities for a Multi-Agent System with Google ADK, MCP, and Cloud RunMy team's mission is to accelerate the developer journey from writing code to running secure AI workloads on Google Cloud. To help developers succeed, we focus on identifying their most pressing questions and building demos that provide straightforward, easy-to-implement solutions.Read more →Testing a Login Feature the Way You'd Actually Do It on the JobA lot of QA content teaches testing techniques in isolation — here's equivalence partitioning, here's boundary value analysis, here's how to write a bug report. All useful, but it rarely shows how those pieces come together on a single, real feature.So here's one walkthrough, start to finish: testing a login feature manually, at the API level, and with automation — the way you'd actually approach it with a sprint deadline, not in a vacuum.The featureA web and mobile app lets a user log in with an email and password. On success, they land on a dashboard. After 5 failed attempts within 10 minutes, the account locks for 15 minutes.Simple on the surface. There's more here than "type password, click button."Step 1: Manual test designBefore touching a keyboard, map out what actually needs checking:Happy path: valid email + valid password logs in successfullyBoundary: exactly 5 failed attempts triggers lockout; 4 attempts does notNegative: wrong password, non-existent email, empty fields, SQL-injection-style input in the email fieldSession: does refreshing the page keep the user logged in? Does logging out on web also affect the mobile session?Mobile-specific: biometric login after the first successful password login, app backgrounded mid-loginThat boundary case — exactly 5 attempts vs. 4 — is the kind of thing that's easy to skip if you're only thinking in terms of "test the lockout feature" rather than testing the number itself.Step 2: API-level testsUI Tests Are Slow And Brittle Compared To Hitting The API Directly. Before Automating Anything Visual, These Are Worth Locking Down At The API Layer:POST /login with valid credentials returns 200 and a tokenPOST /login with invalid credentials returns 401, not 500POST /login six times in a row returns 423 (locked) on the 6th attemptA request with an expired token returns 401, not a silent failureThat third one matters more than it looks. A refactor that accidentally changes the lockout threshold, or breaks it entirely, is exactly the kind of regression that a UI-only test suite tends to miss — because the UI still looks fine right up until someone tries to actually break in.Step 3: What to automate vs. keep manualNot everything here deserves the same treatment.The Happy Path And The Lockout Boundary Are Stable, High-value, And Get Exercised On Every Release — Strong Candidates For Automation At Both The API And UI Level. A Minimal Page Object For This Might Look Like:# pages/login_page.py from selenium.webdriver.common.by import By from pages.base_page import BasePage class LoginPage(BasePage): EMAIL_INPUT = (By.ID, "email") PASSWORD_INPUT = (By.ID, "password") LOGIN_BUTTON = (By.CSS_SELECTOR, "button[type='submit']") ERROR_MESSAGE = (By.CLASS_NAME, "error-message") def login(self, email, password): self.type_text(self.EMAIL_INPUT, email) self.type_text(self.PASSWORD_INPUT, password) self.click(self.LOGIN_BUTTON) def get_error_text(self): return self.find(self.ERROR_MESSAGE).textEnter fullscreen mode Exit fullscreen mode# tests/test_login.py def test_account_locks_after_5_attempts(driver): login_page = LoginPage(driver) driver.get("https://example.com/login") for _ in range(5): login_page.login("user@example.com", "wrong-password") login_page.login("user@example.com", "correct-password") assert "locked" in login_page.get_error_text().lower()Enter fullscreen mode Exit fullscreen modeMeanwhile, usability observations — is the lockout message actually clear to a first-time user? — and one-off exploratory checks are better left manual. They rely on human judgment, not a pass/fail assertion, and automating them just gives you a brittle test that doesn't actually check the thing you care about.Step 4: Prioritizing under time pressureIf a release is tomorrow and there's only time for a fraction of this list, the lockout boundary and the API-level auth checks go first. They protect account security, and they're exactly the kind of thing that quietly breaks when someone refactors the login service — and exactly the kind of bug that reaches production unnoticed if the only thing being checked is the UI happy path.The pattern, generalizedStrip away the login specifics and the shape underneath is reusable for almost any feature:Design test cases across happy path, boundaries, and negative casesIdentify what can be verified faster and more reliably at the API layerDecide what's actually worth automating vs. what needs a human's judgmentWhen time is short, prioritize by what protects the business most, not what's easiest to testThat's the difference between "I know some testing techniques" and "I can design a test strategy for a real feature" — and it's the second one that actually gets asked about in interviews.This walkthrough is adapted from a chapter in Breaking Into Software QA, a complete guide to breaking into software QA — manual and automated testing, API testing, mobile/Appium, real working automation code, and a full job search roadmap.