I’m not sure memorizing the keystrokes is great for QA.
I don’t think those who do it regularly, can prevent themselves from learning it though, and if I’m going to knock off a few installs on our testing checklist in a day, it’s pretty much guaranteed I’ll be in ‘automatic’ mode on most installs, but I try and ensure I’m slow & careful on at least one.
I see a lot of support posts (askubu, UF, etc) with users bring tripped up regularly on installs, and I generally try and pretend I’m that user (or my interpretation of the skill level I read in their support post) during a QA-test install maybe once a week (when I’m doing QA; ie. closer to release time). It’s how you can discover some ditherer types of bugs, which seem to exist in all installers (it’s well known in ubiquity), and even if the bugs are never fully prevented, those bug reports come in handy so I can recognize when I see a user reporting issues in support, or in a filed bug.
I have systems that contain some of my own data (focal & jammy now) that I don’t perform upgrades on, but will re-install the OS as part of QA (install using existing partition type of install) ~weekly which achieves a system package upgrade, and validates the installer & daily is all good for what will now be 20.04.5 & 22.04.1 daily ISOs currently. My manually installed packages I’ll check get auto-reinstalled, my data remains etc. As those are installs I’m doing regularly, it’s hard not to flip into automatic mode for them, but they are on systems I value, and contain data I don’t wish to lose (unlike other boxes I only use in QA where I can be less careful) which can help, but yeah being automatic is harder to prevent.