I have a feature that is currently blocked, and there are some test cases from other features that depend on it. Should I continue testing or stop until the blocker is resolved? How can I determine that I should stop testing because of this blocker? And is it acceptable to stop testing since there are dependent test cases?
2 Likes
I would suggest testing all features that are currently testable and marking the rest of the test cases—those related to blocked features and any dependent ones—as blocked.
Once the blocked feature becomes available, you can execute the test cases for that specific feature as well as the related dependent ones. After the fix is in place, you should also perform a regression check to ensure the new fix hasn’t impacted any existing functionality.
Example from the travel domain:
Suppose you’re working on hotel and flight bookings, and the available payment types are 3DS, PayPal, and card payment.
Now, if the PayPal feature is blocked, it doesn’t mean that all testing must stop. You don’t need to wait for PayPal to be fixed before continuing. Instead, you can still test the following combinations:
-
Hotel booking with 3DS payment
-
Hotel booking with card payment
-
Flight booking with 3DS payment
-
Flight booking with card payment
This way, you save time and can quickly identify if there are any issues once the PayPal fix is delivered.
As testers, it’s important to use our judgment to find the best possible workarounds and make the most effective use of time, even when some features are blocked.
3 Likes
I will also emphasise, test whats testable, mark rest a BLOCKED also
- Highlight or link why these test cases are blocked
- Enquire for the resolution / timeline
Once they are unblock, you need to do regression + testing as well to make sure everything is intact!
Depending upon the time constraint + team size as well, if there is enough time and resolution is timely and near, I wont test it at all, I will wait for entire feature to be available to save me retest whats I already had tested. But its always better to use your judgements and read the current situation! 
2 Likes
Great to see you here.
Regarding your question, encountering blockers is a common part of every tester’s workflow. You don’t necessarily need to halt all testing for a single blocked feature. Here are some practical approaches:
Work on tests that can be done independently Other features or test cases that are not negatively affected by the blocker should be completed, ensuring that your time is used productively.
Clearly track blocked tests Maintain a record of which test cases are affected and why. This gives stakeholders a clear understanding of the impact.
Follow up with your team Inform developers and project managers about the blocker and its impact on testing schedules and scope. They may be able to suggest a workaround or solution.
Change priorities you could do some exploratory tests, risk assessment, or enhancements to the test environment while on hold.
And no, it is not a problem to cease dependent testing when the tests stop having meaning due to the blocker. It is important to communicate the situation to the team so that everyone is aware of the risk and the gaps in coverage.
You are not the only one in this situation everyday testing comes with its share of blockers, and properly managing them is a significant aspect of testing.