Exploratory Testing Risk-Based Exploratory Testing 2 — Questions and Answers
Question 1: What is a 'risk heuristic' in exploratory testing?
- A rule of thumb that helps testers identify likely risk areas based on experience (Correct answer)
- A formal statistical risk model used by project managers
- A mandatory checklist of risks to evaluate before each session
- A tool that automatically scores the risk level of each feature
Correct answer: A rule of thumb that helps testers identify likely risk areas based on experience
Risk heuristics are experienced-based patterns (e.g., 'new code is riskier than stable code') that help testers locate likely problem areas.
Question 2: Why is recently changed code considered a higher testing risk during exploratory testing?
- Code changes introduce new defects and may break previously working behavior (Correct answer)
- New code is always written by junior developers
- Unchanged code is excluded from testing by policy
- Changed code is always deployed to production first
Correct answer: Code changes introduce new defects and may break previously working behavior
Every code change is an opportunity to introduce new defects or unintended side effects, making recently changed areas high-priority for exploration.
Question 3: How does exploratory testing complement formal risk analysis documents?
- It uncovers risks that were not anticipated in the formal analysis through live discovery (Correct answer)
- It replaces formal risk analysis by finding all risks empirically
- It validates that all documented risks are already fixed
- It provides quantitative risk scores to update the risk register
Correct answer: It uncovers risks that were not anticipated in the formal analysis through live discovery
Exploratory testing discovers emergent, unexpected risks during live exploration that static analysis documents often miss.
Question 4: What is 'residual risk' in the context of a testing project?
- The risk remaining after all planned testing has been completed (Correct answer)
- The risk introduced by the testing team's own actions
- The total number of unfixed defects at release
- The risk of test data being deleted after a session
Correct answer: The risk remaining after all planned testing has been completed
Residual risk is what remains after testing — the known unknowns and untested areas that are accepted by stakeholders at release.
Question 5: When resources are limited, how should a risk-based exploratory tester allocate session time?
- Spend the most time on high-likelihood, high-impact risk areas first (Correct answer)
- Divide time equally across all features regardless of risk
- Focus on the newest features exclusively
- Test only the features the test manager assigns
Correct answer: Spend the most time on high-likelihood, high-impact risk areas first
Limited time should be invested where testing value is highest — the areas where failure is both likely and impactful.
Question 6: What is a 'product risk' versus a 'project risk' in exploratory testing?
- Product risks are defects in the software; project risks are threats to the testing schedule or team (Correct answer)
- Product risks only affect the UI; project risks affect the backend
- They are interchangeable terms used in different organizations
- Product risks are tracked by testers; project risks are tracked by developers
Correct answer: Product risks are defects in the software; project risks are threats to the testing schedule or team
Product risks are quality risks (defects, security holes); project risks are management risks (delays, resource loss) that indirectly affect testing.
Exploratory Testing Risk-Based Exploratory Testing 2
What is a 'risk heuristic' in exploratory testing?