今日日程：
上午——QA技能小组需求收集大会
会上暴露出的主要问题：

• 大家对QA的定位、认识和独特价值有很大的疑惑，大多数问题都和此有关。在意识上首先退守到检查流程执行没有的警察角色上，这样的工作似乎没什么价值，充满了疑惑。这个问题，后续不能以研讨的方式进行，而是拍板订钉，直接宣讲，否则被引导到错误的方向。
• 原有的收集需求的目的并没有完全达到，不过了解了整体水平，但为后续工作思路很有帮助。不少人还停留在no know no know（不知道自己不知道）的地方，所以提不出一些具体的需求，都是非常大，如系统了解流程、了解质量工具和方法。

下午前半截——某产品测试代表介绍测试工作思路
通过前期的接触，感觉到该测试代表一直强调测试的独立工作，不想参与到系统设计的工作中去，认识上有明显的偏差。所以会议上提了几点建议：

• 当前公司的测试流程是自底向上发展整理的，并没有和系统设计流程进行有效的结合，虽然解决了部分问题，但是重复劳动、产品整体开发效率低的问题并不能得到有效的解决。公司已经意识到这个问题，已经有人在进行改进的融合。（题外话：有一种情况很不喜欢，就是测试讨论参与开发的讨论与检视甚至设计的时候，总是得到这样一个借口“我们需要从客户的角度出发进行测试设计”。关键的问题是，这根本不是不参加开发设计活动（讨论／检视／场景分析等）的理由，这句话的潜台词就象是“开发从来不从客户的角度考虑问题”，可是事实是这样吗？开发进行设计的时候，不从客户的角度考虑问题，那设计的是什么东西，很明显，整个产品开发的过程中，所有的角色都是从客户的角度考虑问题，不仅仅是测试，只是更细的考虑问题的维度和方法不一样而已。所以，这句话根本就不可以作为一个理由、借口。而应该是，在设计讨论、检视的过程中，就及时的将自己的专业技能贡献出来，在问题还没发生之前就让开发人员改正。况且，完全不理开发，只管自己做，那是一种什么情况：开发、测试都是从客户的角度出发，可是得到的对系统的理解却完全是两回事，对系统的设计和测试居然会是两套标准，那测试发现N多的BUG、开发和测试之间永无止境的吵架也就不足为奇了。关键是，这样的后果很严重，开发不停的改BUG，测试活动永远不能结束…… 只有一个角色对系统应该是怎样的有决定权，那就是SE（当然可能不是一个人也可能是一个组织），测试代表应该积极的参与到系统设计组中对产品应该是什么发挥力量，而不是在旁边等着，然后说产品不应该是这样）
• 测 试仅等系统工程师输出设计需求后，才进行测试需求的分析，在对产品系统的了解上已经落后于系统设计人员，系统设计活动最重要的一点并非仅是其输出的需求和 文档，而是在设计的过程中大家的讨论、交流，这中间传递了大量的知识，不是紧靠文档输出能够学习和体会得到了。测试团队一定要参加到系统设计的讨论中去， 而不是在一边埋头学习协议、标准，何况当前有大量的新员工，参加讨论无疑会极大的提高学习的速度和质量，并且有利于激发大家的积极性。（此 处非会议所提，而是自身感想：另外，无论是开发人员还是测试人员，在产品的开发中都要面对大量的纠缠在一起的问题，只有让大家学习到有效解决这些问题的方 法，才能提高大家的积极性，也能让大家感到学有所成，富有成就感。在这方面，我有强烈的感觉，因为近期听到的离职员工反馈的是“工作了两年，啥也没学 到！”，这种感觉在我工作的前两年也有深刻的体会，所以感触很深，所以转而探寻Why走上了软工的道路。幸运的，去年末一位资源部门的老大和我说，一位员工离职时还记得的我，当然说的是好话， 让我很高兴。更是加深了这方面的体会。这些日子，SE一直和我说，现在大家热情特别高，而且已经可以放心交给下面的员工独立进行工作，一旦大家学会了可以怎么做，不再象开始那么乱了，最近轻松多了，可以写写总结了：-））
• 澄清大家对流程活动的一些误解，统一术语
  

最后大家达成一致意见，测试除参加系统设计的评审外，必须参加系统设计的讨论，对每一个专题指定相关的测试人员。

下午后半截——另一产品研发会议
得到两个可以作为案例的题材，后续可以再调查整理
有人提到目前提交系统组裁决的问题单分析描述不足，我的第一反映就是把问题单打回，不过开发代表说了一句后续开会的时候一起看一下，说几次以后，大家就知道该怎么写了。这点做得确实精彩，值得学习：）

晚上——某产品系统设计阶段活动清理
讨论明确包需求、设计需求、设计规格以及需求跟踪之间的区别

fasiondog
2007年8月16日

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1747542