做好一个系统分析师、项目经理75条准则（3）

 

40. 其他部门知道你们项目组在干什么么？

要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，
其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，
那种感觉不太好。

41. 通过Email进行所有正式沟通

Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，
然后Email来确认。

42. 为项目组建立多个Mailing Group

如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，
ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。
这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。

43. 每个人都知道哪里可以找到全部的文档么？

应该每个人都知道。这叫做知识管理（Knowledge Management）。
最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。

44．你做决定、做变化时，告诉大家原因了么？

要告诉大家原因。Empower team member的手段之一是提供足够的information，
这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了
才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件
的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，
而在于是不是掌握资源。

45. Stay agile and expect change

要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，
对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员？

要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？

这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？
测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么？

应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。
我有时候在做第一遍测试的同时补上test case。至于先test case再开发，
我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例？

不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动
生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？

要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？

要这么做。自己看自己写的程序界面，怎么看都是顺眼的。
这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么？

别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，
忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，
只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？

不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，
早死早升天。

54. 你注意到测试中的杀虫剂效应了么？

虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，
最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

55. 你们项目组中有人能说出产品的当前整体质量情况么？

要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。