Testing & Quality interview questions

A/B testing is an experiment that shows two versions of a feature to random groups of real users and measures which one performs better on a chosen metric.

Long enough to reach the sample size you calculated in advance, and usually at least one or two full weeks so that weekday and weekend behavior are both included. Ending a test the moment results look good often leads to false conclusions.

It is a measure of how unlikely the observed difference would be if the two versions actually performed the same. Teams commonly require a significance level of 5 percent before declaring a winner.

A canary release exposes a new version to a small share of traffic to catch errors before rolling it out to everyone. An A/B test splits users between two working versions to learn which one produces better results.

Acceptance testing checks whether software meets the requirements agreed with its users or customers, so the team can decide if it is ready to release.

UAT stands for user acceptance testing. Real users, customers, or their representatives try the finished software in a realistic environment and confirm that it supports their work before it goes live.

System testing is done by the development or QA team to check that the complete system meets its technical specification. Acceptance testing looks at the same system from the user's or business's point of view and decides whether it is acceptable to release.

The criteria are agreed by the Product Owner, developers, and testers together. Developers or testers usually automate them, while user acceptance testing is performed by the users or customers themselves.

An assertion is a statement in code declaring that a condition must be true at that point, stopping the test or program with an error if it is false.

The assertion throws an error, such as AssertionError in Python or JavaScript's node:assert module. In a test, the runner marks that test as failed and shows the expected and actual values; in a program, execution stops unless the error is caught.

Yes, for conditions that indicate a bug in your own code, such as an impossible state. Don't use them for user input or other expected errors, which need proper validation and error handling because assertions may be disabled.

Behavior-driven development is a practice where developers, testers, and business people agree on plain-language examples that become automated tests.

TDD is a developer practice of writing a failing unit test before the code. BDD applies a similar test-first idea at the feature level, using plain-language scenarios that business people, developers, and testers write together.

Gherkin is a simple structured language for writing BDD scenarios with keywords such as Feature, Scenario, Given, When, and Then. BDD tools read Gherkin files and run the matching step definitions as tests.

Given describes the starting situation, When describes the action or event, and Then describes the expected outcome. The pattern keeps each scenario focused on one behavior.

Black-box testing checks software only through its inputs and outputs, against what it is supposed to do, without looking at or relying on the code inside.

Black-box testing designs tests from the specification and checks behavior from the outside. White-box testing designs tests from the code's structure to exercise its branches and paths. Most teams use both.

A technique that tests values at and around the edges of valid ranges, such as the minimum, maximum and just outside them, because errors are most common at those boundaries.

Usually, yes. End-to-end tests drive the application like a user and check visible results, without depending on how the code is written internally.

Contract testing is a technique that checks whether two services agree on the requests and responses they exchange, without running both of them together.

An integration test runs real components together to see whether they work as a whole. A contract test checks each side separately against a shared agreement, so it is faster, needs no shared environment, and shows exactly which side broke compatibility.

It is a style of contract testing in which the consumers of an API write down the interactions they depend on, and the provider runs those contracts as tests. This lets the provider change anything its consumers don't use without fear of breaking them.

Not entirely. Contract tests greatly reduce how many end-to-end tests you need to check compatibility between services, but a few end-to-end tests are still useful to confirm that critical user journeys work in a fully deployed system.

Cypress is a JavaScript framework that runs end-to-end and component tests for web apps inside the browser, with automatic waiting and an interactive runner.

Both are modern and wait automatically. Cypress offers a very friendly interactive runner and runs inside the browser. Playwright supports multiple tabs and contexts, more languages and parallel runs without a paid service. Many new projects pick Playwright, while Cypress remains popular with front-end teams.

Yes. The Cypress test runner is open source and free. Cypress Cloud, which adds recording, parallelization and analytics, is a paid service with a free tier.

Mounting a single front-end component, such as a React or Vue component, in a real browser and testing it in isolation, without running the whole application.

An end-to-end test is an automated test that runs a complete user journey through the whole application, from the user interface to the database and back.

E2E stands for end-to-end. An E2E test checks an application from one end, the user interface, to the other, the database and external services, in a single realistic scenario.

They start a full application, drive a real browser, and depend on networks, timing, and test data. Any of these can cause delays or random failures, which is why E2E suites are kept small and wait for specific elements instead of using fixed delays.