文长慎入
当QA有些时日了 分享一下
我和很多人一样对QA的工作分际到底是什么有些疑问? 不同公司，组织，人理解都不太
一样 有必要彼此厘清清楚 这样开发与测试流程才能好好的运作
光是要厘清说服 必须相当理解所有的细节包括开发的想法与盲点? 哪类的测试是哪个
角
色来负责较为恰当 unit test,build test,functional test, integration, performanc
e .... 测试也有分阶段分层次 唯有亲身历经才会有较深的感受
我个人会把QA跟SDET当成是不同的角色 虽然常常有人混为一起谈
我的定义里QA的角色较接近使用者的想法与感受 能把关产品经理或专案经理的需求跟使
用者的感受 越是不理解开发者越好(避免洗脑 开发者常常会说这是framework的问题啦
这有效能的极限 不能这样操作啦! 使用者会理解吗? 就是不买不用而已) QA只要理解使
用者的需求就好 测试可能也是较为手动的方式
而SDET的角色较为接近开发者 最好本身有过几年的开发经验 这个角色深知开发者的一些
习惯与盲点 透过自动化测试来确认功能的正常外还需要确认一些例外状况的处理 还有开
发者的设计逻辑会不会影响效能 当然这也可以透过其他测试来达到?
这是我常常喜欢举例的case
"从web用A帐号送一封信给B帐号 然后拿起手机app用B帐号登入去收信 结果收不到信"
通常QA就是这样描述 这也很正常 因为这就是使用者的行为
但开发者有web-front-end server-back-end android-app QA到底要找谁问啊？只能一个
一个问
web-front-end: 我看log有送出去喔 应该是后端有问题
server-back-end: 看来是有收到 从log看也有push到android-app
android-app: 手机我看一下ōo边没收到啊! 当然秀不出来
QA:干你老师! 那信是跑去哪了? 每个开发者都说自己没问题?
如果是一个好的SDET就能直指是哪出问题 且知道要问谁还能帮他找出问题点 毕竟SDET自
己也要开发 思维上较接近开发者 比较能知道开发者需要什么才能debug 还能告知哪边加
个log比较好厘清
Web>back-end>db>back-end>android(service>db>ui)
问题可能发生在上列的任一点上 可以透过自动化测试来逐步厘清 (只是带观念省略一
些细节)
SDET较著重于自动化测试包括功能效能结构数据库设计都可以提出建议
QA除了使用者行为的测试外，可能要多反馈使用者的感受 也许UIUX需要调整
两者角色都很重要 几年下来的感觉是?
QA最好是有产品背景的?
SDET最好是有开发者背景
但好玩的是
有产品背景的喜欢当产品经理
有开发背景的觉得测试很low
个人觉得好的SDET真的不容易要模拟的情境很多 写的code也不比开发者少 通常会更多而
已 当时程被延误最后都会是压在测试上 有问题改版再改版 回归测试决不能少 只能透过
自动化且还要跑的快 这还是api能解决的
如果要连前端的Web,App要自动化也没办法急 没事只要前端开发者心血来潮rename个obje
ct id就能搞死你 所以测试也会慢慢有自己的framework自己的configuration方便快速调
整 refectory更是家常便饭 不然要cover一堆需求的改变 新旧相容 很快就会难以维护
最后就会便宜行事(手动测一下这次改的部分) 品质下滑的开始 因为时间不会多给但要co
ver的范围更多更广 还有一些side-effects 所以不自动化是很难短时间快速验证的 但又
变得越来越难维护 扯远了
所谓专业是要能指出问题论述有理 有凭有据(log) 能被接受 甚至不得不接受 没有模糊
一堆人瞎猜的空间 这样就不会有吵架的空间 大家乖乖的回去修bug或加case让系统更好
更完善
这就是我认知的专业测试
※ 编辑: jl40 (61.228.234.104), 12/05/2018 00:27:54
※ 编辑: jl40 (61.228.234.104), 12/05/2018 00:28:58