21. What information should a good bug report contain?
Answer:
A good defect report generally includes:
- 21. What information should a good bug report contain?
- 22. Developer says, “It works on my machine.” What will you do?
- 23. What will you do if the requirement is unclear?
- 24. What will you do if there are no requirements or documentation?
- 25. You have only 2 hours for testing. What will you do?
- 26. What is Risk-Based Testing?
- 27. You found a critical bug just before production. What will you do?
- 28. What if a production bug is reported by a customer?
- 29. How would you test a login page?
- 30. How would you test an ATM?
- Defect ID
- Clear title
- Environment
- Preconditions
- Steps to reproduce
- Expected result
- Actual result
- Severity
- Priority
- Screenshots/videos
- Logs if applicable
- Test data
Strong interview statement:
“My goal is to make the defect reproducible without requiring multiple clarification messages.”
22. Developer says, “It works on my machine.” What will you do?
How to answer:
Don’t argue.
Say:
“First, I would verify the issue again and compare the environments. I would provide the exact steps, test data, browser/device, build version and evidence such as screenshots or videos. If required, I would reproduce the issue together with the developer and involve the BA or Product Owner if the expected behavior is unclear.”
This shows professional communication and debugging mindset.
23. What will you do if the requirement is unclear?
Answer:
“I would not make assumptions immediately. I would identify the ambiguity, document my question and discuss it with the BA, Product Owner or relevant stakeholder.”
You can add:
“Clarifying requirements early can prevent incorrect test cases and reduce rework later.”
24. What will you do if there are no requirements or documentation?
Answer:
“I would first identify available sources of information such as existing application behavior, business users, developers, previous releases, support tickets and related documentation. I would then clarify the expected behavior with stakeholders before finalizing my testing approach.”
25. You have only 2 hours for testing. What will you do?
⭐ Scenario-Based Question
Don’t say:
“I will test everything quickly.”
Instead:
“I would perform risk-based testing. I would first identify critical business workflows, recently changed functionality and areas with a history of defects. I would execute smoke testing first and then focus the remaining time on high-risk scenarios.”
Priority:
Critical functionality → Recent changes → High-risk areas → Secondary functionality
26. What is Risk-Based Testing?
Answer:
“Risk-based testing means prioritizing testing based on the probability and impact of potential failures.”
Example:
In a banking application:
Money transfer would generally receive higher testing priority than a profile-picture update because the business impact is much higher.
27. You found a critical bug just before production. What will you do?
Answer:
“First, I would reproduce and confirm the defect. Then I would immediately communicate its impact to the relevant stakeholders, raise the defect with appropriate severity and priority, provide evidence, and discuss the release risk with the team. The final release decision should be based on the organization’s release process and risk assessment.”
Important:
Don’t say:
“I will stop production myself.”
QA should communicate the risk and support the release decision, unless the organization’s process gives QA explicit release authority.
28. What if a production bug is reported by a customer?
Answer:
“I would first understand the customer’s exact scenario, environment, account/data conditions and steps. Then I would try to reproduce it in an appropriate environment, assess the impact and severity, and work with the development and product teams to identify the root cause and resolution.”
29. How would you test a login page?
Answer:
Don’t only list positive and negative cases.
Structure your answer into categories.
Functional
- Valid username/password
- Invalid username/password
- Blank fields
- Password masking
- Remember me
- Logout
Boundary/negative
- Maximum username length
- Maximum password length
- Special characters
- SQL injection strings
- Multiple failed attempts
UI/Usability
- Alignment
- Error messages
- Tab order
- Responsive design
Compatibility
- Chrome
- Firefox
- Edge
- Mobile browsers
This structured approach makes your answer stronger.
30. How would you test an ATM?
Answer:
Break it into workflows.
Card
- Valid card
- Expired card
- Blocked card
- Damaged card
PIN
- Correct PIN
- Incorrect PIN
- Multiple incorrect attempts
Withdrawal
- Valid amount
- Insufficient balance
- Daily limit
- Invalid amount
- Insufficient cash in ATM
Other
- Balance inquiry
- Mini statement
- Cash receipt
- Card retention
- Session timeout
Interview Tip:
Always show positive + negative + boundary + security + usability thinking.