您是否曾经参与过一个缺少重要质量保证措施的软件项目？
不只是你这样。很多公司和项目都存在这种情况。
即使他们知道有质量保证这回事，也知道我们应该这样做，但所有努力的结果通常都是在发布前进行大规模的质量保证冲刺。
紧张的时间只会让软件勉强运行。
当然，所有这些混乱都会在下一个发布周期重演。没有改进。
大学教了你什么
问题是，如果你学习的是计算机科学，你就不会学到如何确保软件的质量标准。大部分时间都花在算法、计算机如何工作、一些语言和概念的历史等方面。
此外，至少在我的学习中，有一个学期是关于项目管理方法和 Scrum 的。所有这些都很好，但质量保证却完全缺失。
忽视质量保证是一种耻辱，因为 90% 以上的学生在完成学业后都会在公司工作。必须及时交付没有错误的软件。
公司如何勉强按时交付
我见过无数次这样的情况。由于预算原因，质量保证标准和措施首先会被从项目中砍掉。这通常是在项目结束时计划好的，但如果开发需要更长的时间（这经常发生），或者出现范围蠕变（这总是会发生），就没有足够的时间进行质量保证了。
最终，我们只能进行绝对最少的非结构化测试，然后将一个墙壁脆弱的数字纸牌屋交付给客户。
在一些公司或团队中，有一定的质量保证标准。通常是团队中的资深成员为其他成员执行这些标准。他们很可能已经深刻认识到，没有质量保证，一切都会变得非常困难。不幸的是，即使制定了标准也是不够的。团队只是为了满足项目管理指标而编写测试的情况屡屡发生。
如何摆脱仓鼠轮
我花了很多年才积累起经验和信心，敢于直言项目中缺失的质量保证措施。
与管理者争论，度过发布前的紧要关头，处理失败的生产系统，寻找缺失的监控。这并不好玩。
对于管理人员无法直接看到的代码库或项目的其他改进（例如重构），情况也是类似的。
但对于质量保证部门来说，这总是特别困难，因为如果我们不采取任何措施，就永远也学不会如何正确地去做。
当单元测试通过但集成测试未通过时。只有大声疾呼，反复讨论，才能走出仓鼠轮的第一步。
如何做？
在编写新代码时，我没有使用 TDD，但我强烈建议在编写软件的同时编写测试。这是编写测试的最佳时机。
如果你在实现功能的同时编写测试，你就会发现代码的结构实际上是可测试的。
为现有软件编写测试常常会发现，特定代码的相互依赖性太强，或者违反了单一责任原则。
通过测试，你可以说明你理解了所需的行为，并确保一切工作都符合预期。这甚至可以说是一种代码文档。
（banq注：测试是一种设定你的程序的上下文，你的程序是在什么样的环境中运行，当然，这种上下文设想有时显得比较天真，这样的测试就浪费时间了，可能作者自己包括我们所有人都不知道如何交付高质量的软件，也许高质量软件不是在一次性交付中，而是在时间流式的很多次交付以后才可能）