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也是同时要做转变的.管理, 让大家能够真正以起合作.


最新内容请见作者的GitHub页:http://qaseven.github.io/
相关文章
|
11月前
|
机器学习/深度学习 人工智能 自然语言处理
中国大模型时代新Linux初显!FlagOpen大模型技术开源体系发布
中国大模型时代新Linux初显!FlagOpen大模型技术开源体系发布
254 0
|
安全 定位技术 UED
测试思想 QA的价值体现
测试思想 QA的价值体现
108 0
|
弹性计算 网络安全 数据安全/隐私保护
阿里云体验实验室QA
有关体验实验室问题可以在以下内容中寻找答案,如未找到答案可以在文后提问 或者加入体验实验室群聊 寻找管理员解答
阿里云体验实验室QA
|
编解码 Java API
揭秘!开源软件背后的神秘组织
Flink 社区将分享“走进 ASF”系列内容,先从宏观介绍 ASF 是如何运作的,然后详细解说如何参与 Apache 具体项目做贡献,如何成为某个项目的 Committer、PMC 成员,如何选择多个 Apache 项目进行多领域贡献并成为 ASF Member 等,希望有助于你真正了解开源、参与开源。
|
存储 编解码 前端开发
如何参与医疗软件开源项目
作为一名软件开发人员,我觉得我可以产生巨大的影响。在某种程度上,我觉得帮助一家披萨连锁店提高在线销售额或帮助抵押贷款机构提高利润率是一种浪费。随着 COVID-19 大流行的全面爆发,我想要帮助一个与我息息相关的项目。

热门文章

最新文章