我们发现了什么
只有在别无选择时,你才会亲自这样做:我会在一天内手动完成自己编写的游戏 AccurateMisplaced 的回归测试(6 万行代码——非 AI),覆盖 3 种设备类型,而且远不止快乐路径测试和领域知识测试。我是自力更生创业,所以只能自己做;到目前为止,生产环境中没有任何 bug。我第一份工作很久以前就在 IBM uKernel 做 QA,因此有扎实的 QA 基础,所以也许我更能将思维区隔开来,但测试自己的代码并不理想。
- 来源:Hacker News(发现于 2026-09-04)
- 证据等级:D · 发现产品或需求信号,暂未获得可核验的商业证据。
- 商业模式:待核验
- 主题:独立产品
- 初筛评分:22.9/100 · 收录 1 次
证据,比故事更重要。
规则清洗与初筛,未经人工商业核验。原文语境、实际客户和付费情况仍需自行验证。
引用与数字披露
来源类型(原作者自述/第三方测算/媒体转引)需采集端标注,本版尚未落字段。
- 作者
- 未标注
- 抓取日期
- 来源类型
- 未标注
- 币种
- 未标注
- 口径
- 未标注
- 披露主体
- 未标注
- 披露日期
- 未标注
中文辅助译文(全文)
需求是意图,QA 是证明。我看到如今的 QA 存在着巨大的缺口。这种局面是如何形成的,我并不清楚。我一直埋头做自己的创业项目,没有意识到 QA 正在发生变化——至少在某些圈子里是这样的。众所周知,把 QA 交给编写代码的同一个人通常效果不佳。从心理学角度来说,这并非小事。要让写代码的人和做 QA 的人都能发挥出最佳水平,你几乎需要一种健康的竞争机制(但不能病态到失控)。除非你没有其他选择,否则不要自己测试自己写的代码:我为自己的自研游戏 AccurateMisplaced(6 万行代码,非 AI 生成)手动运行回归测试,一天覆盖 3 种设备类型,测试内容远不止正常路径测试和领域知识测试。我是自力更生,所以自己来做,目前生产环境零 bug;而且我第一份工作(IBM uKernel)时打下了扎实的 QA 基础,也许我更擅长把大脑分区处理,但测试自己的代码终归不是理想的方式。我觉得平均测试覆盖率糟糕透顶。这就是为什么我们看到那么多有缺陷的产品上线吗?什么时候开始,只要在生产环境修一修就可以被接受了?明明只要多花一点力气,就能在上线前保证更好的质量。我说这话针对的是完全缺失的安全测试、集成测试、核心逻辑测试、压力测试、内存与性能检查、韧性检查(用户可能会做出意想不到的操作——你的产品会崩塌还是依然坚挺?)、可扩展性测试等等。对于移动应用来说,布局测试本身就是一项高强度工作,考虑到如今窗口尺寸调整、分屏窗口、同一设备上的多个场景以及设备类型分布(你的应用可能会运行在各种设备上)的复杂情况。如果没人做负面测试,那你的代码就是脆弱的。这些不是产品领域层面的判断,而是技术层面的判断。
必须有人来测试,否则你就要承担在生产环境中才发现问题的风险。你还有基于业务/领域知识的测试,以及真正关乎用户同理心的 UX 测试。QA 是一项不容小觑的工作,尤其考虑到我们架构的复杂性和产品涉及的范围。对我而言,你的测试套件仍然是你打算提供质量的承诺/契约。一套经过深思熟虑的测试套件能够让写代码的 AI 保持负责。在智能体 AI 时代,QA 可能就是用心发布与混乱无序之间的唯一区别。Ms Gitanjali GulveSehgal AKA Gigi Sehgal 创始人 Gigi Sehgal LLC 加利福尼亚州南洛思阿尔托斯
译文由上游机器翻译生成,可能有误;判断请以英文原文为准。
英文原文(来源本站未改写)
Requirements are intentions, QA is the proof.I see massive gaps in QA out there.How did this come to be?I am not sure.I have been heads down on my own startups and didn't realize how QA was changing - at least in certain communities.It has been long known that handing QA to the same person who wrote the code is usually going to be ineffective.Psychologically, it is non-trivial.You almost need a healthy competitive setup ( not to psychotic levels ) to get the best out of those who write the code and those who QA the product.
You do this yourself, only if you have no other options: I run through my regression testing for my self-written game AccurateMisplaced manually ( 60K LoC - non AI ) in a day for 3 device types and it goes way beyond happy path testing and domain knowledge testing.I am bootstrapped so I do it myself, and have zero bugs in production so far, and I have a strong foundational background in QA from my first job ages ago ( IBM uKernel) so perhaps I am better able to compartmentalize my brain but it is not ideal to test your own code.I find average test coverage to be abysmal.Is this why we see so many broken products launched?
When did it become okay to just fix it in production, when a little extra effort can secure better quality pre launch?I am speaking of utter lack of security testing, integration testing, core logic testing, stress testing, memory and performance checks, resilience checks ( users may do unexpected things is your product going to fold or remain standing?) , scalability testing, etc.For Mobile Apps, layout testing itself is a peak activity given the modern sprawl of window resizing, split windows, multiple scenes on the same device and device idiom spread ( various devices your app may run on ) .If nobody is testing for the negative tests, then your code is vulnerable.
These are not Product domain judgments these are technical judgments.Somebody has to test for it else you run the risk of finding out in production.And you have your business/domain knowledge based tests, and UX testing which is really all about user empathy.QA is a non-trivial activity especially given the complexity of our architectures and our products' scope.To me, your test suite remains a promise/contract of the quality you intend to provide.A well thought out test suite keeps code-writing AI accountable.In the Agentic AI era, QA may be the only difference between mindful releases & chaos.Ms Gitanjali GulveSehgal AKA Gigi Sehgal Founder Gigi Sehgal LLC South Los Altos California
这条还缺什么证据?
下面每条都由本条已有字段推出(等级、理由、商业模式、来源次数、是否演示), 本站不生成推测性结论;通用验证方法放在方法论页。
- 可核验的收入或付费证据查官网定价页与付费口径;第三方数据源(如 GetLatka)只作旁证,需标注来源与时点。
- 商业模式未定确认按席位/按用量/授权还是开源托管版收费;开源项目另查 LICENSE 与是否存在付费版。
- 只有单一来源找一手站点或其他渠道是否重复出现同一产品;社区热帖数量不等于商业进展。
通用验证清单(谁有这个问题/谁愿意付费/一个人能交付哪一小步)见我们的筛选方法。