看ASP .NET 团队如何进行测试(2)

The Feature Crew Model
在.NET 2.0 release之后, 开发团队对开发软件的方法, 做了一个很大的转变. 这个改变是从上到下, 作者称它为"Feature Crew Model". 整个开发部门为了这个方法做了很多准备, 花了几个月的时间去开发许多工具以及infrastructure. 这个model主要概念如下:

1. 在开发部门中, 每个Product Unit(PU)会把要relase的系统切分成一堆features. "feaures" 是产品的一个logical sub component, 理论上他们可以单独被开发

2. 会从PM, Dev, QA 的resources, 找出适当的人来建立feature crew. 他们会有一定程度的自主权, 来管理他们的milestone, 以完成他们feature

3. Feature crew会在一个独立的code branch中开发他们的东西

4. 他们会订定一连串的Quality gates, 唯有通过这些规定, 这个feature才算完成. 这些程序才允许整合到main product branch

这种作法的关键是, 要求每个个别的feature要做到完美, 才能整合进来. 和以前比较起来, 这是很大的改进. 以前是很多程序开发都放在main branch, 因此必须不断的做regression test, 来确保整个系统的质量.

第二个好处是, 鼓励Dev和QA必须要有更好的沟通, 并且让他们可以尝试Scrum或是其他任何agile的 methodolgies.

Our First Feature Crews (ASP.NET Ajax 1.0 Release)
作者第一次用feature crew, 是在做ASP .NET Ajax 1.0(Atlas)的时候. 那时候没有人知道要怎么做, 因此他们必须做一些实验并且适当的客制化, 来符合他们的状况:

Atlas把团队分成以下feature crews(这些crews也是依以下顺序kick off, 因为后面的会依赖前面的)
- Core: which included the type system and BCL.
- Networking: everything under Sys.Net
- Partial Rendering: UpdatePanel (this is the feature crew that I worked on, along side Eilon Lipton)
- UpdateProgress/Timer: targeted crews for only these 2 controls.
- Services: script callable Membership, Profile and Roles services.

ASP.NET QA Process in a Feature Crew
相对旧的流程, ASP NET 的 QA团队并没有太多实质上的改变, 我们还是忙于准备测试那些要发行的不同版本, 所以我门要做的事情如下:

1. QA 的resource被分配到一个feature crew
2. Deve/PM/Test同时在独立的code branch上, 开始处理这个feature
3. Dev 负责撰写unit test
4. 每周至少三次desgin feature 会议, 或是提供status updates
5. 当在desing再进行的时候, PM负责spec, Dev负责prototypes, QA负责test plan
6. QA同样也有test plan review
7. 每当Dev有check in code时, QA会尽快去测试它, 并且开始撰写 automation
8. 利用autoamtion complete numbers来追踪目前的进度
9. QA负责确认是否Quality gates check list上的东西已经完成. 更重要的是, 是否这些quality gate上的东西是被自动化完成, 并且在大量的configuration上被执行过.
10. 等到所有quality gates被满足后, 这个feature将会被整合到main branch

How did it Work?
Benefits
- 在不同rile之间会有较好的合作发生
- QA在测试阶段就加入
- Code整合到main branch时已经有很高的质量
- Dev的unit test可以帮忙在早期找到问题

Disadvantages
- 最大的问题是, 过去在2-3年内要做的事情, 现在要在3-4 月内做完. QA并没有改变做事的流程, 所以QA变成是bottle neck. QA仍然需要建立完整且全面性的feature test plan, 并且还是很着重于automation. 即使现在feature改变的很频繁, 我们还是这样做.
- Dev的unit test和QA的functional test, 之间有些重复, 以前的旧思维"test everuthing"仍然存在.
- Crew 之间的关连性造成一些问题, 使得crews会进行的不顺利或停顿

这个model, 使得团队在开发流程的初期, 就开始注意quality. 但是QA团队却因此而遭遇很多问题, 有些问题是之前遇到, 可是后来还是一再发生, 像是 finding bugs to late. 所以作者认为他们还需要再作调整, 来解决这些问题

Note:
我在之前曾有一篇描述类似的作法: Agile at Microsoft. 看起来微软似乎已经是全面采用这样的作法, 大家可以参考一下
http://www.wretch.cc/blog/kojenchieh/15331734