Scrum交互瀑布式软件测试

2Aq-X
][(c0　　有时候，在Scrum中对用户故事进行测试的 时候需要在最后进行一些瀑布式的步骤。在这里我所阐述的情景是基于这样一种情况：在Scrum流程中，需要在Scrum流程的最后阶段进行一些顺序性的步 骤来对所开发的功能进行测试。这些步骤在我们的组织中是必须的，而且这些步骤是为了产品发布的瀑布式流程，因此，我们不得不处理在Scrum中进行瀑布式 流程的情况。然而，据我所知，遇到这种情况并不只有我们。我们把这种情景叫做“Scrum和瀑布式的交互”（详见Michele Sliger的《Bridging the gap： Agile projects in the Waterfall enterprise》）。我认为这种情形应该是很常见的，因为在一个组织中Scrum的实施一般是循序渐进的，也就是说会存在Scrum和瀑布式同时存 在的时期。

　　下面的图是对这种情形的一种表述：51Testing软件测试网*Qs]4F+D$mN PW@

51Testing软件测试网%J%ncY)NrR(Lq&Te"[v

　　首先我会在本文中讨论我们是如何在我们的流程中进行测试的，然后会分析有时会在测试的选择上遇到的反对意见。我希望可以帮助那些遇到同样问题的人，然后我们可以进一步对如何在这种情况下的最好的测试方式进行讨论。51Testing软件测试网?[RK@

　　情景

　 　我们所开发的新功能是又很多用户故事组成的。在每个用户故事开始的时候，团队里的所有成员都会聚到一起讨论我们所谓的“测试策略”。这些测试策略可以被 认为是用户故事的测试验收标准。总的来说，每个测试策略都被转换为手工测试，要完成一个测试场景需要经过不同的测试步骤。我们会为每一个用户故事编写手工测试用例。51Testing软件测试网*[0yz&ld1?+u

　　相对于完全的Scrum化的流程而言，这种在交付之前进行瀑布式的流程，让我们不得不在把产品交付使用之前对所有的功能进行一次完整的测试。

　　反对

　　下面是几个对这种情景的反对意见，它们之间是互有联系的：

　　只为每个用户故事编写和运行测试是不够的，因为我们要对整个功能重新运行所有测试。最好是在Scrum流程的最后进行整个功能的测试。

　　我们花费了大量时间来为每个用户故事创建测试用例，然而，我们却可以为一组用户故事创建一组测试用例。

　　我们在相同的测试上花费了太多的时间：我们先在Scrum流程中对每个用户故事进行测试，然后又在瀑布式流程中对整个功能进行一次整体测试，最后又在瀑布式流程的QA阶段对这些功能再测试一次。51Testing软件测试网*t)aevc8l

Yg)lLkL&f.j0　　第一次分析

　　我认为为每个用户故事进行独立测试是敏捷流程的基础，即使是在一个和瀑布式流程融合的场景里。不光是敏捷或者Scrum，无论是任何软件开发流程，我们都应该把测试集成到流程当中。这样的方法符合现代质量管理的基本原则：“质量是靠创造出来的，而不是靠检查出来的”。

e}N? \S/f0　　尽管在Scrum中引入瀑布式流程也需要遵循这条原则的原因是：因为在流程的最后阶段才进行测试会导致众所周知的问题（详见Mike Cohn的《Scrum敏捷软件开发》）。团队不应该将质量看作成开发工作以外的事情，而将测试工作分配给团队里的唯一成员（测试专家）。让整个团队都参 与到测试中来是非常重要的（详见Lisa Crispin和Janet Gregory的《敏捷软件测试：测试人员与敏捷团队的实践指南》）。51Testing软件测试网c)fEu%L6?!i

%qST
a @`0　　接下来让我们详细分析一下那些反对意见：51Testing软件测试网ex7O4e!B'X]

i:G |[%Un7e @0　　只为每个用户故事编写和运行测试是不够的，因为我们要对整个功能重新运行所有测试。最好是在Scrum流程的最后进行整个功能的测试。51Testing软件测试网_
d@2uAt/Lh

5s"o2h.FDP0　　虽然为每个用户故事单独进行测试比对整个功能测试需要花费更多的时间，但是根据我的观察，当我们对用户故事进行独立测试的时候我们一般倾向于测 试得更加仔细。我认为那就是为什么我们要把一个功能分割成多个逻辑模块也就是用户故事的原因。当我们单独考虑用户故事而不是通盘考虑整个功能的时候，我们 能够考虑到更多情况，更多测试用例。51Testing软件测试网'q\z niF `g]x

　　因此，尽管我们在测试上花费更多的时间，我们却测试得更加细致，也得到了更多测试结果。对我而言，这样并不是浪费时间，而是对在流程开始就引入 测试能够更彻底地进行测试的很好证明。在进行开发的时候，如果能够把这些测试牢记在心，就能生产出质量更好的软件，这是因为在开发的时候要考虑到如何才能 通过所有的测试来完成一个用户故事。51Testing软件测试网pZ~%BI#\
C"Q@.i

　　我们花费了大量时间来为每个用户故事创建测试用例，然而，我们却可以为一组用户故事创建一组测试用例。51Testing软件测试网4opx9iB-c

5{.k+XRF(k0　　有时候，不得不承认的是：当我们明知道我们要在后面的用户故事测试同一个功能的其他部分，尤其是用户故事比较小的时候，看起来为每个用户故事编 写测试用例是在浪费时间。我们不禁会问：“为什么不只为整个功能编写测试用例呢？反正我们都需要在瀑布式阶段中对整个功能进行测试（其中有可能覆盖到几个 用户故事）。”

"g)d7X3] p jO+\0　　在我看来，这样的想法有时候反应的正式我们没有正确地创建用户故事，或者是测试设计得不够好。尽管有时候我们需要在后续的用户故事到来的时候对前面已经完成的测试进行修改，但是这样的修改应该是非常微小的，否则的话就说明用户故事的编写出现了问题。51Testing软件测试网D"^
y3\ jLH

　　那么，如果我们为一整个功能编写了测试（涵盖了多个用户故事），而由于某些原因这个功能只是完成了一部分怎么办呢？我们不妨想想，如果我们总是有一组测试用例反映了当前已经开发完成的功能会不会更好呢？51Testing软件测试网9?_+R.E[

　　我们在相同的测试上花费了太多的时间：我们先在Scrum流程中对每个用户故事进行测试，然后又在瀑布式流程中对整个功能进行一次整体测试，最后又在瀑布式流程的QA阶段对这些功能再测试一次。

`F"N)hI3a-M:n0　　要回答这个反对意见其实是最容易的，因为答案是肯定的。没错，你没有看错，我同意这种看法。因为我实在找不到比引入自动化测试更好的解决方案。 但是要成功实施自动化测试，有时候你不得不面对组织文化和其中的各种阻力。我把这些看作是团队不得不处理的技术债务，因此团队需要进行改变来说明敏捷的测 试原则是可行的。而当然，这不是一件容易的事。51Testing软件测试网q?)CVjqK

　　我希望其他对如何处理测试问题的读者能够和大家一起进行在线讨论。