QA Engineer interview questions

Quality assurance, quality control, and testing address quality at different levels.

• Quality assurance improves processes to prevent defects, for example through requirement reviews and a definition of done.
• Quality control checks the product against requirements, while testing is its main defect-finding activity.
• Junior QA engineers mostly test, but the distinction explains why QA work starts before coding.

A test case is a documented, reproducible check of one scenario.

• It states the goal, preconditions, steps, test data, and expected results.
• A good case is atomic, traceable to a requirement, and clear to someone unfamiliar with the feature.
• Expected results must be concrete, such as a dashboard redirect and a visible welcome message.

Positive and negative testing check valid and invalid behavior respectively.

• Positive testing uses valid input, such as a correct email and password, and confirms the expected flow succeeds.
• Negative testing uses invalid or unexpected input and checks that the system fails safely with a clear error.
• Both matter because production incidents often occur on error paths that happy-path testing misses.

Boundary value analysis targets the edges of valid ranges where defects often occur.

• For a range from 1 to 100, useful values are 0, 1, 2, 99, 100, and 101.
• These values reveal off-by-one errors more effectively than an arbitrary middle value such as 50.
• Boundaries also apply to string lengths, dates, file sizes, and pagination.

Equivalence partitioning reduces many possible inputs to a small representative test set.

• It groups inputs that the system should handle identically and tests one value from each group.
• For an accepted age of 18 to 65, the groups are below 18, within range, above 65, and non-numeric input.
• Combined with boundary value analysis, it provides strong coverage without testing every value.

Smoke, sanity, and regression testing differ mainly in scope and purpose.

• Smoke testing quickly checks critical paths after a build to decide whether deeper testing can begin.
• Sanity testing narrowly confirms that a specific fix or change works.
• Regression testing broadly checks that recent changes did not break existing functionality.

Functional testing checks what a system does, while non-functional testing checks how well it does it.

• Functional checks confirm features meet requirements, such as a transfer moving money correctly.
• Non-functional checks cover performance, security, usability, accessibility, and browser compatibility.
• A checkout can work correctly but still fail if it takes forty seconds under normal traffic.

Black box, white box, and grey box testing use different levels of internal system knowledge.

• Black box testing checks behavior through interfaces using requirements and input-output analysis without seeing the code.
• White box testing uses code structure to cover branches and paths, commonly in developer unit tests.
• Grey box testing uses partial knowledge of architecture, database schemas, or API contracts to design better scenarios.

Testing levels find different defects at different system scopes.

• Unit tests isolate functions and catch logic errors quickly and cheaply.
• Integration tests check components together and expose contract or data-format mismatches.
• System and end-to-end tests cover complete flows, but lower-level tests are faster and more stable, so the test pyramid keeps most checks there.

Verification checks whether the product was built correctly, while validation checks whether the right product was built.

• Verification compares the implementation with specifications through reviews and requirement-based testing.
• Validation confirms that the result solves the user's real problem.
• A feature may match a flawed specification perfectly and therefore pass verification but fail validation.

Retesting confirms a specific fix, while regression testing checks its wider impact.

• Retesting repeats the exact scenario that previously failed on the updated build.
• Regression testing checks that the fix or another change did not break related existing behavior.
• The usual order is to confirm the fix first and then test the surrounding area.

Exploratory testing combines learning, test design, and execution in one structured session.

• The tester follows findings instead of a fixed script and varies paths and data as new clues appear.
• It is valuable when documentation is limited, time is short, or scripted cases are outdated.
• It is not random clicking because a good session has a charter, a time box, and coverage notes.

I turn each testable requirement into a traceable set of scenarios.

• I extract testable statements and cover positive flows, negative and boundary inputs, and state transitions.
• I clarify ambiguities with the analyst or developer instead of embedding assumptions in test cases.
• I link every case to its requirement so coverage gaps and obsolete orphan cases remain visible.

The right documentation depth depends on complexity, risk, and team context.

• A checklist is enough for simple features, experienced teams, smoke passes, or work where speed matters most.
• Full test cases suit complex flows, compliance needs, new-tester onboarding, and scenarios that must remain reproducible.
• Mature teams combine both formats instead of documenting every check at maximum detail.

Testing can reveal defects but cannot prove that no defects exist.

• Exhaustively checking every input, state, and timing combination is impossible in a real system.
• Testers prioritize by risk and use techniques such as equivalence partitioning to reduce the input space.
• The accurate conclusion is that no defects were found in the covered areas under the tested conditions.

An error, a defect, and a failure are stages in a cause-and-effect chain.

• An error is a human mistake, such as misunderstanding a specification.
• That mistake can create a defect in the product's code or design.
• A failure occurs when the defect is executed and causes incorrect behavior, although some defects may stay hidden in unused code.

A bug moves through reporting, triage, resolution, verification, and closure.

• After being reported as new, it is triaged, assigned, rejected, marked as a duplicate, or deferred.
• A developer fixes it and marks it resolved, then QA retests it on the updated build.
• A successful retest leads to verification and closure; a failed one reopens the bug, while rejected and deferred states preserve decisions.

Severity describes technical impact, while priority describes business urgency.

• A crash in a rarely used legacy report can have high severity but low priority.
• A company-name typo on the landing page can have low severity but high priority.
• QA often assesses severity, while a product owner or lead sets priority using business context.

A good bug report lets a developer reproduce the problem without follow-up questions.

• It includes a specific title, minimal numbered steps, and clear expected and actual results.
• It records the environment, including build version, browser, operating system, and test account.
• Screenshots, videos, logs, and API requests and responses provide evidence and speed up diagnosis.

I report an intermittent bug with all available evidence and then search systematically for its trigger.

• I record the exact time, account, environment, screenshots, logs, and reproduction rate.
• I vary timing, network conditions, concurrent sessions, data state, and cache to isolate a pattern.
• I attach server logs from the failure window when available because intermittent issues may be race conditions that appear at scale.