很多团队都倾向于认为自动化是一种加速软件交付的方式，因为这是团队内部经常能够感知到的瓶颈。但是，如果他们将自己的开发实践过程当作一个整体来深入研究的话，那么他们会得到更好的结果。 一、如何预防 BUGS？ 测试，尤其是 UI 层面的自动化测试，通常会被安排在软件交付周期的最末端，通常会试图发现一些可能进入生产环境并给最终用户造成不良影响的 bug（这些 bug 就如同细菌一般）。在这种情况下进行的测试可以探测出 bug 的症状，开发人员进行的修复就是治疗。这就如同我们在等待我们的系统生病并为此采取一些措施。 这种方法对于团队来说是有一定的效果，但是，现在的工作环境迫使我们用更少的人做更多的事并且要比以往更快地完成任务。因此，这种方法并不能长期可持续地运转。这时基于预防的方法而非治疗的方法就横空出世了。 通过对如何构建系统作出调整，我们就可以在故障发生之前探测出问题，或者更好的是，让他们从一开始就不那么容易产生 bug(这就是所谓的“预防”)。这就意味着我们在 bug 产生前就预防它的发生而非试图在 bug 产生后再治疗它。古语有云：预防胜于治疗！ 二、我们的测试自动化之旅 在我刚开始加入移动团队（该团队负责创建并管理公司的点播产品）时，我们所有的测试都是手工执行的，平均每年我们只在每个平台上发布 2 到 3 次。我们知道如果想要加快速度，最明显的瓶颈就是测试。 在没有发现新 bug 的情况下，每个回归测试周期要花费将近两周的时间。如果发现了新 bug，那么开发团队需要时间理解并确认 bug，确定一个修复方案，然后再应用这个方案。这会导致已经执行的任何测试都变得无效，因此需要重新启动测试过程，最终导致测试周期花费两倍以上的时间。 因此，我们开始着眼于将更多的 UI 测试进行自动化处理。我们总是从小的方面开始改变看看这样的尝试能否将我们引入我们想要的正确的方向上，并且我们只选择对新功能进行自动化测试。这种尝试一旦被证实是有效的，我们就会将自动化测试引入到现存系统的其他领域或者已知的问题领域。 我们组织 3 个朋友作为一个团队来理解我们想要构建什么，以及该特性的关键接受标准应该是什么。这为我们提供了一个起点，让我们了解如何分解该特性以及哪些用户场景需要自动化。 在此基础上，我们确定了可以用来自动化测试的工具(Calabash 和 Appium)，并在实际环境中应用它们。对我们来说，这是在真实的手机上进行测试，而不是模拟器，为此我们建立了自己的设备测试场以更好地利用我们的移动设备，同时也允许它扩大规模以期能够在整个组织中得到应用。 三、自动化测试带给我们的好处 起初，自动化给我们带来了很大的帮助：通过自动化我们可以快速可靠地运行简单场景的测试用例并迅速得到我们想要的反馈结果。但是随着时间的推移，在最初的一批bug 被捕获之后，自动化测试很难再发现新的 bug 了，除非我们手动地修改自动化用例代码。 同时，我们也注意到由于某些场景我们无法自动化导致一些 bug 依然存在于系统之中：比如，任何与可用性相关的功能都不得不进行手工测试。 因此，我们最终采取了一种混合的解决方案---自动化用来快速跑一些关键场景，让团队知道自动化测试没有明显地破坏任何东西，以及如果合适的话对任何新功能进行的探索性测试也可以自动化处理。因此，尝试自动化测试的过程是曲折的，我们在尝试测试时很容易出错，又或者手工测试花费的时间太长。 带给我们自动化之旅的一个意料之外的好处就是我们开始更快地发布产品，自动化让我们更加专注于我们正在尝试完成的工作事项。这就让我们可以将每一个新特性新功能拆分成更加细小的分支（可以独立运行的分支）并将这些分支进行自动化测试。 这使得我们可以更快地将各个分支发布到生产环境中并从最终用户处得到实时的反馈。起初这一好处并不明显，因为我们仍在尝试着识别自动化场景。只有在事后，团队才能看到这是他们无意中所做的事情带来的价值。简单地说，我们开始将工作分解为一小批最终用户价值。 四、研究我们的开发模式 我们开始意识到 UI 自动化测试并没有真正带给我们想要的回报。正因为如此，我们开始研究开发过程中的其他领域，看看是否可以做出些许改进。但作为一个团队，我们的问题之一是，我们太过接近流程，以至于无法客观地看到哪些是有效的，哪些是无效的。为了克服这个问题，我们请来了一位敏捷教练来帮助我们的团队。事实上，我们引入了两位教练：一个是帮助团队理解他们正在使用的流程，另一个是帮助我们更好地理解我们实际上是如何构建我们的系统的。 敏捷教练都来自于团队外部，因而他们可以质疑我们系统的任一部分，而不用担心冒犯任何人。他们会问一些简单的问题，让我们了解我们工作方法背后的原因，并将我们从“我们一直都是这样做的”循环中解脱出来。例如，用于管理我们工作的 stand upboard 通常有 backlog、next、dev、wait - For -test、in test and done 等列，但是我们从来没有想过要问为什么我们有 next 和 wait - For -test 列。 我们的教练能够提供帮助的是：我们为什么要将软件开发工作分解成这些小项，为什么开发和测试被视为两个不同的活动。教练的方法并不是简单地改变我们的开发过程，但他们能帮助我们明白问题的根源在哪(未发布的功能卡放在任务看板的 next 和 wait-for-test 列)，让团队看到通过消除开发和测试列（next 和 wait-for-test），取而代之的是一个简单的正在进行（in-progress）的列，很多工作依然可以顺利进行。您可以在我的文章 In test colum 中找到更多关于使用这种方法的好处. 五、我们学到了什么 我们发现的最大问题是：就敏捷开发实践而言，我们的团队中存在“形式主义”。仅仅因为我们有 standups（站会），以小团队的形式工作，并在 sprint 结束时发布东西，但并不意味着我们实际上是敏捷的。这只是意味着我们有一些仪式，让我们看起来像“敏捷”。事实证明，并不是每个人都很清楚我们为什么要这么做，甚至不清楚我们这样做的好处是什么。 我们所做的第一件事就是澄清什么是敏捷：它更多的是基于客观反馈的可持续软件交付过程，而不是试图尽可能快地发布你所能发布的任何东西并期望最好的结果。我们通过读书俱乐部促进团队讨论来实现团队内部对于“敏捷”一词达成一致的理解。这有助于团队成员更好地掌握敏捷实践背后的原则，并在他们的工作中做出更好的决策。 我们还开始研究我们实际上是如何在代码级别构建系统的，并试图将开发人员在如何提交代码、提交的频率和提交的大小这些内容可视化。这并不是试图让开发人员难堪，而是帮助他们理解作为一个团队，他们是如何影响代码库的，并试图鼓励开发人员养成更高效的习惯；比如对于较小的、有重点的任务进行提交，而不是在一天结束时的一次性提交大量的代码。如果他们确实做了大量的提交，那也可以，但是要让其他开发人员知道他们为什么这样做，来促进团队成员间相互学习。 我们对团队最大的改变之一是鼓励结对编程，因此没有一个开发人员单独开发一个特性。这加快了代码评审的速度，但他们也不太可能相互推卸责任。比起在某些项目中仅由资深成员来审查代码而言，结对编程还有助于更快地提高我们团队中较年轻成员的技能和知识，使他们能快速地提高生产力。 六、为了拥有更加高效健康的开发模式，我的一些建议 在团队工作中，需要在这个团队中确定一个高效、健康的开发流程。一个行之有效的方法是建立一个团队视频俱乐部。这允许成员从日常活动中抽出一些时间来学习构建软件的新工具或新方法。在每次会议结束时，团队讨论都由会议负责人(项目经理、技术负责人或将想法带给团队的人)推动，来探索如何使用这些概念来帮助团队尝试新事物。 然后选择一个概念，并对结果应该是什么有一个清晰的想法。我们以更好的单元测试为例，单元测试对团队意味着什么?更好的单元测试会给团队带来什么？一旦你有了这些答案，你就可以想出多种方法来达到这个目的，这样你就可以选择一个可以让你快速而客观地见证结果的方法。 你需要弄清楚，你所使用的新过程或新技术是否真的帮助你在规定的时间内实现了你的目标。如果是这样，那就太好了。如果没有，你需要停止吗？做更多调整吗？您还需要决定谁将实际进行这一尝试，以及他们将如何与团队的其他成员进行沟通。 记住，如果你想让任何新流程或想法在团队中站稳脚跟，那么团队中每个人都需要参与其中；否则，遇到的第一个困难就是，这个想法将停止或缓慢执行，因为只有参与尝试的人才能从中有所收获。

分享本篇文章给更多人: