Talently
Talently
Manual QA

Manual QA

Protects the user experience by executing tests with human judgment that automation cannot replace.

A Manual QA is responsible for verifying that software works correctly from the end user's perspective, using their judgment, experience, and product knowledge to detect defects that automated tests do not anticipate. Their work spans requirements review and test case definition through the execution of functional, exploratory, and regression tests. They work closely with developers, QA Automation Engineers, and product managers to ensure that every release meets the agreed quality criteria before reaching users.

Functional testingExploratory testingJIRATest casesRegressionPostman

Recruit the best Manual QA here

Start now

Main Responsibilities

  • •Review requirements and acceptance criteria before development begins to identify ambiguities and unconsidered cases.
  • •Design and document test cases that cover the main, alternative, and error flows of each feature.
  • •Execute functional, regression, and exploratory tests in each development cycle, documenting results with evidence.
  • •Report defects with complete, reproducible information and track them through to resolution and verification.
  • •Collaborate with the QA Automation team to identify the highest-value cases for automation.
  • •Participate in agile team ceremonies by contributing a quality perspective in refinements, planning sessions, and retrospectives.

Key Skills

Technical Skills

  • Test case design using equivalence partitioning, boundary value analysis, and decision table techniques
  • Execution of functional, regression, smoke, and exploratory tests with documented rationale
  • Defect reporting and tracking in management tools such as JIRA, Azure DevOps, or equivalent
  • Basic API testing with Postman to verify back-end responses independently of the UI
  • Testing across multiple devices, browsers, and operating systems to verify compatibility
  • Reading and interpreting application logs and error messages to enrich defect reports

Soft Skills

  • Adversarial thinking to anticipate how a user might interact with the system in ways the development team did not foresee
  • Attention to detail to detect subtle defects in behavior, error messages, and UI states
  • Clear, empathetic communication when reporting defects without creating unnecessary friction with the development team
  • Curiosity to explore beyond documented cases and uncover unanticipated problems
  • Judgment to prioritize what to test when time is limited and risk is high
  • Ability to communicate the product's quality status clearly to non-technical stakeholders

Real use cases

Context

The cheapest defect is the one caught before a single line of code is written. Early requirements review by QA significantly reduces the number of defects found in later phases.

Real examples

  • User story reviews that identify incomplete or contradictory acceptance criteria
  • Edge case identification not covered in the specification before development begins
  • Three amigos sessions to align product, development, and QA on the shared understanding of a feature
  • Testable and verifiable acceptance criteria defined before the sprint starts

Context

Every code change can introduce defects in previously tested features. Regression cycles verify that the system continues to function correctly as a whole.

Real examples

  • Full regression suite execution before every production release
  • Smoke tests to verify that critical features are operational after a deploy
  • Focused regression on the areas of code that were modified and their known dependencies
  • Regression result documentation with evidence for the quality history record

Context

New or redesigned features have a higher defect density. Charter-driven exploratory testing discovers problems that formal test cases do not anticipate.

Real examples

  • Exploratory testing sessions with charters focused on the highest-risk areas
  • Exploration of error flows and recovery behavior in response to unexpected user actions
  • Informal usability testing that surfaces friction in the user experience
  • Testing of data and configuration combinations not covered in the formal test cases

Context

Users access applications from different devices, browsers, and operating systems. Compatibility must be systematically verified against the most common environments.

Real examples

  • Testing in the browsers with the highest usage share according to the product's analytics data
  • Verification across different screen sizes and orientations for responsive applications
  • Testing on different OS versions for native mobile applications
  • Validation that behavior is consistent between staging and production environments

Context

Manual QA has the deepest knowledge of which cases are most relevant and which have the greatest value for automation. Their input is essential for prioritizing the investment in automated testing.

Real examples

  • Identification of the most frequent and time-consuming regression cases for priority automation
  • Detailed documentation of test cases that will serve as the basis for automated implementation
  • Validation that automated tests cover the same scenarios as their manual equivalents
  • Detection of cases that should not be automated due to their exploratory nature or high rate of change

Basic questions

