Investigation is more valuable than recall
A junior engineer does not need instant answers for every product. You need a repeatable way to turn uncertainty into evidence.
State the question, collect relevant facts, run a controlled check, and explain the remaining uncertainty. This pattern works in interviews and delivery work.
The ten questions below are prompts, not a universal checklist. Prioritize them according to the feature and its failure consequences.
Ask who can act and what can change
First, who is the user and what permissions should apply? Second, which state must exist before the action starts? Third, which business rule decides success?
Fourth, what data enters the system and where is it stored? Fifth, which service or external provider participates in the result?
Use an actor, state, rule, data, and dependency map. It exposes assumptions before you produce a long list of test cases.
Ask how failure becomes visible
Sixth, what does the user see when part of the workflow fails? Seventh, which logs, requests, events, or database records can confirm the cause?
Eighth, can the user retry safely? Ninth, can concurrent actions create duplication or stale state? Tenth, what must the team monitor after release?
Separate observation from interpretation. A spinner that does not stop is an observation. A failed payment callback is a hypothesis until evidence supports it.
Practice on one ordinary workflow
Choose registration, password recovery, search, or checkout in an authorized practice product. Investigate each question with browser tools and available documentation.
Write a one-page note with assumptions, evidence, findings, and open risks. Mark questions that the current environment cannot answer.
Completion means another person can follow your reasoning and reproduce the important observation. Quantity of test cases is not the target.