![]()
QA在功能开发过程中，不应该仅仅局限于自己的测试任务，想要成为一名优秀的QA，除了具备卓越的测试技能，也需要有统筹进度的能力来做好跟进，确保产品质量。
测试职能作为游戏功能上线前的最后一道关卡，可以说在整个功能的开发过程中但凡有一点“风吹草动”，都会像蝴蝶扇动了翅膀，测试工作都会受到一定的影响。在过去的工作中，从刚开始接触测试工作时，有PM详尽的跟进功能进度；到PM空缺由各个职能接口人进行协商管理；再到自己作为接口人参与到功能进度沟通当中，逐渐认识到想要做好测试工作，在功能开发的生命周期中我们需要主动参与其中，来确保测试工作的有效性和效率。
我相信大家在工作上都有遇到一种情形，接到一个kickoff或者是三方的需求，在会上经过大家激烈的讨论过后，各个职能确认了自己工作的预期完成时间，自己也回去如约完成用例的编写，等待测试任务的来临。然后在某一天突然程序或者PM找你沟通说，因为某某原因，这个功能暂时还没做完，亦或者到达约定的提测时间你去询问进度，发现已完成部分不太理想，导致无法如期开始测试。而版本的发布往往都没有商量的空间，随着日子一天天过去，测试时间不断的被压缩，等到提测之时不得以加班加点的赶进度，功能质量或多或少都有一些影响，等到上线后复盘的时候，哀叹一声提测太晚影响了自己的测试计划，下次要保证充足的测试时间，让策划提早出方案，而且因为加班好几天也搞得自己身心疲惫，丧失热情。这个场景在我过去的工作中可以说是屡见不鲜，尤其是在项目处于PM空窗期的时候，开发进度推进基本全靠QA来跟进时，可以说每一次的大版本发布我们都会有功能遇到这样的问题，甚至于平时周版本都会出现熬夜通宵的情况，这种工作节奏显然是不合理的。等到自己作为接口人一起参与到项目管理中时，发现即使是作为测试，我们也应当具备一定的项目管理思维，来帮助我们制定测试计划，保证产品的质量。
02 项目管理
什么是项目管理？虽然在工作中时常都能听到这个词，但是作为管理学的门外汉，其实我是不太懂的，我们来看看chatgpt给出的回答：可以看出测试和项目管理是有很多相似之处的：都对功能有质量要求，都需要进行计划和组织，都有一个明确的目标导向，都要进行风险管理。测试的风险管理往往是在功能出现bug该怎么控制，如何监控潜在问题或者预测带来的影响，这是我们的职能要求，但很多时候我们没有思考自己的测试计划在项目管理上的风险，进而在功能进度发生偏差时，我们的测试没有办法很好的完成，影响到了功能质量。尽管测试与项目管理是两个不同的领域，但在实际工作中，具体到某一个功能开发时，二者还是有很多交织之处，我们在测试工作中可以应用项目管理的思维来帮助我们更好的完成测试工作。
项目管理通常分为五个阶段，这些阶段构成了项目管理的生命周期，这五个阶段分别是启动（Initiation）、规划（Planning）、执行（Execution）、监控与控制（Monitoring and Controlling）、闭环（Closing）。在各个阶段我们该做些什么来帮助我们做好测试工作。结合我自己的工作经历，这个阶段的开始我一般认为是策划给出需求文档。在项目管理中，启动阶段通常会定义项目的目的、目标和范围，并确认项目的可行性，作为测试，在这个阶段我们要做的关键就是明确我们测试目标，确认功能实现的可行性、测试的范围与内容、最终要交付的效果。在这个阶段我们作为测试，有哪些是我们可以做的呢。
·推动程序参与文档分析
做文档分析的好处，我相信大家都能达成共识，将测试左移，使问题在设计阶段就挖掘并解决，修复成本将远远低于在功能实现阶段才发现，第二点好处是策划有时候并不了解功能具体实现的难度及可行性，有些“天马行空”的想法在落地的时候成本会远超预期，等到三方会议上再被否决打回重改，无疑是让进度受到影响，当然作为测试，我们对于代码的理解程度虽比策划好上一点，但仍然是远不及程序同学，所以文档分析也离不开他们的参与。当策划给出功能的需求文档后，到确认三方时间一般都会有一段时间，在这个期间作为文档分析的发起者，我们除了做好自己的文档分析工作之外，也要督促程序同学从他们的角度进行文档分析，并让策划及时回复，毕竟大家对于文档都有自己的理解，仅仅依靠在三方会议上这么短的时间很难全盘理解文档中的每一处描述。而且做完文档分析也相当于确认策划、程序、测试三个职能都明确了想要实现的目标是什么，至少对于文档中要实现的功能大家都无异议，等到后续出现争议时，也不会出现甩锅现象。 ·跟进提交时间
在三方确认完要做的内容之后，各个职能都会给出一个预计工时，但这个的准确程度很依赖于工作经验，一般来说经验越丰富的同事，给出来的估时准确的概率越高，但我们肯定不能完全把自己的命运交给他人，但凡有一个环节出现了延期，作为最后的测试环节，被压缩时间是必然的，虽然PM会帮我们盯着进度，但我们自己也要了解各个职能的提交节点，例如交互什么时候给到，功能板什么时候能交给客户端同学等等，在各个提交时间主动去确认开发进度，当某个环节出现问题时，能及时了解并调整自己的测试策略，而不是等到了提测时间才意识到进度赶不上了。主动出击好过于被动等待。 ·确认中期时间及内容
从过往的经验上来看，功能进行中期演示最后完成质量会高很多。一方面文档中所描述的效果在做出来之后会发现有部分内容需要修改或者有功能遗漏（基本无一例外都有优化意见），另一方面确保程序同学有目的性的优先实现功能的主体框架，即确定P0级开发内容，同时测试这边能提前介入一些基本功能的测试工作。之前遇到过功能开发比预期时间要长，提测时间要延后，但测试时间本来就比较紧张，于是沟通看是否有哪些内容能够先提测看看，一些非必要功能可以有选择性的后发布，但就是由于在三方的时候大家未明确，有些P1的需求已经做完了，但核心部分还有些问题未解决，导致基本流程都跑不通。所以在启动阶段，最好就让PM确定下中期的时间，作为一个节点来督促前面的环节能够按期提交，而我们通过P0的需求来为后续测试用例执行设定优先 这个阶段在项目管理中是至关重要的部分，因为它涉及到所有计划的制定。于我们测试而言，这期间的主要工作就是基于功能需求及协商的开发时间，制定我们的测试计划，比如进行用例设计，确定时间表，协调所需要的资源，做好风险管理。项目管理会使用工作分解结构(WBS)来细化任务，确定里程碑和关键路径。我们也可以借助这一工具来辅助我们制定测试计划，以可交互成果为导向将有助于集中于具体功能的实现质量。这里不展开讲，有兴趣的同学可以去了解一下。·测试用例驱动自测
测试用例的质量将很大程度影响我们之后的测试质量，一份好的用例也将有效提高测试效率。无可避免的是，我们在设计时从测试的角度考虑问题会有遗漏或者视野缺失，当然我们可以通过让其他测试同学来评审用例帮助我们进行完善。但我们也可以考虑将测试用例发在沟通群中，让策划及程序一起参与测试用例的设计中——策划作为需求的发起者，他能够从功能覆盖面发现问题，程序则能从代码实现的角度提供用例思路。将用例提供给策划及程序也是为他们自测提供思路，驱动他们进行自测，尤其是当程序接收到我们的用例，提交就能有标准进行自测，对提高提测质量将会有正面帮助，毕竟提测质量提高，后期执行阶段“返工”的就越少，整体的效率就越高。·主动跟进开发进度
在开发阶段测试的工作其实并不太多，但这并不意味着我们在写完用例之后就保持“静默”，只是被动的等待提测时间来临。虽然说我们并不是PM，更不具备PM的职权，但作为最后质量的把关者，为了避免被占用最后的测试时间，对于当前的开发进度一定是要有所了解的，当开发进度明显与预期不符的时候及时拉上所有人调整计划，提前预警做好风险控制，同时主动跟进也是避免计划出现调整但未同步到测试端，导致我们测试计划没有及时更新，毕竟在开发过程中发生需求变动是常有的事。有的同学可能会比较“社恐”，不知道该如何不惹人“厌”的去反复跟进进度，毕竟一直和开发同学确认进度确实很容易引人反感，这也不是我们的职权范围，所以最好是在启动阶段，让PM同学牵头确认一个同步周期，例如每周五下班前在沟通群中同步一下当前开发进度及问题，我相信PM同学也很乐意去推进流程能够如期进行。 当程序完成代码提交，策划也配置了测试数据后，我们的测试任务也正式从计划落到实际行动。在这个阶段我们会有成果的输出，并且随着在测试过程中一些bug被发现，需求也会有频繁的变动和优化，所以在执行阶段，我们要确保职能间的沟通和协作高效。 ·将口头沟通及时化作文字记录
为了保证沟通的及时及表达准确，我们经常会当面沟通问题，这些涉及到当面确认的问题往往对这个功能的测试都很重要，所以我们需要养成良好的习惯，将口头沟通的结果总结成文字版记录下来，最好是发在功能开发群中，一方面是和沟通的同学确认沟通的结果是符合两人的预期，没有产生理解歧义，第二是避免工作忙碌导致的遗忘或者是后期产生争议各执一词，并且也可以和其他同学进行同步。尤其是一些需求发生变动时，要让策划及时在需求文档中进行更新，如果发生遗漏后续会对开发进度造成严重影响。 ·保证流程规范
随着工作的熟悉程度变高，对工作的流程规范会逐渐失去敬畏之心，这显然是不可取的。我自己常犯的一个问题，在功能测试有一个简单的描述问题发现后，没有开单记录，只是口头和策划讲了，后面由于其他事情一多，这个问题我们两都忘记了，等到上线后才发现这个忘改了，还得刷一个热更，可以说是自食恶果，功能质量败于一个低级的错误。我们可以说有一些流程要花费时间，在某些情况下完全是效率低下，但是不可否认的是，规范化流程在大多数情况下是有助于减少不必要的步骤和重复工作，减少了差错的发生，我们不能盲目相信自己能做好一切，毕竟测试就应该对功能中的一切保持怀疑，当然也包括自己。如果对一些流程规范觉得不合适，可以在复盘时提出优化意见，重新制定符合当前现状需求的规范，而在平时的测试过程中，还是应该严格保证流程规范，保证效率和质量。一个好的测试需要具备的能力之一就是要有风险控制能力，不仅是在功能质量上能识别风险，预防问题发生，对自己功能的开发进度也要做到心中有数，尽管说这是在PM职权范围内，但我们作为“受害人”，要保护好我们自己的测试时间，也要参与到监控进度中来——在启动阶段大家都确定了提交时间，要时不时的确认当前进度是否符合规划，及时对开发风险作出响应。 ·做好测试报告
在要求别人能按时提交的同时，也要保证自己的测试进度也是在如期进行，不能严于他人松于己。对于其他职能而言，测试的进展也是不透明的，所以在测试的过程中我们要做好测试报告，将当前完成的工作及遇到的问题都做好记录，能有一个定期同步。 ·不要闷头自己解决问题
当监控到当前进度存在风险时，如果能自己内部沟通解决固然是最好的，但是当你无法独自推进下去时，要及时向上反馈或者寻求其他人的帮助。有些时候碍于自己的能力，在一些问题上依靠自己一个人确实是很难推动的，可能闷头做好几天也抵不上别人花一小会功夫就解决了。尤其是在一些职权问题上，要尽早意识到自己不具备解决这个问题能力，尽早向外求援，千万不要等到事情已经到了最后关头才追悔莫及。对于我们测试而言，只要功能还在线上运营，我们就未真正的闭环，毕竟线上环境的变化就可能会导致新的bug出现，也会有隐藏的bug还未被发现，功能没有bug只是暂时性的，当功能上线稳定后只能说工作暂时告一段落。 ·推进文档维护
当功能上线稳定后要及时完善测试文档，便于后续功能交接及其他人使用功能，在有优化需求完成之后也不要忘了更新维护，不然等到时间一长连自己都忘了功能有哪些地方改过了，给后续的迭代工作带来极大的麻烦。 ·流程优化思考
当流程反复出现风险及阻塞时，作为QA我们也可以发起流程优化，而不是仅仅只是简单复盘，没有落到实际问题的解决。之前组里周版本经常出现功能上线前一天通宵测试的情况，可谓是苦不堪言，每次都复盘说功能提交太晚，但却没有实际的方法应对。后面开始求变，在版本日进行卡点登记，通过云文档记录原因和最后测试完成时间，并同步给其他职能接口人。当手上积累了充足的“证据”，便找到其他职能的接口人共同探讨流程问题。测试没有完成，其他职能也没办法下班，而连续出现通宵现象，大家的工作状态都受到影响，所以这是共同的痛点，大家利益一致。后经过协商，认为deadline等同于发布时间，于我们而言缺乏缓冲时间，遂决定将版本日前移一天，倒逼提交时间提前。不得不说的是，虽然其他职能的deadline少了一天，但提测情况好了很多，进度风险会更早被预警，提前介入解决，虽然偶尔还是会有加班现象，但周版本发布情况明显好转。QA在功能开发过程中，不应该仅仅局限于自己的测试任务，想要成为一名优秀的QA，除了具备卓越的测试技能，也需要有统筹进度的能力来做好跟进，确保产品质量。以上是我基于自己工作的一些经验思考，大多是主观的内容，受限于个人能力并不全面，希望能让你有所收获。
![]()
![]()
复盘：别让你的经验白白浪费
游戏兼容性测试工作分享
客户端性能优化测试心得
![]()
都看到这里了，点个赞再走吧~
