一些DO事实：除了单元测试和持续集成决策之外，还有哪些测试？
部分切勿事实
我读了很多关于所有这些不同类型的测试，但我目前没有看到写这些测试的理由。现在它看起来像一个普通开销没有任何价值（编辑：工作似乎没有增加很多值在此刻）。
问：是什么原因导致将力我们决定实现任何不该做的，哪些可以/应与工具来自动化/库？
“是什么原因导致将迫使我们决定实施任何不该做的”
没有。
没有什么会强迫你提高质量。许多人编写大多数时间都工作的代码，需要进行大量的仔细维护，而且用户大多都很满意。
这很好。有些人喜欢那样。很显然，既然您已经将导致高质量的实践描述为“没有任何价值的简单开销”，那么您就不需要这种质量水平，也无法预见需要这种质量水平。
这很好。
我不知道如何在未进行验收测试的情况下提供服务，但您已明确指出您没有进行验收测试。我无法理解这是如何工作的，但你似乎对此感到满意。
“哪些可以/应该自动化”
无。这是非常微不足道的东西。您已经在使用C＃的单元测试。单元测试，本质上是回归测试。在一定程度上，您可以使用相同的工具和框架进行验收测试的集成和元素。
有许多化妆类（蚂蚁般，行家状，scons的样）工具在夜间做的构建。
您不需要任何更多的自动化。
“持续集成”不需要工具，只是在往往不够，构建是从未断过检查的东西“没有任何价值平原开销”。
就我所关心的，每个开发人员都是测试人员，所以你们都是专职测试人员。许多人辩论“专职测试人员”的角色。我不知道这是什么意思。这似乎是一个不会产生交付代码的人。不知道你为什么会雇用这样的人。简单地让每个人对所有测试负责任是更有意义的。
作为用户代理人的“专职测试人员”总是事实上与业务分析师密切合作。由于这是它通常如此摆脱的方式，因此他们通常是初级业务分析师，侧重于验收测试。这是一件好事，因为他们有一个可交付成果：一个解决的业务问题。
我不确定测试人员提供什么。更多测试？更多的错误？如何让他们向用户负责，以确保业务问题是解决了？
没有力量你做任何这一点。
对不起。我刚刚更新了我的标签以包含C＃和.Net。如前所述。我们已经进行了单元测试（NUnit + Moq）。 – 2009-08-03 12:31:17
我不能完全肯定这是回答值得，但这里要考虑几件事情：
在某些时候质量可能成为其利润更大的驱动器，然后上市时间。然后你需要开始考虑具有更好的质量。
在这种情况发生之前，您应该考虑夜间构建，自动化回归测试等等，以便为您节省开发时间和精力。因此，每隔几个月花一点时间（比如说1周）来使您的开发（和发布）更高效（和乐趣）。
去的较大涨幅第一，.e.g自动设置为手动回归测试往往是很多更符合成本效益的自动化UI测试它的自我。
（还要考虑你找到乐趣，如果你喜欢编写自动化UI测试代码更然后手动回归测试，你可以做的自动化UI测试代码更好的工作。）
如果你没有（或不要太多）抱怨你的产品质量 - 放轻松，尽量不要放松你已有的水平。我想，两个人的团队可以负担得起。
但是，如果你问质量保证的改进，我认为你对产品质量有一些疑问。在这种情况下，我建议执行一些第三方评估，以确保您对质量的估计是正确的。
你已经上市了吗？或者它是一些“为一个客户”项目？
和你真正的问题是？ – 2009-08-03 11:13:54
我真正的问题是：我们什么时候会做任何不该做的事情？我在不同的测试中阅读了很多内容，但是我现在还没有看到这么做的意义？但是什么时候会是我们不得不写的时候。 – 2009-08-03 11:24:03
@Mitch：我重新说明了我的问题，使其更容易理解（希望）;） – 2009-08-03 11:26:10