Testing interviews mix technical depth (test design techniques, automation frameworks, the test pyramid) with the behavioral and situational rounds that catch people off guard — "how would you test an ATM as an end-user" isn't a trick question, it's checking whether you can think systematically about coverage on the spot. This covers all 100 questions, organized by topic, with code, diagrams, and a mock test at the end.

Testing Fundamentals

Q1. What is software testing, and why is it important?

Software testing is the process of evaluating a system to find defects and verify it behaves as intended — important because catching a bug before release is dramatically cheaper (in cost, reputation, and user trust) than catching it in production, and because testing is the primary evidence that software actually does what it's supposed to do, not just that it compiles.

Q2. Define the difference between verification and validation in software testing.

Q3. Explain the software development life cycle and the role testing plays in each phase.

Q4. What are the different levels of software testing?

Q5. Describe the difference between static and dynamic testing.

Q6. What is a test case, and what elements should it contain?

Q7. Explain the concept of coverage in testing and the main types of coverage (e.g., line, branch, path, statement).

Coverage measures how much of the code your tests actually exercise — but 100% line coverage doesn't guarantee correctness, since a line can execute without its result ever being properly asserted on; coverage is a useful signal for finding untested code, not a proof of quality by itself.

Q8. What is the difference between white-box, black-box, and grey-box testing?

Q9. What is regression testing, and why is it performed?

Regression testing re-runs existing tests after a code change to verify that change didn't break anything that previously worked — performed because even a small, seemingly isolated change can have unexpected ripple effects elsewhere in the system, and manually re-checking everything by hand doesn't scale past a trivial codebase.

Q10. Explain unit testing and which tools you might use for it.

Unit testing verifies one small unit of code (a function, a class method) in isolation, typically with its dependencies mocked — the fastest, cheapest tests to run and the foundation of the test pyramid, covered further in this blog's language-specific interview posts (.NET Core, C#, JavaScript).

Q11. What is integration testing and what are its types?

Q12. What is system testing, and how does it differ from other types of testing?

System testing evaluates the fully integrated application as a whole, end-to-end, against the complete set of requirements — broader in scope than unit or integration testing (which each test smaller pieces in isolation), and typically the last technical testing phase before acceptance testing.

Q13. Define acceptance testing and describe its types.

Q14. What are the benefits of test automation?

• Runs far faster and more consistently than manual repetition
• Enables running the full regression suite on every single commit, which manual testing can't keep pace with
• Frees human testers to focus on exploratory testing and judgment-based work automation can't replace

Q15. When would you choose not to automate test cases?

• A test that will only ever run once (a one-off migration verification)
• Highly volatile UI/requirements still actively changing, where the automation would be rewritten as often as it runs
• Exploratory testing, where human judgment and curiosity — not a fixed script — is the actual value

Test Design Techniques

Q16. What is equivalence partitioning in software testing?

// A discount function valid for ages 0-120
// Equivalence classes: invalid (<0), valid (0-120), invalid (>120)
// One representative test per class, instead of testing every possible age individually
test.each([-5, 50, 150])("age %i", (age) => { ... });

Equivalence partitioning divides input values into groups expected to be handled the same way, testing one representative value per group instead of every possible value — dramatically reducing the number of test cases needed while still covering the meaningfully distinct behaviors.

Q17. Explain boundary value analysis with an example.

// A field accepting age 18-65
// Test the boundaries specifically, where bugs actually cluster:
[17, 18, 65, 66].forEach((age) => testAgeValidation(age));

Boundary value analysis specifically tests values at and just outside the edges of a valid range — off-by-one errors (using < instead of <=) are one of the most common real bug categories, and they show up exactly at these boundaries, not in the middle of a valid range.

Q18. What is state transition testing, and where is it useful?

State transition testing models a system as a set of states and the valid transitions between them (e.g. an order: Pending → Shipped → Delivered), then tests both valid transitions and invalid ones that should be rejected — useful for anything with a meaningful lifecycle or workflow, like an order status, a user account state, or a traffic light controller.

