TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: What Killed Manual Software Testing?

19 点作者 towawy将近 4 年前
Hi HN! I&#x27;ve been working in software development for the past 8 years in different capacities, always for startups or SMBs. Recently I&#x27;ve been thinking about in-house manual software testing - or rather the lack thereof - I&#x27;ve experienced during that time. What gives? Did it ever exist in &quot;typical&quot; software development? If yes, where did it go?<p>Trying to push the issue in multiple projects I&#x27;ve been involved in has so far been met with resistance, calling it unnecessary. The usual counter arguments are:<p><pre><code> - Users will report bugs - The customer will test it before delivery (in case of contract work) - Automated testing </code></pre> Am I crazy to think the first two show a lack of care for quality of our software, and that effective automated testing is too hard (writing tests that catch a wide range of non-regression bugs is often more difficult than writing the actual program) and expensive for projects on limited budgets? Wouldn&#x27;t a few QA staff for testing on a regular basis be cheaper than the additional engineering hours for automation or support for unhappy customers?<p>The only time I&#x27;ve seen structured manual testing in practice was in a company where the entire development and IT staff was assigned to it the day before a planned release. It was grueling and linear work, but even that uncovered bugs that automation didn&#x27;t catch. At another project, the bugs seemed to become more severe after people in our company (especially outside engineering) stopped using it on a regular basis. Would hiring someone to do it as their job help? Are there resources out there to get started on setting manual QA up?

9 条评论

Jtsummers将近 4 年前
Nothing killed it, it still exists, but it&#x27;s being replaced by increasing automatic testing or (as you note) letting customers&#x2F;users do it for us.<p>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).<p>And yes, the first two (users will report bugs or customers will test contract work) are definite signs of a lack of professionalism.<p>Notable: Manual tests are almost universally integration tests. They are not unit tests. The dogma in the 00s&#x2F;10s was that unit tests were the best tests (fortunately this was not universally held and is dying down, unfortunately it&#x27;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&#x27;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&#x2F;organizations from pursuing them even when they have a way to automate the regression test suite after the fact.
dannypgh将近 4 年前
I think the separate QA before release step I bet was mostly killed by modern methods of software distribution. It&#x27;s true that automated testing is great, but let&#x27;s be real: automated tests have existed for many decades, and certainly overlapped with orgs having manual QA steps as part of release engineering.<p>If you&#x27;re duplicating floppies, minting CDs, DVDs and so forth it&#x27;s very expensive to make corrections. If you&#x27;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&#x27;s not the same expense associated with correction.<p>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.
khyryk将近 4 年前
I think that for the most part, reality killed it. Manual testing can slow down the development cycle considerably when bug fixes are streamed through, during system integration testing, etc. A small change can cause the manual testers to groan and declare that they have to recreate a dozen scenarios manually, which includes lots of data prep -- merging in a large change a short time before a planned release is even worse.<p>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&#x27;t indicate that it has failed without someone going through it again, and I suspect many orgs don&#x27;t want to do 20,000 manual tests during system integration.<p>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.
duped将近 4 年前
In my experience, manual QA is a symptom of bad engineering culture where engineers inherit large systems with poor test coverage. Automated testing is only hard when it isn&#x27;t considered from the beginning of the project.<p>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&#x27;t it automated? Is it doing something that fundamentally cannot be automated? If yes, you&#x27;re probably wrong - almost everything can be automated.<p>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.
评论 #27404068 未加载
detaro将近 4 年前
I suspect shorter delivery loops killed it. Manual QA is alive and well in projects with long release&#x2F;delivery times, like embedded products. Also things like partial rollouts aren&#x27;t possible there, but can be done if you can update deployed software very quickly.
评论 #27397136 未加载
softwaredoug将近 4 年前
I find a good human tester is a kind of &quot;expert user&quot; - someone with intimate knowledge of the domain, and knows how a product could help someone solve a problem. Arguably, this is the role of product management. They SHOULD be people from the domain regularly dogfooding the product. Unfortunately, a lot of product management really has become what used to be called &quot;project management&quot;: planning, budget etc. It can be less about what the product should do, depending on the specific product manager.
schwartzworld将近 4 年前
My first software job many years ago was manual software testing. I had a script I&#x27;d follow. Create a thing. Link it to a thing. The company paid me to do this.<p>Now that I&#x27;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?
评论 #27401675 未加载
throwaway088将近 4 年前
Spouse is QA in apple. Lots of manual testing going on. Just getting started on automation
UK-Al05将近 4 年前
Automated testing. Manual testing has now been confined to exploratory testing.