I do not. Not because I’m feeling lucky, but at the company I work at it seems impossible. We rush through prototypes, ideas and so on so quickly that there is no time scheduled for testing at all. Also, most projects either survive only for a year or so (for business reasons, not technical), or get milked without any changes until they die.

The only testing I do is manual devtime testing (partial sandboxed deployments mostly) and then in production. If something breaks, we just fix it, having alert bots and excessive logs to investigate. Again, it is a business decision that is above me, not a simple overlook. It actually works well and brings no substantial downtime or losses.

I think the differences between us and a regular software company are that (1) we move very quickly, e.g. some prototypes take 1 day, not a “sprint”, (2) we only support “main” workflow. There are no rarely used features which could stay under the radar in production or fail only for a quiet subset of clients. There is no “product” or a “site” in a usual sense, only infra, scripts, bots, services, data exchange.

I also try to write code as dumb as possible and always crash-only, because refactoring is the worst enemy in this situation. When code is dumb, it is easy to move parts around and apply incremental changes to production without stopping everything for a week.