独立测试团队在敏捷开发中的几个特别实践-2018版

Posted 2021-04-25 大敏捷

[原文发表在https://hespr.blogspot.jp/2009/03/blog-post.html 写在2009年3月 
发现被人盗版了多处。竟然已经时隔9年，回望当初，结合最新的观察，升级到2018版]

在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践？ 
从以Scrum为代表的敏捷团队的组建上来说，敏捷团队并没有要求安排专门的测试人员，在Scrum中明确说明不区分开发人员角色和测试人员角色，XP中没有说明如何设置测试人员角色，有人解读为就是不需要专门的测试人员，有人解读为XP定义了所需核心实践，把是否安排专门测试人员留给团队和组织自身去决策。

本文讨论的是已经存在独立测试团队的情况，如何在敏捷开发中进行高效的测试。

实践1：测试跟进开发

通过快速的测试跟进开发，保证新增和修改不破坏已经获得的成果。 
主要有2类跟进模式：

一是迭代内无缝跟进或看板价值流式跟进，不妨称之为即时跟进模式，典型步骤如下： 
1，开发人员根据需求，编写代码，无论是否采用TDD，实现了界面和接口。 
2，几乎与开发同步，测试人员针对新故事编写测试用例，在开发人员提交到测试环境后，马上跟进进行手工测试，发现问题，马上提交开发，开发马上修改。
3，对此故事进行相关性+风险分析，识别探索性测试范围和时间，结合迭代内时间箱情况，进行探索性测试，也就是说，根据剩余可用时间来安排探索性测试。
4，在迭代内或者看板价值单元流动周期内执行完成所有相关故事的测试。

二是测试滞后一个迭代进行，就是开发迭代在先，测试迭代在后，不妨称之为滞后跟进模式，典型步骤如下：
1，在开发迭代时，测试人员理解用户故事，准备测试用例
2，开发迭代结束，开发人员提交迭代版本，以及完成的故事清单
3，测试人员执行测试，发现缺陷，马上提交开发，开发人员马上修复，非阻塞缺陷在下个迭代版本修复，阻塞缺陷马上提交新版本。
4，对全部故事进行相关性+风险分析，识别探索性测试范围和时间，进行探索性测试。同样结合迭代内时间箱情况，进行探索性测试，也就是说，根据剩余可用时间来安排探索性测试。

实践2：成为大敏捷团队的成员

子实践1：参加相关会议，如果是SCRUM，参加SCRUM所有要求的会议。

子实践2：可以阅读和修改最大范围的配置项（比如文档，代码，工作项）

子实践3：一起工作，比如把位子搬到开发人员旁边，如果同时参加多个项目，选择一个较近距离的位子。

说明：这个实践本身的宗旨与传统做法并无根本区别，这里的区别在于程度。

实践3：与定期构建一起执行自动化测试用例。

自动化测试用例既可以由开发人员给出，也可以由测试人员给出，但双方需要协同配合一起维护自动化测试用例。自动化测试能与高频构建为基来执行，至少每天一次。

子实践1：维护一套自动化测试环境，选择典型功能，开发出自动化测试，至少做到每日构建和测试。

子实践2：测试结果可以自动发布到合适的地方，缺陷得到跟踪管理

实践4：进行探索性测试，设计更多黑盒手工场景化测试用例，安排更多随机场景测试

为了发布的测试中，值得设计更多黑盒手工场景化测试用例。

选择一些典型场景化测试用例开发为自动化测试用例也是可以的，但是此类测试用例的自动化开发所需工作量较大，要看测试团队的投入和质量目标安排。

一般而言，从经济角度出发，黑盒手工场景化测试用例是发现潜在缺陷的有效且经济的手段，如果存在丰富经验的测试人员，随机场景测试也是值得更多采用的。

本实践在传统测试中也有，这里要强调的特别之处是可以考虑手工测试全部用场景化测试，大幅减少针对单一功能或局部功能的测试用例。

以上做法的最新说法是探索性测试，已经得到业内的认可，相应书籍已经有出版。

对测试人员的要求

从以上实践可以看到，测试人员所要掌握的技能有黑盒测试、探索性测试、自动化测试、场景化测试，最好也要常握白盒自动化测试，定期构建和自动测试报告

工具支持

常见的有HPQC，Zephyr/JIRA，fit,fitnesse, white, watir, selenium, cruisecontrol, QTP, robot, xUnit系列，xFit系列等等

效果和校验

上述的实践是否有效、是否高效，可以观察如下几点： 
1，达到发布条件所需的测试轮次或者时间是否减少？测试缺陷是否减少？ 
2，获得快速发布的能力，需求响应（从处理到上线）工期是否减小？ 
3，测试所需总的工作量是否在测试团队承受的范围之内，尤其关注测试后期的工作量是否大幅减少，减少的数量是否比在测试前期增加的数量要更大？

如果没有获得正面收益，就需反思了。