Ask HN: What Killed Manual Software Testing?

Automated testing is almost universally better, except that it misses out on the exploratory nature of manual testing. Many critical systems utilize automation + manual exploratory systems and convert discovered failures from manual testing into part of the regression test suite (which is increasingly moved towards automation over time).

And yes, the first two (users will report bugs or customers will test contract work) are definite signs of a lack of professionalism.

Notable: Manual tests are almost universally integration tests. They are not unit tests. The dogma in the 00s/10s was that unit tests were the best tests (fortunately this was not universally held and is dying down, unfortunately it's, in some circles, swinging the other way to oppose unit tests wholesale; baby with the bathwater). Unit tests are great tests, but they are not integration tests and it is the interaction between units where many issues arise. (This observation is not unique to software, it's true of most physical, electronic, and hybrid systems as well.) You need both kinds. Integration tests, manual ones especially, are expensive to execute and this discourages many companies/organizations from pursuing them even when they have a way to automate the regression test suite after the fact.

If you're duplicating floppies, minting CDs, DVDs and so forth it's very expensive to make corrections. If you're pushing remote updates and digital downloads, or just running the software as a service and making it available over the network (e.g. a website) there's not the same expense associated with correction.

These methods of distribution also let careful organizations release to a small things out to a fraction of users first, which can minimize the costs and risks associated with a bad software push as well.

Automated tests never get bored or tired, and they can run constantly or exactly when needed; manual testing depends on the mental state of the tester and how prone they are to making small mistakes in general -- a bad night can result in an error in a non-reversible manual step that destroys, say, 2 hours of prep work if detected early and 12 hours of total work if not, causing chaos and confusion in the dev team. A manual test doesn't indicate that it has failed without someone going through it again, and I suspect many orgs don't want to do 20,000 manual tests during system integration.

Automated tests generally survive team reogs, departures, and memory loss; unless manual test scripts are meticulously documented, they may lack implicit assumptions held as a result of working on the same system for 5 years.

A lot of manual QA is bad testing too. If you have a grueling and linear process to go through to test your software each release... why isn't it automated? Is it doing something that fundamentally cannot be automated? If yes, you're probably wrong - almost everything can be automated.

Humans need to be put in the loop when requirements are changing and problems need to be solved. Designing comprehensive testing systems may be the role of good QA, but actually running the tests by hand is not a great place to be regularly.

Now that I'm a dev, I could write a cypress test that would run through that entire script as part of CI, which means the mistakes would get caught before code is merged. How is that not preferable?