QA and SDET interview questions and answers for 2026

What is the difference between 401 and 403?

401 Unauthorized actually means unauthenticated: the request has no valid credentials (missing, expired or invalid token), so the client should authenticate. 403 Forbidden means the server knows who you are, but you don't have permission for this resource or action, such as a normal user calling an admin endpoint. Some APIs return 404 instead of 403 to avoid revealing that a resource exists, which is a valid security choice if it's consistent.

What are web-first assertions? Why are they important?

Assertions such as await expect(locator).toBeVisible(), toHaveText(), toHaveCount(), toHaveURL() and toHaveValue() automatically retry until the condition is met or the timeout expires. Compare expect(await locator.isVisible()).toBe(true), which checks once and fails if the UI is a few milliseconds slow. Web-first assertions are one of the main reasons Playwright tests are less flaky.

Write a query to find duplicate emails in a users table.

Group by the column and keep groups with more than one row.

SELECT LOWER(email) AS email, COUNT(*) AS cnt
FROM users
GROUP BY LOWER(email)
HAVING COUNT(*) > 1;

Using LOWER() catches case-insensitive duplicates (Ana@x.com and ana@x.com), which are often a real bug if emails should be unique.

Why shouldn't you use cy.wait(5000)? What should you do instead?

A fixed wait makes tests slow when the app is fast and flaky when it's slow. Instead, rely on retry-ability (cy.get(...).should('be.visible')), or alias network requests and wait for them: cy.intercept('POST', '/api/orders').as('createOrder'), perform the action, then cy.wait('@createOrder').its('response.statusCode').should('eq', 201).

Explain the test pyramid and its alternatives. How do you decide the right balance?

The test pyramid recommends many fast unit tests, fewer integration or API tests and a small number of slow UI end-to-end tests, because tests higher up are slower, more brittle and more expensive. Alternatives such as the testing trophy emphasise integration tests for frontend apps. The right balance depends on the architecture and risk. I push each check to the lowest level that can prove it, and keep UI tests for critical user journeys. An "ice cream cone" (mostly manual and UI tests) is the anti-pattern to avoid.

The product manager wants to release with a known critical bug. What do you do?

My role is to make sure the decision is informed, not to block it single-handedly. I explain the bug's impact clearly (who's affected, how badly, frequency, data or security implications), suggest options (delay, hotfix soon after, disable the feature with a flag, a workaround with support preparation, communication to users) and document the decision and the risk acceptance. If it's a serious security, legal or safety issue, I escalate according to company policy.