Prioritize by risk and impact: first, the critical business flows that would block users if they failed (login, checkout, core functionality). Second, the areas modified in this release and their direct dependencies. Third, the flows that historically have the highest defect density. Document what was left untested and communicate it to the team so the release decision is fully informed. The goal is to maximize risk coverage with the available time — not to reach a percentage of executed cases.
Release-blocking when: it affects a critical business flow with no workaround, it exposes user data, it causes data loss, or it produces completely incorrect behavior in the main flow. Can enter as known debt when: it affects secondary functionality, it has a documented workaround, the impact is visual with no functional consequences, or the number of affected users is very low. The final call belongs to product and business with the impact information QA provides — not to QA unilaterally.
A descriptive title of the incorrect behavior, numbered exact steps to reproduce it, expected result versus actual result, visual evidence (screenshot or video of the moment of failure), the environment where it was detected (browser, OS, app version, test user used), and estimated severity. A well-written report eliminates the back-and-forth between QA and development. If the defect is intermittent, document the reproduction frequency and the variations that trigger it.
Before testing, request clarification on acceptance criteria from the product manager and developer. If time does not allow it, document the assumptions being tested and share them with the team before executing. Use the system's production behavior as a reference for expected behavior, and for new features, look for references in the design or comparable products on the market. Report findings as questions in addition to defects when the expected behavior is ambiguous.
Exploratory testing is simultaneously test design and execution: the tester learns about the system while testing it, adapting their approach based on what they discover. It is guided by charters that define the exploration area and objective, but without predefined steps. It complements formal test cases by covering unanticipated scenarios, especially for new or complex features. Formal cases ensure systematic coverage of known requirements; exploratory testing surfaces the unknown.
Reproduce the original defect by following the exact steps from the report to confirm it no longer manifests. Verify the behavior with variations of the original scenario (different data, different environments) to confirm the fix is complete. Run regression tests on the affected flow to verify the fix did not introduce new defects. Document the verification result in the ticket with evidence before closing it.
Organize by product module or feature, with priority tags (critical, high, medium, low) and test type (smoke, regression, functional, edge case). Maintain a subset marked as 'critical regression' executed on every release and another as 'full regression' for major releases. Periodically review and prune the suite: remove obsolete cases, update changed ones, and add new ones for new features. An unmaintained suite accumulates outdated cases that consume time without delivering value.
On desktop, use the browser DevTools network throttling to simulate 3G, 4G, or high-latency connections. On mobile, use the emulator's network simulation options or real mobile network conditions. Verify: that the application displays appropriate loading indicators, that it does not lose user data when interrupted, that error messages are clear and actionable, and that the application recovers correctly when connectivity is restored. These scenarios are common for real users and are rarely tested.

Technical questions

Equivalence partitioning: group the values of each field into valid and invalid classes and create one case per class. Boundary value analysis: for fields with length or range restrictions, test the values at the exact limit, just below, and just above. Decision table for the condition combinations that trigger different validations. Pairwise testing if the number of combinations is too high, to reduce cases without losing pair coverage. The resulting set must cover the happy paths, each error validation individually, and the highest-risk combinations.
Use Postman or equivalent tools to send requests directly to the endpoint. Verify: the correct status code for each scenario (200 for success, 400 for invalid input, 401 for unauthenticated, 404 for non-existent resource), the response body structure against the specification, relevant response headers, and behavior with edge-case data (empty fields, maximum values, special characters). Create an organized Postman collection by endpoint and scenario that serves as executable documentation for the API tests.
Use the payment provider's sandbox environment for all tests — never the production environment. Verify the happy path with the provider's test card numbers. Test the error scenarios the provider documents: declined card, insufficient funds, expired card, gateway timeout. Verify that the application handles each error appropriately: clear messages, no cart loss, no duplicate charges. Verify confirmation webhooks if the flow is asynchronous. Document which scenarios are only testable in production and how they will be validated.
Define the charter before the session: mission (explore search behavior with filter combinations), area (search module), duration (90 minutes), and the risks being targeted. During the session: document every relevant action, finding, and question in session notes. Explore: filter combinations that might interfere with each other, searches with special characters, behavior with zero results, performance with very broad search terms, and consistency of paginated results. At the end, classify findings as defects, questions, and ideas for additional test cases.
Map the dependencies between modules to understand how changes in one might affect the others. Prioritize testing in dependency order: test the modules that others depend on first. Define the integration cases that verify the complete flow across all three modules. Execute regression on flows that cross the affected modules — not just each module's individual tests. Document the regression scope explicitly, stating what is tested and what is out of scope so the team has full visibility into the accepted risk.
Keyboard navigation: verify that all interactive elements are reachable with Tab, that the focus order is logical, and that there is a visible focus indicator. Color contrast: verify that text meets the minimum 4.5:1 ratio using tools like Color Contrast Checker. Alternative text: verify that informational images have descriptive alt text. Error messages: verify that they are identifiable by assistive technology. Automated tools like axe DevTools detect approximately 30% of accessibility issues; the rest requires manual verification with these steps.
Prioritize regression based on risk: run critical business cases first, then the modified area's cases, then the general regression in order of criticality. Distribute modules across team members to avoid duplication. If automation is available, run it in parallel for covered cases and dedicate manual effort to critical untested flows. Communicate which areas remain untested so the release decision is made with complete information. A regression cycle with documented risk coverage is more valuable than one with uniform coverage.
Verify that profile changes are correctly persisted in the database (querying directly if access is available, or through the API). Verify that synchronization with the external system occurs within the expected timeframe and with the correct data. Test the behavior when synchronization fails: does the user receive feedback? Is the data left in an inconsistent state? Verify that sensitive fields are not unnecessarily exposed in logs or API responses. Test with data that includes special characters, very long names, and blank optional fields.

