Rethink-2018年中复盘 -IN QT Capital

对整个国内的测试行业来说，到现在为止都还只是处于一个起步发展的阶段 。大多数测试从业者在工作过程中处于测试的末端，做着枯燥的黑盒测试，工作辛苦，成长性小，找不到技术提升的途径。导致最直接的后果就是测试的价值体现被自身能力所限制，明明一直很努力，感觉工作忙忙碌碌，但能力却一直没有多大提升，形成恶性循环。

很久之前看过一个TED的演讲视频，里面提出了一个解决职业瓶颈的方案。演讲者做了很多调研，发现牛人之所以厉害，是因为他们能够在工作生活中刻意地在两个区域中切换：一个是学习区，另一个是执行区。 学习区是用来学习新的知识技能，在这块区域中，我们要做的是学习、尝试、更新、反馈、总结、反思等，从而不断提高自己的竞争力。而执行区是指从事我们的日常工作活动，比如测试跟踪bug，开发写代码等。 因此在工作中提升自己，让自己更强大的方法，就是在学习区与执行区之间相互切换，有目的地培养相关技能，然后再把这些技能应用到执行区。总而言之，我们在学习区待得越久，提升就越大。所以，如果要突破自我，就要增加学习区的时间。 执行区并非没有价值。当我们处于执行区的时候，虽然我们要避免犯错，但是不可能不犯错。犯错也是一种反馈，我们可以从错误中获得成长。

目前所在公司的技术团队，有一个不好的趋势就是团队越来越业务，越来越没有技术味道。此处并不是说业务不重要，而是说理解业务和把控需求是技术人员的base，绝不是全部。

这种技术氛围的缺失对整个技术团队来说是非常可惜的，也不利于技术人员的成长和发展，除非你是一个刚参加工作的新人。很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务需求，但是从长远来看，这种烂系统会极大的阻碍业务的发展，形成一个个的黑洞应用，而整个技术团队被裹挟在新需求和烂系统之间，疲于应对，心力交瘁，烂系统的归途也只有毁灭重构。

这种将就将导致系统腐化，技术债越垒越高，像肿瘤一样消耗团队中每一个人的能量。

在绝大多数的软件项目工程中，测试活动由于受限于时间成本和经济成本，只能采用基于风险驱动的模式，选择合适的测试粒度，即有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重的作用。

关于绩效考核

“零和游戏”之困

开发部门（RD）和测试部门（QA）都是企业生产服务链中的重要节点。在企业中大多存在绩效考核制度，并往往搭配一定的强制手段，比如和员工的利益相绑定等。这种绑定就需要我们能对员工的工作表现进行一个相对公平的分解和量化。建立考核制度的出发点肯定是好的，一套优秀的考核标准，对企业和员工来说都是双赢的，但是如果要考核的KPI指标有失公允，那考核实施的效果只能是适得其反。

QA 通常定位为“质量保证”的角色，自然地，他们所发现BUG的数量和严重程度与其绩效潜移默化地有着紧密关联。于是QA为了提升个人绩效，就会尽可能在缺陷跟踪系统中新建缺陷记录，但对于RD来说，缺陷数量同样可以作为KPI指标以衡量其开发质量。进一步可能会出现这样的工作场景：QA发现问题后，首先与RD进行沟通，在征得RD的同意后再新建缺陷记录，这个过程有时变成了一种博弈，而非真正为了工作效率。更糟糕的是，RD对于QA所发现的问题不是持感激态度，反而认为他们是在“找麻烦”。更更更糟糕的是，由于QA部门的存在，RD心安理得地认为保证软件质量是测试部门的事。 不难发现，这样的体制下其实创造了一个“零和游戏”，这个游戏给我们带来的困境是：测试部门的“赢”：发现了更多的缺陷，意味着开发部门的“输”：开发质量不佳，反之亦然。总而言之，两个部门很难达成共赢，有时甚至出现更糟的极端状况。

关于KPI量化的思考

为了尽量少的避免出现零和效应的局面，我觉得将技术团队的KPI分解为业务贡献、技术贡献和团队贡献三个部分比较合适，其详细内容为：

