Вопросы на собеседовании тестировщика (QA) на английском

Пример ответа · EN

Testing evaluates a product to find defects and to give information about its quality. Quality assurance is broader: it focuses on the process, so that defects are less likely to appear at all. For example, joining requirement reviews is QA work, while running test cases is testing. In my daily work I do both.

Пример ответа · EN

Verification checks that we built the product right: it matches the specification. Validation checks that we built the right product: it meets the real needs of users. A feature can pass verification and still fail validation if the requirement itself was wrong. That is why I like to see real user scenarios early.

Пример ответа · EN

First I read the requirement and list questions about anything ambiguous. Then I identify the inputs, rules and expected results, and apply test-design techniques to choose the cases. Each case has preconditions, steps and one clear expected result. I link the cases to the requirement, so coverage is easy to review.

Пример ответа · EN

I start with equivalence partitioning, to group inputs that should behave the same, and boundary value analysis for the edges of those groups. For rules with several conditions, I use a decision table. For workflows, I use state transition testing. On top of these, I add experience-based tests such as error guessing.

Пример ответа · EN

I would split the inputs into three partitions: below 18, from 18 to 65, and above 65. Then I test the boundaries: 17, 18, 65 and 66. I also check invalid input, such as an empty value, letters, a decimal number and a very long string. Finally, I confirm that the error message is clear.

Пример ответа · EN

It starts with a clear title that says what is broken and where. Then come exact steps to reproduce, the expected and the actual result, and details of the environment, such as the build and the browser. I attach a screenshot, a video or logs when they help. One report describes one problem, so it can be fixed and verified separately.

Пример ответа · EN

Severity describes how much a defect affects the system. Priority describes how soon it should be fixed. A typo in the company name on the home page has low severity but high priority. A crash in a rarely used admin report can have high severity but lower priority. I suggest the severity, and the team usually agrees on the priority.

Пример ответа · EN

I rate each area by the likelihood of failure and the impact if it fails. Payments, sign-in and recently changed code usually come first. I test high-risk areas deeply and lower-risk areas with quick checks. I share the plan with the team, so everyone knows what was tested less.

Пример ответа · EN

I include the core user journeys, areas that have broken before, and features connected to recent changes. I remove tests that no longer find problems or duplicate other checks. The stable, repetitive part of the suite is a good candidate for automation. I review the suite after each major release.

Пример ответа · EN

Tests that run often, are stable and have clear expected results, such as smoke and regression checks of core journeys. API tests are usually faster and less fragile than UI tests, so I automate there when possible. I keep exploratory and usability testing manual. Automation should save time, so I also count the cost of maintaining it.

Пример ответа · EN

Smoke testing is a quick check of the main functions of a new build, to decide whether it is stable enough for further testing. Sanity testing is a narrow check of a specific fix or change. Teams use these terms differently, so I clarify what they mean in their process. The goal of both is to avoid wasting time on a broken build.

Пример ответа · EN

I check status codes, the response body against the schema, and the headers. Then I test validation with missing, invalid and boundary values, plus authentication and permissions. I look at error messages, the result of repeated requests and the response time. I use tools such as Postman or an automated test suite.

Пример ответа · EN

I gather information from the developer, the product owner and similar features, and write down my assumptions. Then I run exploratory sessions with a clear goal and a time limit and take notes. I confirm unclear behaviour with the team instead of guessing. Afterwards I turn the main findings into test cases for regression.

Пример ответа · EN

A test strategy describes the general approach to testing for a product or an organisation: test levels, types, tools and quality criteria. A test plan applies that approach to a specific project or release, with scope, schedule, resources, risks and entry and exit criteria. The strategy changes rarely, while plans are updated often.

Пример ответа · EN

Fast checks, such as unit tests and linters, run on every commit. API and integration tests run on each merge request, and a smaller set of UI tests runs before deployment. A failed stage blocks the next one, so problems are found early. I review the test results and fix flaky tests instead of ignoring them.

Пример ответа · EN

I do not just rerun it until it passes. I collect logs and screenshots from failed runs and look for a pattern, such as timing, test order or shared data. Common causes are fixed waits, dependencies between tests and unstable environments. If I cannot fix it quickly, I quarantine it with a ticket, so it does not hide real failures.

Пример ответа · EN

Testing cannot prove that there are no defects, so I rely on agreed exit criteria. For example, all critical tests pass, no open high-severity bugs remain, and the planned risks are covered. If a criterion is not met, I explain the risk and the team decides. My role is to give clear information, not to block the release alone.