Q19. Describe the concept of decision table testing.

A decision table enumerates every combination of relevant conditions and the expected outcome for each — especially useful when business logic depends on multiple independent boolean conditions together, making it easy to spot a combination the requirements never actually addressed.

Q20. What is pairwise testing, and what tools support this technique?

Pairwise testing generates a test set covering every pair of parameter values at least once, rather than every possible combination (which grows combinatorially and quickly becomes infeasible) — a well-established statistical finding is that most real bugs are triggered by an interaction between just two parameters, so pairwise coverage catches the large majority of defects with far fewer tests. Tools like PICT (Microsoft's Pairwise Independent Combinatorial Testing tool) generate these test sets automatically.

Q21. How do you prioritize test cases in a test suite?

• Risk-based — test the highest-impact, most failure-prone areas first
• Frequency of use — test the most commonly exercised paths (the login flow) more thoroughly than a rarely-used admin setting
• Recently changed code — new/modified areas are statistically more likely to contain new bugs

Q22. Explain error guessing and its effectiveness.

Error guessing relies on tester experience and intuition to anticipate likely defect-prone areas — empty inputs, extremely large numbers, special characters, concurrent access — without a formal technique deriving them systematically. It's genuinely effective specifically because experienced testers have internalized patterns of where bugs actually tend to cluster, even without being able to fully formalize why.

Q23. What is exploratory testing, and how is it structured?

Exploratory testing is simultaneous learning, test design, and execution — a tester actively investigates the application, guided by what they discover as they go, rather than following a pre-written script. It's structured (not just random clicking) through session-based test management — a time-boxed session with a stated charter ("explore the checkout flow for edge cases around discount codes"), with notes on what was covered and found.

Q24. Describe the use-cases for model-based testing.

Model-based testing derives test cases automatically from a formal model of the system's expected behavior (a state machine, a set of business rules) — useful for systems complex enough that manually deriving comprehensive test cases is impractical, and where the model itself can be kept in sync with the actual requirements as a living source of truth.

Test Management

Q25. What is a test plan, and what should it typically include?

Q26. Describe test strategy and its importance.

A test strategy is the high-level, often organization-wide approach to testing — which levels/types of testing are standard practice, what tools are used, how much automation vs. manual testing is expected — while a test plan is the specific, per-project application of that strategy. It matters because without a stated strategy, every project reinvents testing approach from scratch, inconsistently.

Q27. Explain the concept of a test charter in exploratory testing.

A test charter is a brief, written mission for one exploratory testing session — a goal, a time box, and rough areas to focus on (not a step-by-step script) — giving exploratory testing enough structure to be purposeful and reportable, without constraining the tester's judgment the way a fully scripted test case would.

Q28. What is a test data management process?

Test data management covers creating, maintaining, and provisioning the data test cases need to run — synthetic/generated data for most cases, masked/anonymized production-derived data where realistic edge cases matter, and a process for refreshing/resetting test environments to a known state between test runs.

Q29. Define risk-based testing and its benefits.

Risk-based testing allocates testing effort proportional to a feature's risk — likelihood of failure combined with the severity of impact if it does fail — rather than testing everything equally. Its benefit is pragmatic: under real time/budget constraints, it concentrates limited testing effort where it matters most instead of spreading it thin evenly across everything.

Q30. How do you track and manage defects in software testing?

A defect's lifecycle typically moves through New → Assigned → In Progress → Fixed → Retested → Closed (or Reopened, if the fix didn't actually work) — with severity (impact) and priority (urgency, which are NOT the same thing) both tracked to help triage what gets fixed first.

Q31. What is the role of a test lead or test manager in a testing team?

Planning the overall test strategy/plan, allocating testers to features/risk areas, tracking progress against exit criteria, and being the point of escalation when quality and schedule pressures conflict — a role that's as much about communication and prioritization as hands-on testing.

Q32. Describe the challenges in test environment management.

