MENU
You are managing the testing for a bank card project. The testing was scheduled to take 10 weeks but by the time the software was developed only six weeks were available for testing Knowing there were a lot of risks with the software your team started testing activities early by overseeing code reviews, defining acceptance criteria by working with the users and by doing all lest creation prior to the code arriving
You are now three days away from the go-live date Your testing has mitigated all the high and medium risk items leaving only the low-risk elements unmitigated by testing You estimate it will take two weeks to manually test the low-risk elements At this point what should you do?
Context Analysis:
With limited time, testing all low-risk elements is not feasible. Depth testing on a representative low-risk element helps assess potential residual risk efficiently.
Evaluation of Options:
A . Automate the testing of the untested elements to ensure they are covered:
Incorrect. There isn't enough time to implement automation.
B . Block the go-live and start testing the low-risk elements immediately:
Incorrect. Blocking the release may not be acceptable if high and medium risks are already mitigated.
C . Transfer the risk of the untested low-risk items to the help desk:
Incorrect. While a potential fallback, it doesn't address residual risk proactively.
D . Select one of the low-risk elements and perform depth testing to assess the residual risk:
Correct. This provides quick insights into potential risks and helps make an informed go/no-go decision.
Syllabus Alignment:
ISTQB emphasizes prioritizing risk mitigation through targeted testing (TM-1.3.4).
ISTQB Advanced Level Test Management Syllabus (TM-1.3.4)