qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

QA和RD如何在早期就开始合作

  有人说若是QA早一点开始加入项目, 应该可以帮助项目质量变好, 可以帮忙厘清需求, 可以缩短测试时间. 听起来真的好处多多.
  可是真的是这样吗? 我想以各位看倌多年的经验, 应该会觉得不会这么容易. 是的, 是不容易, 但是原因是什么呢?
  就我个人观感第一个原因是mindset, 是的, 是mindset.
  像我现在在run Agile, 如果大家对Agile有所认识, 应该知道Agile强调就是mindset的转变, 如果心态没有转变成, 要因应变化而积极作调整, 那你在执行的任何practice都因而事倍功半, 最常见的就是便成mini waterfall. 因为我们只是把一个大的, 长的开发时程, 便成一个为期2 weeks 或4 weeks的小型项目. 事实上帮助会有限.
  同样的, 如果你认为QA早一点进去就会有帮助, 那同样也是不切实际的. 因为这要work, 需要很多人的mindset都要改变, RD, QA, manager都要做修正.
  在传统开发流程时, 测试是最后一个阶段, 因此QA养成一个习惯, 那就是需求要ready, design要ready, 程序要ready, 否则就无法开始. 因此不打破这个想法, QA早点进去是没有用的, 因为他会认为这些东西都还没有好, 他什么事也不能作. 所以还是得等到design or code ready, QA才会开始动作.
  所以QA需要转换做事的想法, 不要再认为你只需要被动接受RD或是manager给你东西, 你需要真的积极加入, 自己去创造或是找出你要的东西. 也就是说早点跟manager讨论需求, 和UI designer讨论UI行为的运作, 和RD讨论design的细节, error handling的细节等等. QA是可以领导或是驱动项目的进行, 而不是单纯的被动接受者.
  在开立测试个案时, 心态上也要和以前不同. 你的重点不是要去逮到RD的小辫子, 去冲高bug的数量. 你应该要做的是和RD一国, 一起去提升软件的质量. 也就是说事前就要和RD再三确认, 是否你开的这些case, RD已经加以考虑, 不管是细部功能的运作, 或是例外处理的部份, 都要一一确认清楚. 如果这些东西一开始都设计进去, 都考虑进去, 之后就不会
  有冗长的bug fixing时间. 需知道有很多bug通常, 都是因为事前没有人说要考虑或是要处理, 导致于最后要花更多时间去修复, 甚至还要在那边讨价还价. 若是这些事前能谈清楚, 那将会节省之后很多时间的.
  此外若是早点请RD review 过测试个案, 说不定可以知道有些测试个案可以不需要开立, 或是需要再加以补充. 像是有地方, 可能你开的case是在测到3 party或是别的team的code, 但是并没有打到自己要测的部份, 像这些可能就可以不要测. 或者, 有时候因为QA对于实作细节不了解, 或是缺乏coding skill, 有些个案便会开不到, RD这时候的建议便可以帮助你补足你不够的部份.
  另外在设计测试自动化的时候, 更是需要和RD早点讨论. 一方面可以让他考虑testaability, 一方面你不会多走一些冤枉路. 有些QA因为怕麻烦RD, 独立自行去开发测试程序, 或是来作performance test program, 结果事后却被RD指出, 有容易做到的方法, 或是这样的行为可能和受测软件架构不同. 这时候启不是很冤吗?
  当然啦, 一个巴掌是拍不响的, 同样的RD的心态也要转变. 在设计时不要认为QA听不懂, 或是无法贡献意见, 就不找他. 至少他加减听的状况下(注1), 当你不完整的文件出来后, 他也比较容易看的懂. 当然啦, 若是他也有coding的基础, 便可以很快知道你内部运作的行为, 对于之后测试个案的开立, 或是bug trouble shooting, 会有很大的帮助.
  (注1: 之前有post篇 "招募SDET来当QA是必要的吗? 正确的吗?" , QA你能加强这篇所说的能力, 否则RD看不起你, 你的工作也有可能被所谓的SDET所取代.)
  另外当QA找RD作test case review时, RD也不要认为这跟你没有什么关系, 你需要好好看看这些scenario你是否都已经考虑到了, 你可以趁此机会和QA一起brainstorm, 找出是否需求面或是设计面上是否有考虑不足的地方, 我想这时候花时间, 让之后你程序没有bug,或是bug较少, 这不是件很划算的事情吗?
  最后, 当然是manager也要改变心态, 需知道前面这些事情要发生, 要开花结果, 都是需要时间. 若是你缺乏耐心, 觉得怎么大家前面花的时间变长了, schedule怎么delay了, 因此而责怪, 责骂, 那只会让这件事情毁掉而已. 这时候你需要的就是稳住, 要信任大家, 也要让大家信任你是愿意要这改变发生.
  看到这里, 我想大家应该了解, 不是单纯让QA早点加入就好, mindset也是同时要做转变的.管理, 让大家能够真正以起合作.

posted on 2014-07-30 09:59 顺其自然EVO 阅读(949) 评论(0)  编辑  收藏 所属分类: CMMI & QA


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