• Environment configuration drifting out of sync with production, producing tests that pass in staging but fail for real
• Multiple teams contending for the same shared test environment, causing test interference
• Test data going stale or getting corrupted by earlier test runs, requiring a reliable reset/refresh process

Q33. What tools are available for test management, and how do they differ?

Q34. Explain what a traceability matrix is and how it is used in testing.

A traceability matrix maps each requirement to the test case(s) verifying it — used to confirm every requirement actually has test coverage, and (working backward) to identify exactly which requirements are affected when a specific test fails.

Q35. What are the key metrics used to measure test progress and coverage?

Automation Testing

Q36. What are the criteria to decide whether a test should be automated?

Q37. Describe the Page Object Model in automated testing.

class LoginPage {
  constructor(page) { this.page = page; }
  async login(username, password) {
    await this.page.fill("#username", username);
    await this.page.fill("#password", password);
    await this.page.click("#submit");
  }
}

// test:
const loginPage = new LoginPage(page);
await loginPage.login("ada", "secret123");

The Page Object Model encapsulates a page's structure (selectors) and interactions (methods) into a dedicated class, so tests describe intent (login()) rather than raw selectors — when the UI changes, you update one page object, not every test that happens to touch that page.

Q38. Explain the advantages and disadvantages of record and playback in test automation.

Q39. What is continuous integration, and how does it relate to test automation?

Covered in depth in the DevOps interview post — CI automatically builds and runs the automated test suite on every commit, which is the entire reason test automation exists in the first place: manual testing simply can't run on every single commit at the pace CI requires.

Q40. Which automation testing tools are you familiar with, and what are their strengths?

Q41. What is keyword-driven testing, and how does it work?

Keyword-driven testing expresses test steps as a sequence of keywords (Type, Click, Verify) with parameters, typically in a spreadsheet or table a non-programmer can author — an underlying automation engine translates each keyword into the actual code that executes it, decoupling test authoring from test implementation.

Q42. How does test automation fit into a DevOps environment?

Covered in depth in the DevOps interview post's testing section — automated tests running in the CI/CD pipeline are the actual gate that makes frequent, low-risk continuous deployment possible at all.

Q43. What are the main challenges you have faced in test automation?

• Flaky tests that fail intermittently for reasons unrelated to an actual bug, eroding trust in the whole suite
• Maintenance burden as the UI/API changes, if tests aren't structured to isolate that change (Page Object Model, covered above)
• Balancing test execution speed against thoroughness as the suite grows

Q44. Explain the use of assertions in automated tests.

expect(response.status).toBe(200);
expect(user.name).toEqual("Ada Lovelace");

An assertion checks that an actual value matches an expected one, and fails the test immediately (with a clear message) if it doesn't — assertions are what actually turn "the code ran" into "the code produced the correct result," which is the entire point of an automated test.

Q45. What is data-driven testing, and how can it be implemented?

const cases = [
  { input: "test@example.com", expected: true },
  { input: "not-an-email", expected: false },
];

test.each(cases)("validates %s", ({ input, expected }) => {
  expect(isValidEmail(input)).toBe(expected);
});

Data-driven testing runs the same test logic against many different input/expected-output pairs, defined as external data rather than duplicated test code — one test function covers many cases, and adding a new case is just adding a new data row, not writing a whole new test.

Performance Testing

Q46. What is performance testing, and how does it differ from functional testing?

Q47. Describe the subtypes of performance testing (e.g., load, stress, capacity).

Q48. What are the key performance testing metrics?

Q49. Explain how to set up a performance test.

Define realistic scenarios and load patterns based on actual (or projected) usage, establish a baseline on a representative environment, run the test with a load-generation tool ramping up traffic, and monitor both the application's own metrics and the underlying infrastructure while it runs — the environment matters enormously; testing against underpowered infrastructure produces results that don't generalize to production.

Q50. What tools can be used for performance testing, and what factors influence their selection?

Selection depends on the team's language preference, the protocols under test (HTTP, WebSocket, gRPC), and whether you need a code-first or GUI-first authoring experience.

