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/
相关文章
|
5月前
|
数据采集 监控 JavaScript
移动端性能监控探索:鸿蒙 NEXT 探针架构与技术实现
阿里云 ARMS 团队倾力打造的鸿蒙 NEXT SDK,为鸿蒙应用提供了业界领先的全链路监控解决方案。这不仅仅是一个 SDK,更是您洞察用户体验、优化应用性能的智能伙伴。
754 48
|
Python
python变量未定义(NameError)
【7月更文挑战第13天】
1573 11
|
传感器 物联网 Linux
物联网设备的操作系统之争:Linux vs RTOS
【6月更文挑战第4天】在遥远的数码星球,物联网城中的Linux先生与RTOS小姐展开激烈角逐,分别在操作系统领域各显神通。Linux先生以其开源、兼容性强、功能丰富占据服务器、桌面及嵌入式设备市场,适合处理复杂任务和需要强大计算能力的设备。而RTOS小姐以实时性、高效响应和低资源占用见长,适用于资源有限、强调实时性的物联网设备。设备制造商在两者间抉择,引发物联网设备操作系统的选择大战。通过Python与FreeRTOS示例,展现了两者在智能家居和生产线控制等场景的应用。在物联网世界,Linux与RTOS共同推动设备智能化,为生活带来更多便捷。
812 3
|
弹性计算 Kubernetes Cloud Native
云原生技术的实践与思考
云原生技术的实践与思考
216 2
ceph集群用户管理实战指南
这篇文章提供了Ceph集群用户管理的详细指南,包括用户格式和权限说明、创建和删除用户、修改用户权限、用户备份和恢复,以及如何导出和验证用户授权文件。
352 1
|
存储 监控 NoSQL
结合通义千问对CentOS靶机进行入侵排查
本文介绍了一种在Linux系统中记录所有登录用户操作历史的方法,通过在/etc/profile中添加脚本代码,每次用户登录时会自动生成一个包含该用户操作历史的文件。同时,文章还提供了多种查看系统登录记录和日志的方法,如使用last, last -f /var/log/wtmp和cat /var/log/secure | grep 可疑IP等命令,帮助管理员监控系统活动和排查异常行为。此外,通过rpm -Va命令可检查文件完整性,识别可能存在的安全隐患。
|
Windows
显示器设置
显示器设置
402 2
|
编解码
技术心得:常见电脑屏幕分辨率
技术心得:常见电脑屏幕分辨率
2703 0
|
前端开发 JavaScript
Uncaught (in promise) Error: Request failed with status code 500
Uncaught (in promise) Error: Request failed with status code 500
1257 0