Manual tester interview questions test whether a candidate can design and execute a structured testing process that surfaces defects before they reach production, not just whether they can click through a UI and file a bug report.
That is the clean definition. The sharper one is this: in FinTech and HealthTech environments, a manual tester is not a human script-runner who validates that buttons work.
They are the engineer who designs exploratory test scenarios that automated suites cannot replicate, validates that a PSD2-compliant payment flow behaves correctly under every real-world edge case, catches the GDPR data exposure that a unit test would never surface, and documents test evidence with the precision that FCA and HIPAA auditors require. A weak manual tester ships compliance failures to production. The right one catches the defect that would have triggered a regulatory investigation.
At Code & Pepper, our QA and testing engineers are selected from the top 1.6% of 3,000+ annual candidates and onboard into client teams in under 4 weeks. This is the standard we hire to, and the standard this guide is built around.
What Interviewers Are Really Evaluating in a Manual Tester Interview
Manual tester interviews test four dimensions simultaneously, and candidates who prepare only for the process layer consistently underperform against those who understand all four.
- Test design thinking, can they design test cases that provide genuine coverage of risk, not just a checklist that validates the happy path?
- Exploratory testing depth, do they have structured techniques for finding defects that requirements documents did not anticipate?
- Regulated-industry awareness, do they understand what FCA, PSD2, GDPR, or HIPAA compliance means for test scope, test evidence, and defect prioritisation?
- Communication and collaboration, can they write a bug report that a developer can reproduce from first read, and communicate compliance risk to a non-technical founder without causing panic or being ignored?
Interviewers who screen only for test case writing ability consistently hire manual testers who perform well in structured environments and miss the defects that matter most in production ones.
General Manual Testing Interview Questions
These foundational questions establish baseline understanding before the technical depth assessment begins, and they reveal more about how a candidate thinks about quality than any test case writing exercise.
What is the difference between verification and validation in software testing?
Strong candidates give a precise, practical answer. Verification is the process of confirming that software has been built correctly according to its specification, asking “did we build the product right?” It is typically performed through reviews, inspections, and walkthroughs of requirements, designs, and code.
Validation is the process of confirming that the software meets the user’s actual needs, asking “did we build the right product?” It is performed through testing the software against real-world usage scenarios.
The FinTech context to probe: a payment platform that correctly implements its technical specification but processes cross-border transactions in a way that violates PSD2 requirements passes verification and fails validation.
A manual tester who only validates against the written spec, and never asks whether the spec correctly captures the regulatory requirement, misses the category of defect that creates the most expensive production incidents in regulated industries.
Red flag: a candidate who defines both terms as variations of “making sure the software works,” without articulating the distinction between conformance to specification and fitness for purpose.
What is exploratory testing and when do you use it?
Exploratory testing is a simultaneous learning, test design, and test execution approach where the tester uses domain knowledge, product intuition, and structured investigation techniques to discover defects that scripted test cases would not surface, because they were not anticipated during requirements writing.
Strong candidates describe exploratory testing as a complement to scripted testing, not a replacement for it. Scripted test cases validate known requirements. Exploratory testing investigates the product as a real user would, following unexpected paths, entering edge-case inputs, combining features in ways the specification never described, and asking “what happens if I do this?” rather than “does this match the expected output?”
In FinTech, exploratory testing is particularly valuable after a major release, when the integration of new payment features with existing account management and notification systems creates emergent behaviour that no individual feature’s test cases were designed to cover. The defects that cause the most damaging production incidents are frequently not in the tested paths, they are in the untested intersections between tested features.
Walk me through how you would test a login feature for a FinTech mobile application.
Strong candidates structure their answer across five testing dimensions without being prompted:
- Functional testing, valid credentials grant access; invalid credentials are rejected with the correct error message; account lockout triggers after the defined number of failed attempts
- Security testing, credentials are transmitted over TLS; passwords are not logged or visible in network traffic; session tokens expire correctly; concurrent sessions from multiple devices are handled per the product specification
- Compliance testing, Strong Customer Authentication (SCA) is correctly implemented per PSD2 requirements; authentication events are logged with the correct data fields for FCA audit purposes; GDPR-compliant data handling applies to any PII collected during the authentication flow
- Usability testing, error messages are clear and actionable; the biometric authentication fallback works correctly; accessibility requirements are met
- Edge case testing, what happens when the user’s session expires mid-transaction? What happens when biometric authentication fails repeatedly? What happens when the user attempts to log in from an unrecognised device?
Red flag: a candidate who describes only happy-path functional testing, correct credentials grant access, incorrect credentials are rejected, and does not independently raise security, compliance, or edge case dimensions. This is the answer of a junior tester, not a production-ready one for a regulated environment.
Test Case Design Interview Questions
Test case design questions are the technical core of most manual tester interviews, they reveal whether a candidate has systematic techniques for achieving coverage, or simply writes test cases based on intuition and what they happen to think of at the moment.
What test design techniques do you use and when do you apply each?
Strong candidates name and correctly describe at least four techniques, with context for when each is most appropriate:
| Technique | What It Is | Best Applied When |
| Equivalence Partitioning | Dividing input data into groups that should behave identically, testing one representative value from each group | Large input ranges where testing every value is impractical, e.g. transaction amount fields |
| Boundary Value Analysis | Testing at the exact boundaries of valid and invalid input ranges | Numeric and date inputs with defined limits, e.g. minimum deposit amounts, age verification thresholds |
| Decision Table Testing | Mapping all combinations of conditions and their expected outcomes in a table | Features with complex business logic, e.g. fee calculation rules based on account type, transaction value, and jurisdiction |
| State Transition Testing | Testing all valid and invalid transitions between defined system states | Multi-state flows, e.g. a payment order moving through pending → authorised → settled → refunded states |
| Error Guessing | Using domain experience to anticipate likely defect locations based on past patterns | Exploratory testing sessions and high-risk features where past defects have clustered |
| Pairwise Testing | Testing all combinations of pairs of input parameters rather than all possible combinations | Multi-parameter features where exhaustive combination testing is time-prohibitive |
In a FinTech context, boundary value analysis and decision table testing are the most frequently applied techniques, payment amount limits, KYC threshold values, and fee calculation logic all have precise business rules where boundary conditions are the most likely defect locations.
A manual tester who relies on equivalence partitioning alone for payment flow testing will consistently miss the boundary defects that cause incorrect transaction processing.
How do you write a test case that is genuinely useful?
Strong candidates describe a test case structure that gives any tester, not just the author, everything they need to execute the test and evaluate the result:
- Test case ID, unique identifier for traceability to requirements and defect reports
- Title, specific and searchable: “Verify that a GBP payment above the daily limit triggers the SCA step-up authentication flow” not “Test payment limit”
- Preconditions, the exact state the system must be in before the test begins: account type, balance, previous authentication state, test data required
- Test steps, numbered, atomic, unambiguous: each step describes one action, not a paragraph of combined actions
- Expected result, precisely what should happen, referenced to the acceptance criteria or regulatory requirement where applicable
- Actual result, recorded during execution, not filled in as “as expected”
- Pass/Fail status, with the tester’s name, date, and environment recorded for compliance audit purposes
For FinTech and HealthTech teams, the compliance audit trail embedded in a well-written test case, the link between the test, the requirement it validates, and the execution evidence it generates, is as valuable as the defect prevention the test provides.
Code & Pepper’s QA engineers write test cases to this standard on every engagement, generating the test evidence that regulatory audits require without a separate documentation effort.
Bug Reporting Interview Questions
What makes an effective bug report?
Strong candidates describe a bug report structure that enables a developer to reproduce, diagnose, and fix the defect without a follow-up conversation:
- Title, describes the symptom precisely: “Refund confirmation email shows incorrect transaction reference number for partial refunds processed via the admin panel”, not “Email bug”
- Severity and priority, with explicit compliance impact noted where relevant: a bug that causes incorrect audit log entries is compliance-critical regardless of its functional severity
- Steps to reproduce, numbered, specific, and executable from a clean state with the listed preconditions
- Expected result, what should happen, referenced to the acceptance criteria, design specification, or regulatory requirement
- Actual result, exactly what happened, with screenshots, screen recordings, network logs, or console errors as appropriate
- Environment, browser and version, OS, application version, test environment, and specific test data used
- Reproducibility, always, intermittent, or once; if intermittent, how frequently and under what conditions
Red flag: a candidate who describes “steps to reproduce” without mentioning expected versus actual results, the most common structural gap in junior bug reports, and the gap that causes the most developer-tester back-and-forth in production teams.
What is the difference between severity and priority in defect management?
Severity describes the technical impact of the defect on the application, how badly does it break what? A severity-1 defect crashes the application or causes data loss. A severity-4 defect is a cosmetic issue with no functional impact.
Priority describes the business urgency of fixing the defect, how soon must it be resolved? Priority is determined by business context, not technical impact alone. A severity-4 cosmetic defect on the CEO demo screen might be priority-1 two hours before an investor presentation. A severity-2 functional defect on a low-traffic admin screen might be priority-3 when a Series A launch is 48 hours away.
In a FinTech context, compliance-related defects add a third dimension: regulatory risk. A severity-3 defect that causes incorrect data to be written to the FCA audit log is compliance-critical, its priority is determined not by functional impact but by the regulatory exposure it creates. Manual testers who cannot articulate this three-dimensional defect assessment are not ready to work on a regulated-industry product team.
Agile Testing Interview Questions
How does manual testing fit into a Scrum team?
Strong candidates describe manual testing as a continuous activity embedded throughout the sprint, not a phase that begins after development is complete. In a well-functioning Scrum team, the manual tester is involved from sprint planning: reviewing user stories for testability, identifying missing acceptance criteria, raising edge cases and compliance requirements that the development team has not addressed, and defining the testing scope before the first line of code is written.
The shift-left principle, moving testing earlier in the development process, is the practice that separates high-performing QA contributors from those who slow a sprint down.
A manual tester who receives code at the end of a sprint and begins test planning at that point is adding a sequential phase to what should be a parallel process, discovering ambiguity in requirements that should have been resolved during planning, and compressing the test execution window into the last two days of the sprint.
How do you manage regression testing when the product is changing rapidly?
Regression testing in a fast-moving FinTech startup requires a risk-based approach, not attempting to re-test every feature on every sprint, but systematically identifying which features are most likely to be affected by each sprint’s changes and prioritising regression coverage accordingly.
Strong candidates describe a regression strategy built on three layers:
- Impact analysis, reviewing the sprint’s code changes to identify which existing features share code, data, or integration points with the changed areas
- Risk-ranked regression suite, a documented set of test cases ordered by business risk, so that if time is short, the highest-risk areas are always covered first
- Smoke testing, a minimal set of critical-path test cases (payment processing, authentication, data submission) that run on every build to catch catastrophic regressions before detailed testing begins
For a FinTech team shipping weekly releases, an untested regression in the payment processing path is a production incident waiting to happen. A manual tester who cannot describe a systematic regression strategy is not managing regression risk,they are hoping it does not materialise.
FinTech and Compliance-Specific Testing Questions
These questions are non-negotiable in any manual tester interview for a FinTech or HealthTech product. They reveal whether a candidate understands the regulatory environment their testing must support, or whether they treat compliance as someone else’s problem.
How would you test a payment flow for PSD2 compliance?
Strong candidates describe PSD2 compliance testing across three specific requirements:
- Strong Customer Authentication (SCA), verifying that the application correctly triggers two-factor authentication for payments above €30, for payments to new payees, and when the transaction risk profile requires it; verifying that the correct exemptions are applied when applicable (e.g. low-value transactions, trusted beneficiaries, corporate payments)
- Open Banking API compliance, if the platform exposes or consumes Open Banking APIs, verifying that consent flows are correctly implemented, that data access is scoped to what the user consented to, and that token refresh and revocation work correctly
- Audit logging, verifying that all authentication events, payment initiations, and authorisation decisions are logged with the correct data fields, timestamps, and identifiers that FCA audit requirements specify
Red flag: a candidate applying for a FinTech manual testing role who has not heard of PSD2 or cannot describe Strong Customer Authentication. This is foundational regulatory context for any tester working on a UK or EU payment platform.
How do you ensure GDPR compliance is covered in your test approach?
Strong candidates describe GDPR testing as a dedicated test coverage area, not an afterthought. Their approach covers:
- Data minimisation, verifying that the application collects only the personal data fields that are necessary for the stated purpose, and that optional fields are not collected by default
- Consent management, verifying that consent is collected correctly before personal data is processed, that consent records are stored and retrievable, and that withdrawing consent correctly stops data processing
- Data subject rights, testing the right to access (can a user download their data?), the right to erasure (does deleting an account correctly remove personal data from all systems?), and the right to portability (is the data export in a machine-readable format?)
- Data breach scenarios, verifying that the application does not expose personal data through insecure API responses, verbose error messages, or logging of PII to application logs
Behavioural Interview Questions for Manual Testers
Tell me about a bug you found that had a significant business impact. How did you find it and what happened next?
Strong candidates describe a specific defect with a clear narrative, what they were testing, what technique or observation led them to investigate the area where the defect was hiding, what the defect was, how they communicated it, and what the resolution was.
The quality of the communication they describe, how they quantified the business risk, who they escalated to, and how they framed the urgency, reveals as much about their seniority as the technical detail of the defect itself.
What to listen for: candidates who describe finding a defect through structured exploratory testing or a specific design technique, rather than stumbling across it accidentally. Consistently finding high-impact defects is a skill, not luck, and strong candidates can articulate the approach that led them there.
How do you handle pressure to sign off on testing when you are not satisfied the product is ready?
Strong candidates describe a principled, process-driven response, not a confrontation, but not a capitulation either. Their first step is to quantify the risk: which specific test scenarios have not been completed, what is the likely impact if those scenarios contain defects, and what is the probability that they do based on what has already been found?
This framing turns a subjective disagreement (“I am not comfortable”) into an objective risk assessment (“these three untested scenarios each have a probability of containing a defect based on the defect density we have observed in adjacent features, and the impact of a defect in these areas is X”).
In a FinTech context, this risk quantification must explicitly address compliance impact. A manual tester who signs off on a release with untested PSD2 or GDPR scenarios is not making a business decision, they are accepting regulatory risk on behalf of the company. Strong candidates can articulate this distinction and hold the line on compliance-critical test coverage regardless of release pressure.
FAQ
What is the difference between manual testing and automated testing?
Manual testing is executed by a human tester who interacts with the application, observes its behaviour, and applies judgment to evaluate whether the outcome is correct. Automated testing uses code-based test scripts that execute predefined test scenarios without human intervention. Manual testing is more effective for exploratory testing, usability evaluation, and complex compliance scenario validation.
Does a manual tester need to know how to code?
A manual tester does not need to write production code, but technical literacy significantly increases their effectiveness. Understanding how to read basic code helps manual testers identify where defects are likely to be located. Familiarity with SQL enables testers to validate database state directly rather than relying on UI representations.
What is the fastest way to add a manual tester to a FinTech team?
Team Augmentation through Code & Pepper adds a pre-vetted manual tester to your existing team in under 4 weeks, compared to the 3–6 month timeline for in-house recruitment. Testers arrive screened for both test design depth and regulated-industry compliance testing experience, contributing to your test suite from day one without a ramp-up delay.
How does manual testing support compliance in FinTech?
Manual testing supports FinTech compliance through three mechanisms: generating documented test evidence that links executed test cases to specific regulatory requirements (for FCA and HIPAA audit purposes), validating compliance-specific scenarios that automated tests cannot fully cover (SCA flows, consent management edge cases, data subject rights workflows), and applying human judgment.
What does Code & Pepper look for when hiring manual testers?
Code & Pepper screens manual testers across five dimensions: test case design technique proficiency, exploratory testing methodology, compliance and security testing awareness specific to FinTech and HealthTech, bug reporting quality and defect communication effectiveness, and collaboration and agile process fit.
Build Your Testing Team with Professionals Who Pass This Bar
Code & Pepper provides pre-vetted manual testers for FinTech and HealthTech teams that need structured test coverage, compliance testing expertise, and production-ready quality discipline, without the 3–6 month in-house hiring delay.
- Top 1.6% of engineers and QA professionals, 1 in 60 candidates accepted
- Onboarding in under 4 weeks, 50–70% faster ramp-up than in-house hiring
- Up to 50% lower cost versus building an in-house testing team
- 500+ successful projects across 18+ years of FinTech and HealthTech delivery
- FCA, PSD2, GDPR, HIPAA compliance built in from day one