【心路历程】
尽管经历过通信、IT、医疗行业测试工作的锻炼。刚面对移动互联网QA工作时,我的内心是崩溃的。
只言片语的需求,天花乱坠的交互及其变更,虎视眈眈的产品和市场,再加上疯狂节奏的项目迭代,造就了繁荣景象。
与此同时,也顺带造就了一批批向死而生背锅侠-开发&测试同学。
每每临近版本发步,挑灯夜战的一定有赶上线进度、或准备上线、或正在上线的开发gg和测试mm;
因为延误上线,那是开发测试的锅。
发完版本的夜里,失眠者中多了几位开发&测试;
因为线上出bug也是开发&测试的锅。
怎么破???
【分析原因】
踩过足够的坑,背锅足够的锅后,我们来静静地分析一下原因,回顾一下事情的来龙去脉:
以当下还算热火着的智能设备APP为例,分析一下产品质量风险的来源。
<1>从版本的生命周期角度(纵向,时间维度):
产品策划设计->交互视觉设计->开发设计实现、联调->运维部署->售前售后服务 各环节输出蕴含着从大到小的风险。
<2>从产品的构成角度(横向,空间维度):
服务端(模块)、APP客户端(模块)、设备端(模块),所有的端(模块)实现及端(模块)之间接口定义&变动都是质量的风险。
<3>产品/策划随时随地的需求变更
以上的流程和模块的质量,本该限制在端(模块)或者本流程内解决。
但事实上,通常都在测试阶段,甚至版本临近上线才集中暴露。
原因其实很简单,一个该全面质量管理的工作,因为层层防火墙失效,变成了仅最后测试一道防线。
不知从何时起,测试工程师被重新定位为QA;从那一天起,其实质量的锅是甩不掉了!
【整理思路】
了解了现状和探究了原由,QA同学应该都自觉的调整定位了。我们是QA,我们是产品质量的QA,我们是全面质量管理的QA。
质量工作,其实是跟风险做斗争的工作; 质量的一生,贯穿着消灭风险的一生。
然而,我们也不要痴迷绝对质量,就像安全,绝对的安全是不纯在的,也是窒息的。
笔者理解的移动互联网QA工作,是“质量可控”、“效率优先”。说白话是既好又快。
【解决方案】
笔者有幸,前后参与了我厂两个智能设备APP项目,在主动请缨智能医疗项目QA工作后,积极贯彻“质量可控”、“效率优先”原则,尝试全面质量管理实践。具体措施如下:
1. 积极主动参与产品团队的软硬件需求交互评审,及时有效反馈产品在设计阶段的质量风险问题
目的:尽早了解产品定位、确认需求来源及真实性!最高收益的测试!
2. 主动配合项目管理工作,推进全面质量工作,规范质量相关的需求评审、交互评审流程和输出,通过项目管理日常推动流程建立、执行
目的:全面质量,严把设计环节的质量,是后续开发质量的前提!
3. 花最多经理在测试分析和用例设计,精心准备高效用例评审(会前澄清、会上同步、会后跟踪);推行100%开发冒烟自测
目的:测试前移,缩短缺陷修改路径,从而提高产品质量和进度!
4. 引入搭建移动测试平台(bugease),提高视觉走查、交互走查工作效率速度
目的:全员测试,激活视觉、交互、产品的质量把关作用,让最了解需求的人参与负责质量工作。
5. 积极主动与开发、项目合作搭建 质量相关平台,包括:需求交互评审(wiki /axure),任务缺陷跟踪(jira),用例管理(tc),后台部署(omad),前端APP打包(10086),发布(app)、持续集成(ci)。
目的:工欲善其事,必先利其器,掌握好工具平台提高版本整体开发测试效率!
6. 学习业务知识、深入各端技术架构
目的:测试前移的前提是,你得懂技术,比产品、开发都全而新!
笔者所在的POCT项目组,在项目管理支持下,在产品、交互、视觉、前后端开发和QA的通力合作下,在经历过残酷的6:1的开发比下,如期将产品推向了内测。
产品质量尚待检验,以上仅为个人经验,仅供参考!
【结束语】
一直把线上问题/Bug说成锅,探根溯源是个人心态问题。
其实我们可以发动每一个团队成员、把质量工作再做细致一点、用心一点,将背不完的黑锅变为捧不玩的奖杯(请自行PS成冠军奖杯)。
笔者完成了心态的状态,你呢?
本文来自网易实践者社区,经作者汪洋旦授权发布。