Q51. What is a performance bottleneck, and how is it identified and addressed?

A bottleneck is the single component (database queries, an under-provisioned CPU, network I/O, a slow external API call) actually limiting overall throughput — identified by monitoring resource usage and response-time breakdowns during a load test to see which layer saturates first, then addressed by optimizing or scaling specifically that layer, since fixing anything else won't move the needle.

Q52. Explain the performance testing lifecycle.

Requirements gathering (what load/response-time targets actually matter for this system) → test planning → test environment setup → script/scenario creation → test execution → results analysis → tuning/optimization → re-testing to confirm the fix actually worked, repeated until targets are met.

Security Testing

Q53. What is security testing and why is it important?

Security testing specifically evaluates a system for exploitable vulnerabilities rather than functional correctness — covered in exhaustive depth in the 100 Web Security interview questions post on this blog. It matters because a functionally perfect application that's insecure can still cause catastrophic damage — a data breach, financial loss, reputational harm — that functional bugs alone rarely cause at the same scale.

Q54. Describe common security threats that testing should address.

The OWASP Top 10 (XSS, SQL injection, broken authentication, security misconfiguration, and more — each covered with prevention detail in the Web Security post) is the standard reference list any security testing effort should check against as a baseline.

Q55. What is OWASP, and why is it significant in security testing?

OWASP (the Open Web Application Security Project) is the non-profit maintaining the industry-standard Top 10 vulnerability list, testing guides, and tools (like ZAP) — significant because it's the shared, evidence-based reference point the security testing community organizes around, rather than every team inventing its own ad hoc checklist.

Q56. Explain SQL injection and how you test for it.

