Interview Insights · QA Tester
Why QA Tester Candidates Freeze on the Simplest Questions
Quick summary — QA basics
Candidates freeze on simple QA questions because they memorised a sentence instead of understanding a picture. Basic questions feel dangerous because everyone expects you to know them, so any hesitation feels like failure. Under that pressure, a memorised sentence disappears. What does not disappear is a concrete example you understand. If you can picture a logo misspelled on the home page and a crash on a rarely used settings screen, you can explain severity and priority without remembering any textbook line.
In this guide you will learn:
- Why basic questions cause more freezes than hard ones
- The define, example, contrast method for any QA term
- Crisp answers for six common basics, each with an example
- How to recover when your mind goes blank on a basic
- A flashcard set to practise out loud
SECTION 01Why the easiest QA questions cause the hardest freezes
With a hard scenario question, nobody expects a perfect answer, so candidates relax and think. With a basic question, the stakes feel higher: 'if I miss this, they will think I know nothing'. That pressure triggers the freeze. The memorised sentence slips, and the candidate goes silent or mixes up the two terms.
The fix is not to memorise harder. It is to attach each concept to a picture you understand. Pictures survive pressure much better than sentences do. Here is how the freeze typically happens and what it looks like to me.
| What happens in your head | What I see | What I conclude | Better approach |
|---|---|---|---|
| Trying to recall the exact textbook line | Pause, eyes up, then a jumbled sentence | Memorised, not understood | Start from an example instead |
| Worrying the question is a trick | Over-complicated answer | Nervous, maybe unsure | Answer simply; add depth if asked |
| Mixing up two similar terms | Swapped definitions | Concepts not separated | Always give a contrast sentence |
| Blanking completely | Silence | Unknown, so I probe again | Say the example you remember first |
Me: What is the difference between severity and priority?
Candidate: Severity is... the degree of impact... that a
defect has on the... development or operation of a
component. And priority is... the order... sorry, I
know this. Priority is the importance... I think
severity is decided by developers?
(Half a textbook line, then a wrong detail.)Me: What is the difference between severity and priority?
Candidate: Severity is how badly the bug affects the system.
Priority is how soon it needs to be fixed.
Example: the company name is misspelled on the home page.
Low severity, nothing breaks, but high priority because
every customer sees it.
The opposite: the app crashes when exporting a report in
an old format almost nobody uses. High severity, but it
can wait, so lower priority.
Usually the tester suggests severity, and the product owner
or lead sets priority.The understood answer has no textbook wording at all, and it is far stronger. The two examples do the work, and the last line about who sets each one answers the most common follow-up before it is asked.
SECTION 02Six QA basics answered the calm way
These are the basics I hear candidates freeze on most often. For each one, learn the picture, not the sentence. Use the shape: define each term in one plain line, give an example from a real kind of app, and finish with one contrast sentence.
Practise saying these out loud, not just reading them. Speaking is a different skill from recognising, and interviews only test speaking.
| Pair | Plain definition | Example | Contrast sentence |
|---|---|---|---|
| Retesting vs regression | Retest: check the fixed bug. Regression: check nothing else broke | Fix coupon bug, retest coupon, regress checkout and cart | Retest looks at the fix; regression looks around it |
| Smoke vs sanity | Smoke: is the build stable enough to test? Sanity: does this fix work at a glance? | Smoke: login, home, search open. Sanity: changed tax rule shows right total | Smoke is broad and shallow; sanity is narrow and focused |
| Verification vs validation | Verification: are we building it right? Validation: are we building the right thing? | Review spec and test cases vs user tries the real flow | Verification checks against specs; validation against user needs |
| Bug vs defect vs failure | Defect or bug: a flaw in the product. Failure: the visible wrong behaviour | Wrong tax formula in code shows a wrong total to the user | A defect can exist without a failure until that code runs |
FRONT: Retesting vs regression
BACK: Retest = run the failed case again after the fix.
Regression = check that the fix did not break
anything around it.
Example: fix coupon -> retest coupon,
regress cart, checkout, invoices.
FRONT: Smoke vs sanity
BACK: Smoke = new build, broad and shallow: does it open,
log in, load main pages?
Sanity = after a small change, narrow check that
the change works before deeper testing.
FRONT: Verification vs validation
BACK: Verification = reviews, walkthroughs, spec checks.
Validation = actually running it against user needs.A COMMON BUG LIFE CYCLE (names vary by tool)
New -> Assigned -> Open / In Progress -> Fixed
-> Ready for Retest -> Retest
-> Verified -> Closed
-> Reopened (if still failing) -> Assigned ...
Side exits from triage:
Rejected / Not a bug
Duplicate
Deferred (valid, fixed in a later release)
Cannot reproduce
Say it as a story:
"I log it as New, the lead assigns it, the developer fixes
it, I retest. If it passes I close it, if not I reopen
it with fresh evidence."When you explain the bug life cycle, mention that state names differ between tools. Saying 'in our Jira workflow it was called Ready for QA' shows you have used a real tool, and it protects you if the interviewer's version uses different names.
SECTION 03What to do when your mind goes blank on a basic
Even with practice, a blank can happen. The worst response is silence followed by 'sorry, I forgot'. The better response is to start from whatever piece you do remember, usually an example, and build outward. Interviewers are far more forgiving of a slow, reasoned answer than of a fast, wrong one.
In Uncodemy mock interviews, one exercise is to have a trainer fire basics rapidly so candidates practise recovering from blanks in a safe setting. You can do a version of this at home with a friend and a list of terms.
| Blank moment | Recovery line | Why it works | Then do this |
|---|---|---|---|
| Forgot both definitions | Let me start with an example I know | Examples come back faster than words | Describe the example, then name the terms |
| Unsure which term is which | I will describe both and check with you | Shows honesty and keeps talking | Give both meanings, ask if the labels match |
| Term you truly do not know | I have not used that term, can I guess from context? | Honest and shows reasoning | Reason aloud, accept correction |
| Panic after a mistake | Let me correct that | Self-correction is a strong signal | Restate cleanly and move on |
Me: What is the difference between smoke and sanity testing?
Candidate: (pause) Let me start with what I do in practice.
When a new build comes, I first check the app opens, login
works and main pages load. If that fails, I reject the
build. I believe that is smoke testing.
When a developer fixes something small, like a tax rule,
I quickly check just that change before going deeper.
That is sanity testing.
So smoke is broad and shallow on a build, sanity is narrow
on a change.RAPID-FIRE PRACTICE (friend reads, you answer in 20 s)
- Severity vs priority
- Retesting vs regression
- Smoke vs sanity
- Verification vs validation
- Defect vs failure
- Test case vs test scenario
- Positive vs negative testing
- Black-box vs white-box testing
- Functional vs non-functional testing
- Test plan vs test strategy
Rule: every answer must include an example.
No example = try again.Notice that the recovery example arrives at a correct answer even though the candidate started from a blank. Starting with 'what I do in practice' worked because they had actually done it. That is the deeper lesson: hands-on practice protects you from freezes.
SECTION 04Seven-evening plan to stop freezing on QA basics
Spend about twenty minutes an evening. By the end, each basic will have a picture attached, and you will have practised saying it under mild pressure.
EVENING 1 Severity vs priority: write 2 examples each way
EVENING 2 Retesting vs regression: use a real app you know
EVENING 3 Smoke vs sanity: describe a new-build check
EVENING 4 Verification vs validation, defect vs failure
EVENING 5 Bug life cycle: draw it, then tell it as a story
EVENING 6 Rapid-fire with a friend, 20 s per answer
EVENING 7 Record yourself on all of them, play back
Each evening: say every answer aloud 3 times.DEFINE -> EXAMPLE -> CONTRAST
Term A is ______________________ (one plain line)
Term B is ______________________ (one plain line)
For example, in a ____________ app,
_________________________________________ (A)
_________________________________________ (B)
So the difference is ____________________ (one line)
Optional: who decides / when it is used: ____________AFTER RECORDING, CHECK EACH ANSWER
[ ] Started within 5 seconds
[ ] Used my own words, not textbook phrasing
[ ] Gave at least one concrete example
[ ] Ended with a contrast sentence
[ ] Under 45 seconds
[ ] No swapped terms
Any answer missing 2+ ticks goes back on tomorrow's list.SECTION 05Habits that make basic questions feel easy
These habits replace panic with a simple routine you can trust.
- Learn pictures, not sentences — Tie every term to a specific bug or screen you can imagine clearly. Pictures survive nerves.
- Start with what you do — 'In practice, when a new build arrives, I...' is an easy way to begin and often leads you straight to the answer.
- Keep it short — Basic questions want basic answers. Give the definition, an example and a contrast, then stop.
- Expect the follow-up — For severity and priority, the next question is usually who decides. Prepare that line in advance.
- Practise speaking, not reading — Reading notes builds recognition. Only saying answers aloud builds the recall you need in the room.
SECTION 06Interview Q&A — QA basics
Q1What is the difference between severity and priority, with an example?
Severity is how badly a bug affects the system, and priority is how soon it should be fixed. A misspelled company name on the home page is low severity but high priority because every user sees it. A crash in a rarely used export is high severity but may be lower priority. Testers usually suggest severity, and the lead or product owner sets priority.
Q2What is the difference between retesting and regression testing?
Retesting means running the failed test again after a fix to confirm the bug is gone. Regression testing means checking that the fix or change did not break other parts of the application. For example, after fixing a coupon bug I retest the coupon and run regression on cart, checkout and invoices.
Q3What is the difference between smoke testing and sanity testing?
Smoke testing is a broad, shallow check on a new build to see whether it is stable enough for testing, such as login and main pages loading. Sanity testing is a narrow, quick check after a small change or fix to confirm that change works before deeper testing.
Q4What is the difference between verification and validation?
Verification checks that we are building the product right, against specifications, using reviews, walkthroughs and inspections. Validation checks that we are building the right product for users, usually by running and testing the actual software against their needs.
Q5Explain the bug life cycle.
A bug is logged as New, then assigned to a developer, who works on it and marks it Fixed. The tester retests it. If it passes, it is Verified and Closed; if not, it is Reopened. During triage it may also be marked Duplicate, Rejected, Deferred or Cannot Reproduce. State names vary by tool.
SECTION 07Test yourself — QA basics quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
Why do I forget simple answers in interviews?
Pressure makes memorised sentences hard to recall, especially for questions you feel you must get right. Linking each concept to a concrete example and practising answers aloud makes recall much more reliable under stress.
What are the most common basic QA interview questions?
Severity vs priority, retesting vs regression, smoke vs sanity, verification vs validation, bug life cycle, test case vs test scenario, black-box vs white-box testing, and functional vs non-functional testing are asked very often.
Who decides bug severity and priority?
In most teams, the tester suggests severity based on impact, and priority is set by the product owner, project manager or lead based on business needs. Practices differ, so mention how it worked in your project.
Is it okay to give an example instead of a definition in an interview?
Give both if you can, but if you blank on the definition, starting with an example is a good recovery. A clear example often shows understanding better than a textbook line.
How should I prepare QA basics before an interview?
Make flashcards with a plain definition, an example and a contrast sentence for each pair of terms. Practise saying them aloud, ask a friend to quiz you rapidly, and record yourself to check you start quickly and stay under a minute.
Does Uncodemy help with QA Tester interview answers?
Yes. Uncodemy's Software Testing Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise QA Tester interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Know the basics so well they never freeze you
Our Software Testing Training Course builds strong testing fundamentals through hands-on projects, so every basic concept is tied to something you have actually done.
Talk to a counsellor for current fees- Testing fundamentals
- Hands-on live projects
- Bug tracking practice
- Rapid-fire mock rounds