《敏捷软件测试》的读书笔记(二)

第二部分 组织挑战

3. 文化挑战
组织文化: 敏捷团队最适合于允许独立思考的团队。
质量哲学:如何定义软件质量的可接受水平的角度;
整体团队负责质量
技能和适应能力
辅助因素: 测试人员需要时间和培训。
合适的节奏:在团队更好的管理负载和节奏之后,加班才会消失。
客户关系:敏捷团队依赖于客户至少是客户代表的紧密参与。
组织规模:组织越大,结构中的层次越多,不适合技术和业务交流。
沟通挑战:每日例会。
组织内的文化冲突
提前计划
先行动后道歉:想办法创新。
授权团队
测试/质量保证团队成功适应敏捷的障碍
丧失身份:测试人员坚持拥有独立的质量保证团队(害怕丧失质量保证人员身份;害怕丧失支持;害怕在产品和组织中失去身份)
其他角色:思考团队缺少什么角色使我们停止不前?
缺乏培训:培训帮助测试人员适应敏捷转变。
不理解敏捷概念:团队必须就如何成功实现向敏捷的转变而达成一致。
过去的经验/观点:测试人员坐在自己的座位上,并不与程序员讨论存在的问题。
角色间的文化差异
引入变化
讨论恐惧:提供讨论恐惧和获得反馈的机会。让人们知道感到恐惧是正常的。保持开放态度。讨论每个恐惧的根源,从讨论中 学习,作出决定并继续前进。
赋予团队权利
庆祝成功
管理层期望
经理的文化改变:敏捷团队的经理关于于清除障碍,让团队成员更出色地 工作,而不是糟糕地管理团队的活动。
使用经理的语言:告诉经理投资回报率;图表告诉经理当前的项目进展;
改变并不容易:耐心、让他们感觉到痛苦(人们最希望在他们感觉到最痛苦的领域做出改变)、建立你的诚信、警惕质量警察思想、用离开表示拒绝
[要做一个合作者,而不要做一个强制实施者]
 
4. 团队构成
独立的质量保证团队:拥有独立的检查和审计角色很重要;可以对产品提出没有偏见的意见;开发关系过紧密,会确实站在客户的认识;开发leader会站在代码的角度要求你;
[如果在一个团队有什么优点呢?1. 沟通更畅通;2. 代码理解更充分,产品质量更高; 3. 测试人员成长更快] 
把测试人员整合到敏捷项目:好的关系很重要
敏捷测试团队:人员职责划分不是那么的界限化;
人员分布
坐在一起很利于沟通和合作,不坐在一起需要的是大家的努力;
人力资源
测试人员/开发人员比例,依赖于应用的复杂性、测试人员的技能和使用的工具。
当程序员负责手动测试和测试自动化时,团队才真正有工作效率。
团队建设
自组织团队
在赋予团队权利自己发现并解决问题时,团队进展得最快。
引入其他团队
每个团队成员有同等的价值
业绩和奖励
你可以做什么
 
5. 迁移传统过程
寻找轻量级过程
度量标准
精简测算:减少测量的数量和寻找驱动正确行为的测量。
为什么我们需要度量:当度量被用作路标-为提醒团队偏离了轨道或者在正确的道路上提供反馈;不应该关注个人度量,而应着眼于目标和到达目标的趋势。 
与度量无关的事情:使用度量判断个人或者团队业绩是危险的事情。
沟通度量:确保度量以正确的方式呈现给合适的人。
度量的投资回报率:应记录每一个度量标准的投资回报并决定是否跟踪或者维护它。
缺陷跟踪
为何应该使用缺陷跟踪系统(DTS):方便;不使用DTS就没有地方记录所有缺陷的细节;知识库;大规模或分散团队;客户支持;度量标准;可跟踪性;
为何我们不需要缺陷跟踪系统:作为一种沟通工具;浪费时间和精力;
集中注意力:工具的出现是为了解决问题;
测试计划
测试策略和测试计划:注意信息使用的频率和用途,越是长的文字越是很少有人会去看;
可跟踪性
现有的过程和模型
审计
框架、模型和标准
 
 
 

你可能感兴趣的:(软件测试)