• 业务贡献：包括需求把控，业务项目和业务创新等；
• 技术贡献：包括设计重构、技术研究、Code Review和性能提效等；
• 团队贡献：包括技术文档、团队培训和新人培养等方面；

具体的KPI考核维度，我站在QA的立场上，做了以下的几点思考：

1. 绩效考核应该包含自评的部分（参考bilibili）
2. 以结果导向进行考核为主，而不是过程导向。比如建议降低使用BUG数、Case数或者上线需求数等指标所占的百分比，使用此类指标来进行考核，太机械化，充满了目的性。
3. 维度

• 本职工作的工作成果

本职工作是否按时完成？完成过程中展现的能力和推动力如何？

• 创新性思想

在做好本职工作之外，是否有为提升岗位的工作效率付诸具体行动？

• 团队效益

输出创新，提升团队效益，比如进行项目总结和团队技能培训等；

• 成长速度

个人能力提升速度，学习速度等方面；

• 工作态度、积极性

团队正能量，从工作态度等方面综合考量

职业规划

对于一名QA来说，首先需要具备基本的软件测试理论基础，其次要能展开工作，还必须要了解业务背景知识；要想更多的发现缺陷和更准确的定位缺陷，还要学习WEB系统或移动应用相关技术知识；要更进一步，全面提升软件质量，就要从代码、安全、性能和健壮性等多个层面去着手； 一个优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易于发现问题的测试用例。如果你不能对SUT的设计有深入理解，不明白安全攻击的基本原理、没有掌握性能测试的基本设计方法，很难设计出有的放矢的测试用例；

测试价值的体现需要一个过程，包括对这个行业的认知过程以及测试人员给自己的定位过程，这其中以测试技术以及质量管理为导向的专业化测试服务路线是我最感兴趣的。

总结一下，可以从以下五个方面开始做起：

• 作为测试人员，业务能力应该摆在首位的，公司的业务多且比较复杂，熟悉业务知识，对产品有深刻认识是基本要求。测试过程中，应该先谈业务再谈技术，保障业务是底线，通过技术去提高工作效率是途径。
• 以自身公司产品为导向，首先确立真正适合公司的测试方法论，然后再去规划部门测试技术发展方向，引导测试团队往测试研发团队转型，把黑盒测试往灰盒、自动化技术方向提升。可以尝试结合公司情况，对现有的各种测试工具进行开发，搭建自动化测试开源平台，提高工作效率以及专业化程度，形成创新氛围。
• 适当的量化工作成果，使用数据度量工具进行数据归集统计，尝试去规划质量平台工具，把质量体系建设的层面做好铺垫。
• 把自我认知从软件测试提升到质量保障，在质量的大体系下，我们的职责不仅仅是把软件的功能测试好就可以了，而应该从根源，比如：流程、规范等等去约束项目组，保证软件质量。当然这一点前提是需要自上而下的质量体系建设以及推动。
• 找到自己的长处纵向深入的同时，制定横向提升的方向。提高自己在团队中间的核心竞争力，无论是自动化测试、性能测试、安全测试或是精通业务等等。

测试用例评审

• 评审目的

1. 避免因三方需求理解不一致而导致项目返工的情况出现；
2. 减少测试人员执行阶段做无效工作，如执行无效case，提交无效问题等；
3. 确保每个测试人员的质量标准与项目要求标准达成一致。

• 评审前的准备工作

1. 需求评审结束后，就可以着手把需求拆分为功能点的测试用例，粒度自己把控。建议使用XMIND，用画思维导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。
2. 用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。；
3. 和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看；

• 用例评审参加人员

主要是产品、开发（客户端和后端）、测试、项目负责人、运营。等。

• 用例评审时间

对于敏捷开发项目，建议控制在半小时以内。

如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。

• 用例评审过程

1. 评审要按用例的优先级，功能的复杂程度进行；
2. 评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3. 遇到用例中有错误的地方，需要作出标记，便于会后修改；
4. 超过5分钟无法确定结果的问题，留作会后跟进问题。

• 评审结束后需要做些什么事？

评审结束后，第一时间整理测试用例，把评审过程中修正的内容重新整理补全，会上未确定的内容，会后继续跟进，直到确定结果。

---

一言以蔽之：质量取决于团队的能力 。

---