Should I test this? Decision tool

NobodyNobody but you. The code runs on your machine or you throw it away.My teamYour team or your company. A failure slows people down. No customer sees it.UsersCustomers see errors, wrong data, or a broken feature.MoneyA failure loses money directly: wrong charges, lost orders, wrong invoices, refunds.Safety or lawA failure can harm a person, expose personal data, or break a law or a contract.

OnceThe code runs one time, or you write it once and never change it.RarelyThe code changes a few times a year.RegularlyThe code changes about once a month.ConstantlyThe code changes in most weeks.

ImmediatelyThe person who makes the change sees the failure at once: the build fails, the app does not start, or the error is on the screen.Same daySomeone notices within a day: an alert, an error report, or a user complaint.EventuallySomeone notices after days or weeks, usually by chance.NeverNobody notices until the damage is done, or nobody notices at all. The output looks correct, or the failure is silent.

TrivialYou revert or redeploy and the problem is gone. Nothing stays behind.With effortRollback works, but it takes work: a hotfix, a data repair script, or replies to support tickets.CostlyRollback leaves lasting damage: data that you repair by hand, refunds, lost trust, or a new app store release.ImpossibleYou cannot undo the damage: emails are sent, data is deleted without a backup, secrets are public, money is paid out.

TrivialThe test takes minutes to write and seldom breaks when the code changes.ModerateThe test takes about an hour to write and needs updates when the behaviour changes.HeavyThe test takes days to build. It needs fixtures, environments, devices, or checks for output that is not the same each time. It breaks often.ProhibitiveThe test costs more than the feature. The setup does not exist, you cannot reproduce the conditions, or the test needs its own team.

Should I test this?

Result