答案 0 :(得分：5)
我是一个为政府客户开展大型项目的团队的一员。 第一阶段的第一个模块是一个巨大的灾难，团队没有管理，没有一个QA团队，开发人员没有动力更好地工作。相反，经理不停地喊叫并扣除没有加班的人的工资!!
客户，呵呵，不要问这个问题，他们真的很生气，但他们和我们公司呆在一起，因为他们知道没有人像我们一样理解业务。
那么解决方案是什么：
我们很快将交付系统的第4个模块，作为支持团队之一，我可以说它至少95％没有bug。这是我们的第一个模块的巨大跳跃。
今天，我们拥有一支强大的开发团队，合格的质量保证和专家漏洞修复工具。
很抱歉这个故事很长，但这就是我们的团队（在4个月内）向经理和客户证明我们是可靠的，并且只需要合适的环境。
答案 1 :(得分：4)
你无法证明它超出了测试的范围，除非有防弹规范（从未有过），否则测试永远不会证明任何超出明显的范围。
作为一个团队，您可以做的是以负责任的方式处理您的软件设计，而不是屈服于编写错误代码的诱惑，以取悦管理者，要求必要的资源和时间限制，并尽可能地处理整个过程作为工作的工艺。最好的文艺复兴时期的雕塑家都知道，没有人会看到后面的雕像放在大教堂的角落里，但仍然努力确保他们不会卖空自己。
作为一个团队，证明您的软件可靠的唯一方法是建立一个跟踪记录：从一开始就正确地做事，在实现新功能之前修复bug，永远不要放弃快速修复，并确保每个人对代码抱有同样的热情和尊重。
答案 2 :(得分：3)
在所有但无关紧要的情况下，您无法“证明”您的软件是正确的。
这是 U ser A cceptance T esting的作用：表明已达到可接受的有效性水平。
答案 3 :(得分：1)
我认为这会把车推到马前。这无异于一名步兵试图向将军解释什么是战斗演习以及为什么保护你的侧翼很重要。如果管理层无法区分质量代码和大泥浆之间的差异，那么你总是会最终提供一个大泥球。
不幸的是，完全不可能“证明”你的软件无故障工作（windows xp商业广告总是通过宣布“有史以来最安全的Windows版本”来惹恼我，这在发布时无法证明）。管理层需要设置和实施质量保证流程，并建立关于可交付产品的实际情况以及最终版本中可接受的错误或意外行为级别的指标。
也就是说，如果你是一个小团队并且在管理层提供很少投入的情况下制定自己的质量保证政策，我认为编写一个基本的质量保证流程并让管理层签署它是有利的。对于我们的网络应用程序，我们目前支持4个浏览器 - 管理层知道这一点 - 所以当应用程序在一些不起眼的手持浏览器中出现故障时，每个人都清楚地知道这不是我们设计应用程序支持的。当管理层决定开始测试x时，它还为雇用额外的开发或测试资源提供了良好的杠杆作用。
答案 4 :(得分：1)
正如比利乔尔曾经说过的那样，“这始终是一种信任问题。”
除了编写软件的人之外，您需要了解软件开发对所有人来说都是“黑魔法”。对于贵公司的其他人来说，许多倡议都会提高质量并降低长期和/或预算运行的风险，这一点并不明显（实际上，非常直观）。
关键是在发展和业务的其他部分之间建立一种信任，尊重的关系。你如何建立这种信任？好吧，这是那些敏感的人们问题之一......你需要进行一些实验。我经常使用以下工具：
如果您与您的经理有良好的关系，您可以建议他们阅读一些特定于软件开发的书籍，以便他们了解行业最佳实践。
此外，我会向你的老板指出，不允许你作为专业软件开发人员的行为正在伤害你的职业生涯。你真的想在某个地方工作，让你成长为专业而不是某个让你成为黑客的地方。