Smart Testing

Office PARC负责Word和相关产品的开发。PARC测试团队大约有40~50人，有5个测试领导（Test Lead）和1个测试经理（Test Manager）。测试经理汇报给负责Word和OneNote的副总裁（Vice President），副总裁汇报给向微软商业部门（Microsoft Business Division）的总裁（President）Kurt DelBene，而Kurt汇报给首席执行官Steve Ballmer。

这是一个相对扁平的组织结构。Kurt 领导的团队非常庞大，他们的产品包括Microsoft Office（Word, Excel, PowerPoint, OneNote, Outlook, Access, Publisher, Project, InfoPath, Visio等)，Mac Office, Office Web App，SharePoint, Exchange, Lync (服务器和客户端），Office 365等。测试经理只越过一级就可以向总裁Kurt汇报，这有利于传达研发团队的意见。

测试经理的名叫Mike，是一位非常资深的管理者（其职位是Partner Test Manager）。他亲自主持每周测试会议（Weekly Test Meeting），向PARC测试团队沟通当前进度和本周重点。

周会是一项被广泛采纳的开发实践。Office PARC的测试周会有什么特点呢？以下是我连续两周观察到的内容。

第一周

会场

在周一10点，Office PARC的测试员工进入会场。在我看来，以下几点值得记录。

1. 会场的桌子被摆成U型。某个员工发言时，其他人都可以看到他的表情。
2. 测试经理Mike站在会场中间主持讨论。如果有讨论，他可以随时走到发言者身旁，近距离地交流。
3. 投影仪投射出PowerPoint文档，其内容是本次会议的议题。会后，该文档被保存在内部站点上。
4. 只有少数员工携带笔记本电脑参加会议。在中国微软，几乎所有人都携带笔记本电脑参加会议。
5. 大多数员工携带纸质笔记本参加会议，但是频繁记录者不多。

上周趣事

会议的第一项议题是上周趣事。Mike问：关于上周，大家有什么好玩的事情可以分享？于是，一些员工分享了他们在工作内外的遭遇，并引发阵阵笑声。以我观察，发言者以性格外向或资历较老的员工居多。像我这样初来咋到、性格内向的员工发言的可能性较低。但是，“无关的趣事”使得会场气氛变得轻松，让我觉得这不是一个压抑的“工作会议”。

杂项

会议的第二项议题是Misc（杂项）。议题大多是团队内务，包括欢迎新员工、年中职业讨论（Middle Year Career Discussion）、微软年度反馈（Microsoft Poll）等。

例行议题

在轻松的内容之后，是一系列固定的议题，包括：项目进度、测试自动化情况、Bug情况、本周重点任务等。在我看来，以下几点值得参考。

1. 每一个议题都有固定的负责人（Driver）。他（她）可能是测试领导，也可能是资深员工。他驱动PARC测试团队的一项具体工作，如测试自动化、Service Pack测试、Bug修复等。这使得PARC的测试实践拥有统一的风格，且促进了测试人员之间的交流。
2. 负责人往往会用带标记的表格或各种图形，来传达当前情况。明幻灯片综合了多个负责人提供的数据。
3. 对于里程碑的开发进度，其度量单位是已经完成的功能（Feature）数，而不是已经使用的开发时间。
4. 对于测试进展，其度量指标包括测试工程师的Bug数量和自动化测试通过率。
5. 依据Office的开发计划和当前进展，负责人给出本周的工作内容和重点。在会后，他们还会发送邮件，给出更详细的说明和指导。

插曲

除了例行议题，本周的会议还有两个“插曲”。

第一个插曲是演示一项刚刚开发完毕的新功能。两位测试工程师一边演示，一边回答观众的提问。当时，我的第一反应是，这与Scrum的“Sprint演示”异曲同工。Scrum以2~4周的Sprint为开发单位。每个Sprint结束后，开发团队都要向利益相关人（stakeholder）演示Sprint的成果。这有助于开发团队专注于用户价值、获得可度量的进展、增强团队信心、获得必要反馈。

Office采用的是螺旋开发模型，产品开发由几个里程碑（Milestone）组成。在每个里程碑，程序经理、开发工程师和测试工程师会组成功能小组（Feature Crew），完整的实现并测试一批端到端（end-to-end）的功能。每周例会提供了一个产品演示的固定舞台，使得功能小组能够尽快展示他们的成果，从而获得与Sprint演示相似的收益。

第二个插曲是介绍本周的一个测试活动：Test Focus Day，活动内容是用半天时间，让测试工程师一起测试Word Web App。活动组织者是Word Web App的测试工程师，她介绍了活动规则：测试工程师被分成若干个团队，每个团队各自编辑一份文档。在此过程中，工程师要尽力寻找bug，并使得整份文档美观、有趣。测试结束后，Mike作为评审，会选出最佳文档和最佳Bug。

介绍完规则，Mike接过话题。他首先感谢了组织者的工作，然后动员大家发动奇思妙想去编辑美妙的文档。他说了一句令我印象深刻的话：

We always find beautiful bugs in writing beautiful documents of the real world.

第二周

在第二周，PARC测试团队照例举行周会。会议内容是上周趣事、杂项和例行议题。除了上文所提到的内容，还有两点值得记录。

Dogfood

Mike指着投射出的PowerPoint文档说：“这是我用Dogfood Build制作的PowerPoint文档。在过去一周，我一直使用Dogfood Build。让我感到高兴的是，PowerPoint崩溃过1次，Outlook崩溃过2次，Word没有崩溃！”

Dogfood来自于俗语“吃自己的狗食”（Eating your own dogfood），意思是开发团队使用自己正在开发的产品。这是一项有许多收益的活动。

1. 开发者作为用户获得对产品的第一手反馈。这加速了产品的持续改进。
2. Dogfood要求正在开发的产品有较好的质量，不会妨碍日常的使用。这自然要求开发团队能够持续提供质量稳定的构建（Build）。Office vNext尚在开发的早期，就可以应用在日常工作中。这说明Office在每日构建和持续集成上的投入，收到了好的效果。
3. Dogfood有助于推进一些功能的完善。例如Dogfood PowerPoint崩溃，Mike不会绝望。因为Office的自动恢复（AutoRecovery）可以挽回大部分修改。不把自动恢复做好，员工很难正真使用Dogfood Build。
4. 在Dogfood过程中，不同职位、不同背景、不同习惯的员工会用不同的方式使用系统。在一个大的团队内实施Dogfood，很可能覆盖独立测试工程师不能覆盖的场景。

Mike的举动鼓励了我：连测试经理都安装并使用Dogfood Office，我也要加入这项活动！于是，我也在自己的机器上安装了Dogfood build，并每天用它处理邮件和编写文档。从这件事上，我体会到：有效的管理，有时不需要指令或劝说。作为领导，Mike的榜样作用不可低估。

最佳文档和最佳Bug

在“杂项”议题中，Mike拿出2页A4纸，上面写满了他的笔记（系手写，非打印）。他利用周末的时间，仔细阅读了Test Focus Day所产生的所有文档，并记录了每一篇文档的特色。基于笔记，他逐一点评了每篇文档，感谢撰写该文档的团队，并提点出他所喜欢的Bug。

在点评我所在团队的文档时，Mike特别摘录出一句他觉得很搞怪的话。其实，这句话是我写的，是我在文档中放的一个玩笑。这件小事说明Mike仔细地阅读了文档中的每一句话，并做足了功课。

我认为，所谓“正真”的领导重视，就是领导亲自做他声称重要的事情。Mike的言行表明，他非常重视团队协作、Test Focus Day和有价值的Bug。他在最后公布了最佳Bug的获得者和获奖理由，大家将掌声送给获奖的同事。

小结

1. 周会有助于提供稳定的开发节奏。Kent Beck在《极限编程解析（第二版）》中提出了多项实践。在这些实践中，他建议从“周计划”开始敏捷之旅。PARC测试团队的周会沟通了当前情况，并制定了本周计划。
2. 有效的周会需要仔细的准备。PARC测试周会汇聚了多个信息源的数据，绘制了图表，并以此形成行动计划。
3. 好的会议要有好的主持人。Mike的丰富经验和个人魅力提升了会议的效果。

在2011年2月，我加入Office Word团队，测试Office vNext（下一个版本的Microsoft Office）。为了记录和分享我的所见所感，我将在博客中开始一个新的系列：How We Test Software at Office PARC（缩写为：Test@Office）。

在开始正文之前，我有几点需要说明。

1. 我只是Office测试团队的新人。虽然我尽力避免疏漏和偏见，我难以保证博文不包含错误。希望读者不吝批评指正。
2. 我的博文只代表我的观点，不代表我所在团队、部门和公司的观点。
3. 我要遵循保密协议。我不会描述Office vNext的细节，不会讨论机密信息，也不回答相关问题。
4. 软件开发没有秘技。也许读者会发现，我所描述的技术和实践都是广为所知的“常见方法”。Office PARC只是将传统方法稍作改变、组合使用罢了。
5. 软件开发没有最佳实践（Best Practice）。语境驱动测试（context driven testing）认为：“在语境中存在好的实践，但不存在最佳实践”。Office PARC的方法具有参考价值，但是它们不适用于所有情况。
6. 我的文章很可能没能描述最重要的东西。语境驱动测试认为：“实践的价值取决于语境。在一起工作的人是项目语境中最重要的部分”。用文字描述技术和流程相对容易，描述情感、交流、气氛则困难得多。

如果您有批评、建议、疑问，请让我知晓。谢谢。

随着云计算和社交网络的快速发展，Windows用户将在多个软件中管理她的网络帐户。不幸的是，虽然这些软件都由微软开发，但是它们彼此孤立，无法提供流畅的用户体验。

Microsoft Office

• Outlook可以管理Live Hotmail邮箱，它要求用户提供Live ID。
• Word、Excel、PowerPoint、OneNote可以将文档存放在SkyDrive上，它们要求用户提供Live ID。不幸的是，虽然Outlook已经掌握此Live ID，Word等还是要求用户再次输入。
• Outlook Social Connector让Outlook显示发信人和收信人的社交网络更新，它目前支持Live Messenger、Facebook、LinkedIn等。对于Live Messenger连接，即便用户已经用Outlook管理Live Hotmail邮箱，它还是会要求用户输入Live ID。

Windows Live Essential

• Live Messenger、Live Mesh、Live Movie Maker、Live Photo Gallery可以分享彼此的Live ID。用户在某软件登录一次，其他软件就将此Live ID设为默认帐户。
• Live Mail需要用户再次输入Live ID。
• Live Writer需要用户输入WordPress或其他博客网站的帐户。
• Live Messenger与网络服务Live Services配合，可以将用户在社交网络（如Facebook、LinkedIn、WordPress、新浪微博等）的更新显示在Live Messenger和Live主页上。这自然要求用户输入Facebook、LinkedIn、WordPress的帐户。以我的使用体验，Live Movie Maker和Live Photo Gallery可以获得Facebook帐户，但是Live Writer对WordPress帐户一无所知。

Windows Phone 7

• 初始化WP7时，用户需要提供一个Live ID。
• Zune是连接Windows和WP7的桥梁。用户如果想利用Zune更新WP7，他需要再次提供Live ID。
• Windows Phone上的People Hub可以连接Windows Live Services，从而显示用户在社交网络（Facebook等）的更新。但是，当用户安装了Facebook官方App，他需要为App再次输入Facebook帐户。

在不同的软件中输入相同的帐户，既不方便也不安全。微软也许应该考虑在Windows 8上加入Account Hub，让用户统一管理各种帐户。在用户授权下，不同的软件通过Account Hub提供的编程接口获得帐户信息，从而提供流畅的用户体验。

在这方面，微软已经有所行动。

• Windows Live Services用Live ID连接了Facebook、LinkedIn、WordPress、新浪微博等帐户。使得用户在Facebook上的更新可以显示在Live Messenger和Live主页上；反之，用户在Live相册上的更新也可以显示在Facebook上。Windows Live Services可以看作是Account Hub在云上的雏形。目前，它的问题是其他软件无法从中获得这些互相连接的帐户。
• Windows Phone 7在初始化时，要求用户提供Live ID。之后，无需用户干预，它的People Hub就可以显示用户的Live联系人和社交网络更新；Email就可以管理用户的Live Hotmail；Mobile Office就可以访问用户在SkyDrive上的文档；Pictures就可以显示用户在Live相册的图片，并将拍摄的照片上传到Live相册。在多个应用之间切换时，用户始终可以访问相应的Live服务，用户体验很流畅。

这样，在Windows 8中提供Account Hub也是顺理成章的事。

• Account Hub是Windows Live Services的客户端，它们彼此同步所拥有的帐户信息。
• Account Hub管理了用户的多个网络帐户：Live、Facebook。LinkedIn、WordPress、Flickr、新浪微博等。
• Account Hub提供编程接口，供应用软件查询用户帐户。
• 当应用软件尝试访问Account Hub时，Windows以显著地方式（可以参考User Account Control的视觉模型）询问用户是否信任该软件。如果信任，用户可以将他指定的帐户共享给该软件。
• Account Hub可以要求用户提供一个Live ID作为默认帐户。之后，微软的应用软件，如Office、Live Essential、Zune、文件管理器，皆以此帐户为默认帐户。未来，“另存到SkyDrive”也许是所有Windows应用的功能之一。
• Account Hub不但可以连接帐户，还可以让应用软件分享帐户的资源。如Outlook可以访问Live Hotmail的通讯簿，Live Mail可以访问Outlook的通讯簿。当然，这必须得到用户的授权。
• Windows Live Service提供Web API，在用户授权的情况下，将帐户信息提供给其他Web程序。

各种消息都在暗示Windows8将拥抱“云计算”，模糊本地应用和网络服务的界限。而Account Hub将减少用户的重复工作，提供更平滑的用户体验。

多余的话：此篇博客看似与测试无关，却是我在测试工作中萌发的想法。于是归入“测试杂感”系列。