Testing Types Interview Questions for Software Testing

Alpha is done in-house by internal teams before release; beta is done by a limited group of real users in their own environment.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

User Acceptance Testing — end users or the client verify that the system meets business needs in a production-like environment before go-live.

Retesting, or confirmation testing, checks that a specific bug that was fixed now works, using the same steps as the original bug. Regression testing checks that the fix or a new change has not broken other, previously working features. Retesting is planned for failed cases only, while regression covers a wider set of passing cases. Retesting usually comes first, then regression around the changed area.

Ad hoc testing is informal testing without test cases, done by a tester who understands the application and tries likely weak areas based on experience. Monkey testing gives random inputs and actions, often without knowing the application, to see if it crashes. Ad hoc testing is targeted and good at finding logical bugs, while monkey testing is good at finding stability issues and is often automated.

End-to-end testing checks a complete business flow from the user's first action to the final result, across all connected parts: UI, APIs, database, third-party services and notifications. For example, in online shopping: search a product, add to cart, pay, receive the confirmation email and see the order in the account. It finds integration issues that module-level testing misses, but it is slower and needs stable environments.

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.

System testing tests the complete, integrated application against the requirements in an environment close to production. It is done by the testing team after integration testing and before UAT. It covers functional testing of all features plus non-functional aspects such as performance, security, usability and compatibility. It is black box testing, so the tester checks behaviour from the user's point of view without looking at the code.

Model answer: I follow testing communities and blogs, practise on public demo sites and read release notes of the tools I use. Last month I learned API schema validation from an online course and tried it on a practice API. I also share one new idea in our team chat each week. This keeps me improving and helps the team pick up useful practices without waiting for formal training.

Check alignment, spacing, fonts, colours and images against the design. Verify text is not cut off or overlapping, buttons and links look clickable and show hover and disabled states, and error messages appear in the right place. Check responsive behaviour on different screen widths and zoom levels. Confirm icons and images load and have alt text. Compare with the design file and take screenshots for any differences.

Internationalisation tests that the product can support many languages and formats; localisation tests that a specific locale is correct for text, currency, date and layout.

Checking the application works across browsers, devices, operating systems, screen sizes and network conditions.

Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.

Verifying the application works across different hardware, software and settings combinations.

Smoke tests run on every build for quick feedback; full regression runs less often, such as nightly or before release.

Re-testing existing features after a change. Automate stable, repetitive, high-value flows that run every release.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

Evaluating how easy and pleasant a product is to use by observing real users complete tasks and noting confusion.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

Both are temporary pieces of code used in integration testing when some modules are not ready. A stub replaces a called lower-level module and returns fixed responses, used in top-down testing; for example, a stub payment service that always returns success. A driver replaces a calling higher-level module and sends inputs to the module under test, used in bottom-up testing. In API testing, mock servers play the role of stubs.

Recovery testing checks how well the system recovers from crashes, hardware failures, network loss or other failures. For example, kill the server during a file upload, or disconnect the network during payment, and verify the system restores a consistent state, does not lose or duplicate data and resumes or shows a clear message. It also measures recovery time against agreed targets, which matters for banking and healthcare systems.

Installation testing checks that software installs correctly on supported systems: fresh install, custom paths, low disk space, missing prerequisites and clean uninstall. Upgrade testing checks moving from an older version to the new one: user data and settings must be kept, database migrations must run, and the app must work after the upgrade. Also test skipping versions, such as 1.2 to 1.5, and what happens if the upgrade is interrupted.

Use analytics to pick browsers and versions that most real users have, plus the ones listed in the requirement, usually the latest two versions of major desktop and mobile browsers. Run the main flows on each and check layout, fonts, forms, date pickers, file upload and JavaScript errors in the console. Use responsive mode for screen sizes, and real devices or a cloud device lab for mobile browsers.

QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.

Retest the change itself, then run a focused regression on every page type that uses the header: home, listing, detail, checkout and account. Check navigation links, search, login and logout state, cart count and the mobile menu. Do cross-browser and responsive checks because layout changes affect all sizes. A quick visual comparison against the previous build helps spot alignment issues across many pages.

Read the hotfix ticket to know exactly what changed. First verify the fix with the original reproduction steps and data. Then check the directly connected flows, for example if the fix is in coupon calculation, test applying, removing and paying with a coupon. Finish with a quick smoke of login and the main business flow. Report the result immediately, mentioning what was and was not covered.

Trigger the email from each event, such as signup or order placed, and verify it arrives at the right address within the expected time. Check subject, sender name, personalised fields, amounts and links. Click every link and confirm it opens the right page. Check the layout on desktop and mobile mail apps, the unsubscribe option where required, and that no email is sent for failed or cancelled actions. Use a test mailbox tool in QA.

Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.

Compliance testing checks that software meets external laws, standards or internal policies, not just functional requirements. Examples include payment security standards for card data, data protection rules for personal data, accessibility guidelines and RBI rules for banking apps. Testers verify items such as consent capture, data retention, audit logs and masking. Findings are usually documented as evidence for auditors, so traceability and clear records matter as much as the tests.

Mutation testing measures the quality of a test suite. A tool makes small changes, called mutants, to the code, such as changing greater than to greater than or equal, and runs the tests. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, which shows a weak spot in the tests. The mutation score is killed mutants divided by total mutants. It is strong but slow, so teams apply it to critical modules.

Contract testing checks that a service provider and its consumers agree on the API format, such as request fields, response fields and status codes, without running a full end-to-end environment. The consumer defines what it expects, and the provider's build verifies it still meets that contract. It catches breaking changes early in microservice systems, where full integration environments are slow and fragile.

Compare record counts per table before and after. Check field mapping, data types, formats, encodings and default values for a sample of records, including edge cases like nulls, special characters and very old records. Verify relationships are kept, such as each order still linked to its customer. Run key business reports in both systems and compare totals. Test the rollback plan and confirm the new application works with migrated data.

Operational acceptance testing checks that the system is ready to be run and supported in production: backup and restore, failover, monitoring and alerts, deployment and rollback scripts, log access, security patches and support runbooks. UAT checks that the system meets business users' needs. OAT is done with operations or SRE teams, UAT with business users. Both must pass before a major go-live.

Ask the developer which code, services and database tables changed. Map them to impacted flows: all payment methods, refunds, partial payments, failed payment retries, invoices and order status updates. Add high-risk areas from past defects and anything that calls the same service. Run full payment regression because the business risk is high, plus a smoke test of the rest of the application before release.

Explain the risk: system testing proves the software matches the specification, but only users confirm it fits real business work. Propose a lighter option instead of none: a short, focused UAT on critical flows with two or three key users, or a staged rollout to a small user group with monitoring and quick rollback. If they still skip it, record the decision and the accepted risks with the product owner.

Backward compatibility testing checks that a new version still works with older versions of things it depends on or that depend on it. Examples: a new app version opens files and data created by the old one, a new API version still serves older mobile app versions that users have not updated, and an upgraded database keeps old records readable. It prevents breaking existing users when only some parts of the system are upgraded.