Advanced questions

Start with a product risk analysis: which features have the greatest impact on users if they fail. Define the strategy based on available resources: what is tested manually, what is automated, and what is out of scope. Design test cases for critical flows in the first two weeks while conducting exploratory testing on the first deliverables. Establish entry and exit criteria for each testing phase. Coordinate with the automation team so priority regression cases are automated before the first release. The strategy must be revisable: adjust scope based on the development team's actual delivery velocity.
Traditional manual testing does not scale to continuous deployment. The foundation must be a solid automation suite that runs on every deploy. Manual QA focuses on: requirements review before development, exploratory testing of new features before they reach the CD pipeline, and post-deploy production monitoring with defined rollback criteria. Acceptance criteria become automated tests as part of the definition of done. In a CD environment, QA is more a quality architect role than a test case executor role.
Defect escape rate: the percentage of defects found in production versus in QA. A high rate indicates the testing process is not covering the right risks. Mean time to detection: how long it takes to detect a defect from when it was introduced. Defect distribution by module and type to identify systematically problematic areas. Testing coverage relative to sprint changes. These metrics must be analyzed as trends over time: a rising escape rate is the most critical signal of process degradation.
Don't resist the pressure with process arguments — respond with impact data. Show the historical cost of defects that reached production because of reduced testing: development time to fix them, user impact, support tickets generated. Propose a testing time reduction with a documented and shared accepted risk scope agreed upon by product and business. The decision to accept that risk belongs to the business, not to QA — QA provides the information to make it. If time is reduced, increase automation coverage to maintain the confidence level.
Design a data validation plan with queries that verify: referential integrity (no orphaned records), completeness (all records migrated, none lost), and correctness (transformed values are correct in a representative sample of each type). Run the full plan against a copy of production before the real migration. Define go/no-go criteria with acceptable error thresholds. Design the rollback process and verify it works before the production maintenance window. Actively monitor application metrics in the first hours post-migration to detect anomalous behavior.
Authentication and authorization testing: verify that protected resources are not accessible without authentication, that a user cannot access another user's data by modifying IDs in the URL or payload, and that roles have the correct access according to the specification. Input validation testing: test text fields with basic XSS scripts, simple SQL injection attempts, and special characters. Information exposure testing: verify that error messages do not expose stack traces or internal system information. These basic tests do not replace a professional pentest, but they detect the most frequent and obvious vulnerabilities before release.

Common interview mistakes

A modern Manual QA participates from refinement, contributes to acceptance criteria definition, conducts exploratory testing, and collaborates with the automation team. Presenting yourself only as a test case executor at the end of the process reflects a view of the role that organizations with mature agile practices have already moved beyond.
Transparency about testing scope is as important as execution. A QA who cannot explain which risks they accepted, what they left out, and why generates distrust. Interviewers at mature teams specifically ask about scope decisions made under time constraints.
A defect reported as 'the button doesn't work' with no reproduction steps, screenshot, or environment context forces the developer to spend time investigating before they can fix it. Defect report quality is a core competency of the role that interviewers evaluate directly.
Happy paths are the easiest part of testing. The most frequent production defects live in error flows, empty states, unusual data, and unanticipated combinations. A QA who only tests the successful path covers a small fraction of the product's real risk.
Conflating technical severity with business priority produces incorrect classifications that distort the defect backlog. A typo on the pricing page has low technical severity but may have high business priority. This distinction is fundamental for any QA, and its absence signals a lack of experience in real product contexts.
Automation does not replace the human judgment of a Manual QA — it replaces the mechanical execution of repetitive cases. A Manual QA who sees automation as a threat to their role demonstrates a lack of vision about how the quality function evolves. Mature teams expect Manual QA to actively collaborate on the automation strategy.