Covered with prevention code in both the SQL and Web Security interview posts — testing for it means attempting to inject SQL metacharacters (', --, ;) into every input field and API parameter, checking whether the application's behavior changes in a way that reveals it's being interpreted as SQL rather than treated as plain data.

Q57. How do you perform authentication and authorization checks in security testing?

• Attempt to access protected resources without authenticating at all, and confirm access is denied
• Attempt to access another user's resources while authenticated as a different, lower-privileged user (checking for broken object-level authorization)
• Test session expiry, logout invalidation, and password reset flows specifically for logic flaws

Q58. What tools can be used for security testing?

Q59. What is penetration testing, and how is it executed?

Covered in depth in the Web Security interview post — a simulated, authorized attack against a system to find and actually exploit vulnerabilities (not just detect them), typically following a structured methodology: reconnaissance, scanning, exploitation, and reporting findings with remediation guidance.

Q60. What is the role of encryption and secure communication in testing?

Testing should verify that sensitive data is actually encrypted in transit (TLS correctly configured, no fallback to plain HTTP) and at rest, and that certificate validation isn't accidentally disabled anywhere in the stack (a common, dangerous shortcut sometimes left in from debugging a certificate issue) — see the Web Security post's cryptography section for the underlying mechanisms being verified.

Mobile and Web Application Testing

Q61. How does mobile application testing differ from desktop application testing?

Q62. Explain different types of mobile application testing, such as native, web, and hybrid.

Q63. What emulators are available for mobile testing, and when would you use real devices?

Android Emulator and iOS Simulator (both free, built into their respective SDKs) are fine for early, fast-iteration functional testing — real devices matter for anything genuinely hardware-dependent (camera, GPS, biometrics, actual battery/thermal behavior) and for final validation before release, since an emulator's performance characteristics don't perfectly match real hardware.

Q64. What is responsive testing, and how is it conducted?

Responsive testing verifies a web application's layout and usability across different screen sizes/orientations — using browser DevTools' device emulation for quick checks during development, and real devices or a cloud device farm (BrowserStack, Sauce Labs) for final verification across the actual range of devices real users have.

Q65. Describe challenges unique to mobile application testing.

The sheer combinatorial device/OS-version matrix makes exhaustive testing genuinely infeasible (prioritize by actual user analytics data on what devices/versions matter most), and testing real-world conditions like poor connectivity or app-switching interruptions requires deliberate effort beyond a straightforward functional test pass.

Q66. What is cross-browser testing?

Cross-browser testing verifies a web application behaves and renders consistently across different browsers (and versions) — necessary because browsers don't implement web standards identically, and a bug appearing only in one specific browser/version is a genuinely common category of real-world defect.

Q67. What are the key areas to focus on in web application testing?

• Functional correctness of core user flows
• Cross-browser and responsive/mobile compatibility
• Security (covered in the Web Security post) and performance under realistic load
• Accessibility — usable with a screen reader, keyboard-only navigation, sufficient color contrast

Test Automation Frameworks

Q68. What is a test automation framework?

A framework is the shared structure, conventions, and reusable utilities (setup/teardown, reporting, the Page Object Model, data providers) that automated tests are built on top of — without one, every test reinvents its own approach, making the suite inconsistent and hard to maintain as it grows.

Q69. Describe different types of test automation frameworks (e.g., data-driven, keyword-driven, hybrid, modular).

Q70. What considerations are involved in choosing a test automation framework?

• The team's existing language/tooling expertise
• The application type (web, mobile, API) and what the framework actually supports well
• Community support and maintenance activity — an abandoned framework is a real long-term risk
• How well it integrates with the existing CI/CD pipeline and reporting tools

Q71. How can you ensure maintainability of an automation framework?

• The Page Object Model (or equivalent abstraction) to isolate UI changes to one place
• Clear, consistent naming and organization so tests are discoverable and understandable months later
• Regularly pruning/fixing flaky tests instead of letting them accumulate and erode trust in the suite

Q72. How is reporting implemented in automation frameworks?

Most frameworks generate structured output (JUnit XML, HTML reports, or a JSON format) that CI systems parse to display pass/fail results, and dedicated reporting tools (Allure, ExtentReports) add richer visualizations — screenshots on failure, execution trends over time, categorized failure reasons — beyond a bare pass/fail count.

API Testing

Q73. What is API testing, and why is it important?

API testing verifies an API's behavior directly (requests, responses, status codes, data contracts) without going through a UI — important because it's faster and more stable than UI-driven testing of the same logic, and it catches backend issues (a broken contract between services) that a UI test might mask or never even exercise.

Q74. How do you approach testing RESTful APIs?

test("GET /users/1 returns the user", async () => {
  const res = await fetch("/api/users/1");
  expect(res.status).toBe(200);
  const user = await res.json();
  expect(user).toMatchObject({ id: 1, name: expect.any(String) });
});

Test each endpoint's status codes for both success and failure cases, response body shape/data correctness, and behavior at the edges — missing/invalid parameters, unauthorized access, rate limiting — treating the API's documented contract as the specification to test against.

Q75. Explain how to test SOAP-based web services.

SOAP testing validates the XML request/response structure against the service's WSDL contract, checks SOAP fault handling for error cases, and often uses dedicated tooling (SoapUI) purpose-built for SOAP's more rigid, XML-schema-driven contract, as opposed to REST's typically looser JSON-based structure.

Q76. What kind of tests would you write for an API?

• Happy-path tests for each endpoint's expected success case
• Negative tests — invalid input, missing required fields, malformed requests
• Authentication/authorization tests — unauthenticated and under-privileged access attempts
• Contract tests verifying the response shape matches the documented schema exactly

Q77. Describe how to use Postman for API testing.

pm.test("Status code is 200", () => {
  pm.response.to.have.status(200);
});
pm.test("Response has a name field", () => {
  pm.expect(pm.response.json()).to.have.property("name");
});

Postman lets you build requests interactively, organize them into collections, and attach JavaScript-based assertion scripts (as above) that run automatically after each request — collections can also be run headlessly via Newman in a CI pipeline, turning exploratory API testing into an automated regression suite.

Q78. What is contract testing, and which tools support this type of API testing?

Contract testing verifies that a service's API still honors the exact contract its consumers depend on — Pact is the most established tool, letting a consumer define expectations that get verified against the actual provider automatically, catching a breaking change before it ships rather than discovering it only when a dependent service breaks in production.

Quality Assurance Processes

Q79. What is quality assurance, and how does it differ from testing?

Testing is one activity within the broader discipline of QA — QA also covers process definition, code review standards, and continuous process improvement aimed at preventing defects, not just finding ones that already got introduced.

Q80. Describe the QA process in agile development.

QA is embedded within each sprint rather than a separate phase at the end — testers participate in story refinement (clarifying testability upfront), write and automate tests alongside development within the same sprint, and continuously integrate testing into the team's regular cadence rather than a big final QA pass before release.

Q81. Explain the role of a QA engineer in a scrum team.

A QA engineer in Scrum participates in sprint planning (assessing testability and estimating test effort), writes and maintains automated tests, performs exploratory testing on new work, and — critically — represents quality/user-experience concerns during planning discussions, not just at the end once code is already written.

Q82. What quality metrics are important for a software project?

Q83. How do you establish a QA process in an organization that has none?

• Start with the highest-risk, highest-value area first, as a visible proof of concept
• Introduce basic automated regression coverage before anything more sophisticated
• Establish clear defect-tracking and triage practices so bugs don't get lost or ignored
• Grow process incrementally based on what's actually needed, rather than imposing a heavyweight framework all at once

Advanced Testing Topics

Q84. What are the emerging trends in software testing, such as AI and ML applications?

AI-assisted test generation (suggesting test cases from requirements or code changes), self-healing test automation (automatically adapting a selector when a UI element's locator changes slightly), and ML-based visual regression testing (flagging meaningful visual differences while ignoring noise like anti-aliasing) are the most concrete current applications — still maturing, and best treated as an assistive tool augmenting testers' judgment rather than a full replacement for it.

Q85. How do you handle testing in a continuous delivery environment?

A fast, reliable automated test suite in the pipeline is non-negotiable — testing has to happen on every single commit, not periodically, which means investing in test speed (parallelization, a proper test pyramid balance) and eliminating flakiness aggressively, since a slow or unreliable suite directly blocks the deployment cadence continuous delivery depends on.

Q86. Describe the concept of shift-left testing.

Covered from a broader DevOps angle in the DevOps interview post — moving testing earlier in the development process (unit tests written alongside the code, requirements reviewed for testability before development even starts) so defects are caught when they're cheapest to fix.

Q87. What is chaos engineering, and how do you apply it?

# Example: deliberately kill a random pod to verify the system recovers gracefully
kubectl delete pod $(kubectl get pods -o name | shuf -n 1)

Chaos engineering deliberately injects failures (killing a server, adding network latency, exhausting a resource) into a system — typically in a controlled, monitored way, often starting in a non-production environment — to verify it actually degrades gracefully and recovers as designed, rather than assuming resilience without ever testing it under real failure conditions.

Q88. Explain the role of virtualization in software testing.

Virtualization (VMs, containers) provides isolated, disposable, quickly-provisioned test environments — spin up a clean environment for each test run, tear it down after, and never worry about state leaking between runs or one team's tests interfering with another's on a shared machine.

Behavioral Testing Questions

Q89. How do you stay updated about new testing technologies and practices?

Following testing-focused communities and conferences (Ministry of Testing, TestBash), release notes for tools actually in your stack, and — most importantly — hands-on experimentation, since testing tooling changes fast enough that reading alone tends to produce shallow, quickly-outdated familiarity.

Q90. Describe a situation where you had to meet a tight deadline for testing. How did you handle it?

A strong answer names the concrete prioritization decision made (risk-based testing — focusing on the highest-impact areas first, deliberately deferring lower-risk edge cases with stakeholder agreement) rather than claiming everything got fully tested anyway — interviewers are specifically listening for realistic trade-off reasoning under pressure, not an implausible "I did it all" answer.

Q91. How do you handle disagreements with developers regarding bugs or software issues?

Ground the disagreement in reproducible evidence (exact steps, actual vs. expected behavior, logs/screenshots) rather than opinion, and separate "is this a bug" (a behavioral/factual question) from "how severe is it" (a judgment call reasonably open to discussion) — most disagreements resolve faster once framed as a shared investigation rather than a dispute.

Q92. Can you explain your approach to testing a feature with unclear requirements?

Ask clarifying questions directly rather than guessing silently, document the assumptions made where genuine ambiguity remains, and lean on exploratory testing plus comparison against similar existing features/common UX conventions to fill the gaps — flagging unclear requirements back to product/business is itself a valuable testing contribution, not a failure to "just figure it out."

Q93. Describe a particularly challenging bug or issue you've had to deal with.

The strongest answers describe a genuinely hard-to-reproduce issue (intermittent, environment-specific, or a race condition) and the systematic process used to actually isolate it — narrowing scope methodically, gathering logs/environment details, forming and testing specific hypotheses — rather than just "I found it eventually."

Situation-based Testing Questions

Q94. How would you test an ATM machine as an end-user?

• Functional: successful withdrawal, deposit, balance inquiry, PIN change
• Boundary: withdrawing exactly the account balance, an amount exceeding it, the daily withdrawal limit
• Negative: wrong PIN (repeatedly, checking lockout behavior), an expired/damaged card, network failure mid-transaction
• Non-functional: security (card skimming resistance, on-screen privacy), accessibility, transaction speed under load

This question is testing whether you can systematically generate a comprehensive test scope on the spot — the specific categories matter less than demonstrating a structured approach (functional, boundary, negative, non-functional) rather than a random unstructured list.

Q95. Imagine you have a website that is experiencing performance issues. How would you test to find the cause?

Reproduce the issue under controlled conditions first, then use performance monitoring/profiling tools to identify exactly where time is actually spent (database queries, external API calls, front-end rendering, network) — narrowing from "the site is slow" to a specific bottleneck, then load-testing that specific suspected area to confirm the hypothesis before recommending a fix.

Q96. Given an e-commerce application, how would you carry out security testing?

Test authentication/session management, payment flow security (PCI DSS-relevant, covered in the Web Security post), authorization on order/account data (can user A see user B's order history?), input validation on search/review fields for injection, and check for exposed sensitive data in API responses or client-side code.

Q97. How would you approach testing a new software application with no documentation available?

Start with exploratory testing to build a working mental model of the application's actual behavior, interview whoever built it (or similar systems) for implicit assumptions never written down, and derive test cases from observed behavior and common domain conventions — while flagging the missing documentation itself as a genuine risk worth raising, not just working around silently forever.

Q98. Describe how you would test a new feature that interacts with multiple systems.

Unit-test each system's own logic in isolation first, then integration-test the actual interactions between them (contract testing where relevant, covered earlier), and finally an end-to-end test of the complete cross-system flow — layering coverage from narrow/fast to broad/slow rather than relying on end-to-end tests alone to catch everything.

Technical Testing Questions

Q99. Write a basic SQL query to fetch records from a customer table where the customer's age is more than 30 years.

SELECT * FROM customers WHERE age > 30;

Q100. Given a function that calculates the nth Fibonacci number, how would you test it?

test.each([
  [0, 0], [1, 1], [2, 1], [10, 55],
])("fibonacci(%i) = %i", (n, expected) => {
  expect(fibonacci(n)).toBe(expected);
});

test("throws for a negative input", () => {
  expect(() => fibonacci(-1)).toThrow();
});

Cover the base cases (0, 1) explicitly, a few typical values, a boundary/edge case (a large n, checking for performance or overflow issues), and invalid input (negative numbers, non-integers) — the same equivalence-partitioning and boundary-value-analysis thinking covered earlier, applied to a concrete function.

Test yourself

A quick mock test covering the ground above — the rapid-fire round that often opens a software testing interview before the deeper scenario-based follow-ups.