对任何软件产品来说，软件上线永远是一件大事。完全确保所有功能生效以及发布高质量软件给用户非常重要。不好的、不成熟的、不稳定的、难以使用的产品会引发重大经济损失，还会让用户对品牌本身失去信任。我们通常听到当软件符合上线标准时，测试就应该结束了。我们也听到软件缺陷必须被修复以达到软件上线标准。然而，这些都是伟大的冠冕堂皇的准则，太模糊了。更确切地说：多少比例的软件缺陷对软件上线来说是可接受的？你如何决

你曾经遇到过难以开始一件事情吗？我不是在谈论在冬季启动一辆汽车，而是一些工作，可能是一个新项目或一篇博客。启动新项目不容易。你还记得你曾经思考过，说过或听过下面的一些事情吗？“我还在计划这件事。”“我需要做更多的调查。”“我的想法还不够完美。”“我还不确定哪种方式最好。”症结这些片断有个共同点。最好的情况显示为犹豫不决，最坏的情况可能是分析瘫痪。这个情况（对某些点的思考和分析无法前进）并不少见。作

在上一篇文章里，我讨论了代码评审的效果。更确切地说，代码评审怎么通常没有效率。我提议用结对编程来解决代码评审的问题。事实上，结对工作完全不需要任何代码评审。对开发软件来说，和其他人一起工作是最有效的机制之一，在这篇文章里，我会说到为什么是这样。下面采用了和结对编程一样多的抱团编程，但是我只简单地讨论结对编程。为什么结对工作传统代码评审过程涉及两个角色：作者和评审者。结对编程把作者和评审者的工作融为

几年前，我的团队从瀑布模型转到敏捷模型，现在转到DevOps。对企业而言，在生产环境一天多次部署新软件，最具挑战性的转型问题之一是需要革新测试。在持续部署和集成的时代，没有太多时间让QA团队发现问题并踢给开发人员。因此在开发结束后，产品上线前去测试程序的时代已经过去了。在这段走向DevOps的旅程中，我想出了一个非常简单的框架，并且改变了我对测试的看法（然而我的主要使命是产品经理）。从功能测试角度

在我写这篇文章时，首先进入我脑海的是CemKaner的话-“最好的测试人员不是发现缺陷最多的人或者让最多程序员尴尬的人。最好的测试人员是让最多的缺陷得到修复的人。”那么-发现最多的缺陷和让最多的缺陷得到修复这两者之间的区别是什么？难道不是很明显记录在缺陷管理系统里的任何缺陷都应该被修复吗？答案是否定的。有很多因素比如推广产品的时间，日程表上完成项目的时间，开发在不切实际的紧张日程中工作等。迫使公司

QA角色-它到底是什么？我已经见到过好几次，那些打算用敏捷开发的公司将项目里做自动化测试的QA角色，仅仅视为一个瀑布模型的测试人员。我的意思是因项目需要做手动测试的人，也会看到测试代码（当然后者取决于很多因素）。在我看来，这种描述对我所认为的QA角色在广度和深度上是一种伤害。我经常花费相当多的时间跟客户解释这个角色的其他方面，以及每一个方面带给团队和产品的价值。这样解释了几次之后，我发现做一张（只

测试人员到底应该做什么？我和我的团队刚刚进行了一场头脑风暴。许多答案跳出来了：应该测试应该全面测试应该不漏掉任何缺陷应该理解应用程序应该尝试中断应用程序好吧，但是我认为“有质量”才能使得一名测试人员成为非常好的测试人员。我估计你肯定要问“怎么才能做到”呢？当你汇报一个问题的时候会发生什么？我抛出了另外一个思考。开发人员修复缺陷有时候他们不修复缺陷有时候他们推迟修复缺陷有时候问题被标记为“不可重现”