What do you mean by “blue screen”? Could you share a photo?
Also what hardware are you using?
I think automated testing beyond some basics becomes too inefficient pretty fast, and is simply (by logic) just never able to actually prevent the next bug…
Happen to stumble over an article that also suggest that’s not too far off, unfortunately.
So, the important thing seems to be to have an easy way for users interested in stability to test their own field-setup and to report bugs, and for maintainers to be able to withdraw a release again if a bug did slip though, in order to spare normal users (that only update stable-backports after a user field-testing delay) any known trouble (as well as the production machines of the users doing the testing, without their admins needing to be especially skilled to set up testing environments, pin packages etc. Installing and using with the delay disabled would already be enough to help with testing).
(against testing)
…some unforeseen interactions between the code for serialization and preparing a draft for editing. What test would have found this? The serialization code worked. The deserialization code worked. The code to prepare a draft worked. They even all worked together. Just not twice. Without apriori knowledge this could fail in this particular way, would I have tested it? Not likely…