Sometimes when I'm testing I run into scenarios where I'm faced with the decision if I should execute a test or not.
There can be many reasons why I'm hesitant about executing that test, but usually it comes down to the test taking to much time in some form or another. Or I'm unfamiliar with some of the prerequisites  needed for the test case to be executed and it will take some time to learn about that prerequisite, thereby translating into "taking to much time".

At times like these when I'm pondering on whether it's worth it or not to execute the test, I fall back on the abbreviation that I came up with myself: MORT

MORT:   Money vs. Opportunity vs. Risk vs. Time

Money:
It is going to cost money for the stakeholders in some form or another if I spend time on executing this test. Time will be spent preparing the test. Time will be spent if I have to learn about something new, and time will be spent if I for instance have to prepare new test data.
The things above are notoriously hard to estimate in actual money, and can be considered "soft" factors. Quite frankly it is almost always not worth the effort of trying to quantify the cost (money) and just settle with small/medium/large.
But in some cases I might need to buy something for actual money, like special hardware, special software etc. And in those cases we have to have a figure on what it will cost on top of the "softer" money-aspects above.

Opportunity:
There might also be an opportunity involved in me performing the test.
The opportunity that I learn a new skill which I can apply in the future for coming tests, and thus becoming a better tester and asset for my employer. Something I can even spread further within the organisation, thus increasing the value of the opportunity.
There might be the opportunity to create new unique test data that can be reused by other testers and developers within my organisation.
And being a test developer there is quite a few times when I see tests I want to perform that will require some coding on my part for a test tool, a test tool that could be reused by me or others around me.
Buying new hardware is of course something that should be seen as an investment for the future, and as such an opportunity to improve our testing going forward.
Never underestimate the opportunity to improve the way we are working long-term within an organisation.

Risk:
What is the risk if I don't run this test and gather the information it answers?
The most obvious risk is that we don't find potential bugs hidden in the software that then get released to the customer.
There could be contractual risks, or perhaps the risk of our software not passing standardization criteria's.
There is the risk that I'm not uncovering potential new information that could be communicated within our organisation. Or that people have a preconception on how they think the software behaves.

Time:
This aspect is usually the most tricky thing to "overcome" or "pass" in MORT since we are almost always working within time limits.
If I'm in the middle of a project, then there is usually enough time to motivate me running the test, or investing the time to learn about something new that I need.
But if the release date is drawing nearer, then I might not have as much time left to spend on this and there might be a lot of other easier/faster test activities for me to perform.
But never forget that even though we might not "have enough time", the factors "opportunity" and "risk" (especially risk) might make it impossible and even unprofessional for you to not take the time to perform this test, and by performing the test thereby risking not executing other test cases, or even delaying the date when we are "finished testing", although Michael Bolton's view on this is by far the best.

There are of course many other examples for the aspects above in MORT, but these are some of the more common ones I run into.
Rember: Have the courage to start taking these decisions more for yourself since you know the context best (thanks Aleksis Tulonen/@al3ksis for reminding me).

Where is Value?
Of course over the years since I started doing more and more "agile testing" I should perhaps have added a "V" as well for "Value to the customer", but then there wouldn't be a (not so subtle) homage to T. Pratchett ;-)