But it's also programming as you have to study outputs to ensure they're correct. Some (it seems many) don't do this, and then their outputs usually aren't correct.
In my experience, QA is something like ensuring it responds correctly to input. This is similar, but not the same as code review. I would more liken QA to dynamic review rather than static. Note though that code review can still be a form of QA. (Formal proofing especially.)
That’s what QA departments in software companies do. In many other contexts they examine things produced by machines to ensure they meet the specs and functional requirements for that piece, and if not, either adjust it, have someone else adjust it, or have the adjusted machine spit out another one. They might design tests, fixtures to measure things, etc etc etc but they do not make the things directly.
To be fair, ensuring that machines produce the correct outputs (even by making someone else fix it) is still the kind of process I'm talking about. After all, that's also how it works in software.
It depends on what the machines are supposed to do. I’ve never worked in software QA, but worked as a developer for over a decade and currently work in manufacturing. Is mass-manufacturing totally different? Sure. QA engineers in small high-complexity single-run prototyping shops? It’s not much different.