A software testing intern supports the QA team by executing test cases, logging bugs, retesting fixes and learning the product and tools. Interviews are mostly about basics: what testing is, types of testing, writing test cases for simple features, the bug life cycle and a few SQL basics. Interviewers look for curiosity, clear thinking and a willingness to learn rather than deep experience.
Testing fundamentals Test execution Bug logging Basic SQL Communication
Solved for this roleStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What is integration testing and what are its approaches?
Integration testing checks that modules or services work correctly together, focusing on interfaces and data flow. Approaches: big bang, where all modules are combined at once and testing is simple to plan but defects are hard to locate; top-down, where high-level modules are tested first using stubs for lower ones; bottom-up, using drivers for higher ones; and sandwich, which mixes both. Incremental approaches make it easier to find which interface failed.
The test basis is the set of documents and knowledge from which test cases are derived. It includes requirement specifications, user stories with acceptance criteria, design documents, wireframes, API contracts, business rules and even existing system behaviour. A good test basis lets you trace each test case back to a requirement. If the test basis is weak or missing, testers must clarify it before or while testing.
It means that finding and fixing many defects does not guarantee success if the system itself does not meet user needs. A bug-free product built on wrong or misunderstood requirements is still a failure. For example, a perfectly working report that shows the wrong business metric is useless to the client. This is why testers validate against real user expectations, not just the written specification.
06
Describe a time you missed a bug that reached production.
Model answer: Situation: a discount was applied twice when users pressed the pay button quickly. Task: I had tested the feature and missed it. Action: I owned it in the retrospective, helped reproduce and verify the fix, and added double-click and slow network cases to our checklist for all payment buttons. Result: similar issues were caught in later sprints, and I learned to always test repeated actions.
07
A requirement says the page should load fast. How do you turn it into a test case?
The word fast is not testable, so ask the product owner for a measurable target, for example the page loads within 3 seconds on a 4G network for 95 percent of requests. Agree on the conditions: device, network, data size and whether it is first load or cached. Then write the test with those conditions and expected time. Record the agreed number in the story so the expected result is not open to opinion.
08
Tell me about a time you used a test design technique to reduce the number of test cases.
Model answer: Situation: in my training project, a registration form had age, state and course fields, and my first draft had over 60 test cases. Task: cut effort without losing coverage. Action: I applied equivalence partitioning and boundary values to age and pairwise combinations for state and course. Result: I covered the same rules with 18 cases, my mentor approved them, and execution finished in half the time.
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
10
How do you test password policy and account lockout?
Try passwords that break each rule: too short, no digit, no special character and common passwords, and check clear messages. Verify the password is masked and not shown in the URL or logs. Enter the wrong password up to the limit and confirm the account locks for the defined time or until reset. Check that the error message does not reveal whether the username exists and that the lockout counter resets after a successful login.
Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.
15
What is the difference between an error, a defect and a failure?
Evaluating software to find defects and confirm it meets requirements. It reduces risk, protects users and saves the cost of fixing bugs after release.
A bug bash is a short, time-boxed session where people from across the team, including developers, product and support, test the product together to find as many issues as possible before a release. To run one, share a build, scope and test accounts, assign focus areas, give a simple bug template and a shared board, then triage findings at the end. It brings fresh eyes and finds usability issues formal tests miss.
19
When should you reopen a bug and when should you log a new one?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
20
Tell me about a time you had to learn SQL or API testing quickly for a project.
Model answer: Situation: in my first project, testers had to verify orders in the database, and I knew only basic SELECT. Task: become useful within a week. Action: I practised joins on a copy of the test database every evening and asked a senior to review my queries. Result: by the second sprint I was validating order data on my own and caught a missing tax column bug.
21
What are components, labels and fix versions in Jira?
Components are fixed sub-parts of a project, such as Payments or Login, often with a default owner. Labels are free-text tags, such as regression or ui, that anyone can add for grouping. Fix version is the release in which the issue is planned to be fixed, while affects version is where the bug was found. Testers use these fields to filter bugs and to build release-wise reports.
22
What is the difference between Scrum and Kanban for a tester?
Scrum works in fixed sprints with planned scope, roles and ceremonies, so the tester plans testing for the sprint and aims to finish all stories by the sprint end. Kanban is a continuous flow with work-in-progress limits and no fixed sprints, so testing happens as each item reaches the test column. In Kanban, a tester watches that the testing column does not become a bottleneck and raises it when limits are hit.
23
Difference between black box, white box and grey box testing?
A duplicate bug is a new report for a problem that is already logged. Before raising a bug, search the tracker by key words, module, error message and recent open bugs, and ask teammates working on the same area. If a similar bug exists, add your extra information, such as another browser or data set, as a comment instead of a new ticket. This keeps the backlog clean and saves triage time.
Model answer: To me quality means the product does what users need, reliably, and is easy to use, not just that test cases pass. In my final-year project I tested a library app; all features worked, but students struggled to find the search option. I reported it as a usability issue and the team moved search to the home screen. That taught me to test from the user's point of view as well.
Verify reset with a registered email sends a link. Verify an unregistered email shows a generic message without revealing whether the account exists. Check the link opens the reset page and expires after the defined time. Check the link works only once. Validate new password rules and that confirm password must match. Verify login works with the new password and fails with the old one. Check resend limits and that other sessions are logged out.
28
How do you test a web page using only the keyboard?
Put the mouse away. Press Tab and Shift+Tab to move through every link, button and field, and check that the order is logical and the focus outline is always visible. Use Enter and Space to activate buttons and links, arrow keys for menus, radio groups and sliders, and Escape to close dialogs. Check that nothing traps focus, hidden items do not receive focus and a skip to main content link works.
A fixed sleep, such as waiting five seconds, is either too long, which makes the suite slow when the page loads in one second, or too short, which makes the test fail when the server is slow. Both waste time and cause flaky results. Instead, wait for a real condition: an element to appear, a network response to finish or a loading spinner to disappear. Modern tools do much of this automatically.
Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).
Exhaustive testing means trying every possible input, path and combination, which is practically infinite for real software. Even a single text field accepting 20 characters has more combinations than you could ever run. So testers use risk and techniques like equivalence partitioning and boundary value analysis to select a small set of tests that give high confidence. The goal is enough coverage of important risks, not every possible case.
Read the requirement and identify inputs, outputs, business rules, user roles and states. Turn each rule into a condition with an expected result, then add negative and boundary conditions. For example, 'users can withdraw up to 10,000 per day' becomes: withdraw below the limit, exactly at the limit, above the limit, multiple withdrawals adding up to the limit, and the limit resetting the next day. Each condition then becomes one or more test cases.
34
When is manual testing a better choice than automation?
Manual testing is better for exploratory testing, usability and look-and-feel checks, features that change often, one-time tests and early testing of new functionality. Automation pays off for stable, repetitive tests such as regression suites, data-driven checks and smoke tests run on every build. Most teams combine both: manual for discovery and judgement, automation for speed and repeatability.
35
How do you handle a bug found late in a release cycle?
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
Severity = impact on the system. Priority = urgency to fix.
Logo misspelt on the homepage → low severity, high priority.
Crash in a rarely used report → high severity, low priority.
40
What is the role of a manual tester in a software team?
A manual tester understands requirements, writes test scenarios and test cases, prepares test data, executes tests on each build, logs clear bug reports and retests fixes. They also do exploratory testing, join stand-ups and reviews, and give a quality status before release. Beyond finding bugs, a good manual tester represents the end user and raises usability or requirement gaps early, when they are cheap to fix.
Frequently asked questions
What does a Software Testing Intern do?
A software testing intern supports the QA team by executing test cases, logging bugs, retesting fixes and learning the product and tools. Interviews are mostly about basics: what testing is, types of testing, writing test cases for simple features, the bug life cycle and a few SQL basics. Interviewers look for curiosity, clear thinking and a willingness to learn rather than deep experience.
Which skills are tested in a Software Testing Intern interview?
Expect questions on Testing fundamentals, Test execution, Bug logging, Basic SQL, Communication. Most rounds also ask you to explain a project and solve one practical problem live.
How do I prepare for a Software Testing Intern interview?
Revise Manual Testing Basics, Test Case Design, Bug Life Cycle and Jira first using the topic sheets, practise the questions on this page aloud, then do one full mock interview to practise timing.