PMI-ACP®认证
适合敏捷开发项目 敏捷项目管理最佳实践
网络课程
PMI-PBA®认证
重视项目商业分析 商业价值与需求分析能力
NPDP®认证
产品管理国际认证 全球产品管理最佳实践
网络课
PMP®认证
单项目管理经典指南 年轻项目经理首选
北京 | 直播 | 录播
PgMP®认证
大型复杂项目全球标准 定位高级项目管理层
网络班
PfMP®认证
链接战略与项目 实现组织资源投资回报
全球直播
软考项目管理
信息系统项目管理师 系统集成项目管理工程师
计划 | 报名 | 经验
版面信息
本版版主
俱乐部导航
联盟·近期活动
社区热点
精彩专题
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
推荐信息
社区圈子
联系社区管理员
那些没有认识到“通过测试并不能保证质量”的主管们,在软件出了问题时,第一个想到的就是测试的问题,我对他们的这个条件反射表示理解,但也非常的忧虑,因为这会直接导致最终测试人员的绩效不好,而这也容易形成一个恶性循环。
而团队中也并非仅仅主管会不理解,客fu人员最先埋怨的对象往往也是测试人员,因为表象显示的就是客fu电话多,客户的问题没有测出来,那责任就应该是测试人员的了。当然对于他们的不满还是比较容易转移的,只要合理的解释说明,那么他们也会理解的。
而要扭转测试员的这一尴尬境地,解释或者自我检讨只能治标,就像作者所说的质量保证要来自整个项目团队,建制、建全软件开发过程,保证每一个节点、每一个阶段的质量,才是治本之道。
附注:
有一篇名为《需求与测试》的文章里有这么一段话:“其实我们有时候会抱怨需求为什么会考虑不周全,可是换个角度想想,我们认可程序会存在bug,那么需求同样也会有。这就像是一场接力赛,需求是第一棒,开发是第二棒,测试是第三棒,每一棒的交接都有上一棒的辛苦付出,也只有彼此信任和共同的努力,才能最终传递胜利。”