Exploratory Testing Reporting and Debriefing 2 — Questions and Answers
Question 1: What is 'test status reporting' in exploratory testing and why is it important?
- Regular communication of testing progress, key findings, and risk status to stakeholders throughout the testing cycle (Correct answer)
- Filing a formal test completion certificate at the end of each sprint
- Automatically generated reports from test management tools tracking scripted test execution
- Daily bug count reports submitted to the project manager
Correct answer: Regular communication of testing progress, key findings, and risk status to stakeholders throughout the testing cycle
Ongoing test status reporting keeps stakeholders informed of risk exposure and testing progress, enabling timely decisions about quality and release readiness.
Question 2: What is a 'test log' in the context of exploratory testing?
- A chronological record of testing activities, observations, and decisions made during a session (Correct answer)
- An automated output file from a CI/CD pipeline recording test execution results
- A formal document listing all test cases and their execution status
- A post-release audit trail of all bugs found and fixed before deployment
Correct answer: A chronological record of testing activities, observations, and decisions made during a session
A test log is an informal real-time record the tester maintains during a session to capture actions taken, anomalies noticed, and ideas generated.
Question 3: How should 'severity' and 'priority' be used when reporting bugs found during exploratory testing?
- Severity describes the technical impact of the bug; priority indicates how urgently it should be fixed based on business context (Correct answer)
- Severity and priority are identical terms and can be used interchangeably
- Priority is determined by the tester; severity is assigned by the developer who fixes it
- Severity applies only to performance bugs; priority applies only to functional defects
Correct answer: Severity describes the technical impact of the bug; priority indicates how urgently it should be fixed based on business context
A bug can be technically severe but low priority (rare edge case) or low severity but high priority (visible UI issue on a marketing page) — both attributes together guide fix decisions.
Question 4: What is the purpose of including 'test ideas generated but not executed' in a session report?
- To preserve exploration opportunities for future sessions so no valuable test idea is permanently lost (Correct answer)
- To prove the tester worked efficiently and had more ideas than time allowed
- To document scope creep that occurred during the session
- To justify requesting additional testing time from management
Correct answer: To preserve exploration opportunities for future sessions so no valuable test idea is permanently lost
Unexecuted test ideas represent potential future charters — capturing them ensures exploratory insights generated in one session can seed the next.
Question 5: What does a 'completion criterion' look like for exploratory testing, and how is it reported?
- Coverage of defined risk areas, session count targets achieved, and key quality questions answered are all reported as completion evidence (Correct answer)
- Exactly 100% of scripted test cases executed with a defined pass rate
- Zero open defects in the bug tracking system at the end of the testing cycle
- A fixed calendar date beyond which no more testing sessions will be run
Correct answer: Coverage of defined risk areas, session count targets achieved, and key quality questions answered are all reported as completion evidence
Exploratory completion criteria are qualitative and risk-based — testing ends when the team has sufficient confidence in the product's quality for the target use cases.
Question 6: How should exploratory testers handle 'intermittent bugs' when writing their reports?
- Document all reproduction attempts, conditions observed, and frequency, even if consistent steps cannot be confirmed (Correct answer)
- Only report bugs that can be reproduced on demand; discard intermittent findings
- Mark intermittent bugs as 'works as designed' until they can be reproduced three times consecutively
- Escalate intermittent bugs directly to the product owner without filing a formal report
Correct answer: Document all reproduction attempts, conditions observed, and frequency, even if consistent steps cannot be confirmed
Intermittent bugs can be serious even without guaranteed reproduction steps — documenting observed conditions and frequency gives developers useful context to investigate.
What is 'test status reporting' in exploratory testing and why is it important?