基于上一篇文章 *测试人员,为什么要学习一门技术?(一) *, 我们理解的大部分测试行业的同学遇到的难点痛点, 那么, 我们今天来聊聊第一个痛点, 业务基线管理的那些事情

基线管理

首先, 我们来聊聊文档管理, 在日常的测试工作中, 我们总会需要和文档打交道, 文档可以更好的作用于跨部门协作, 产品通过文档明确需求, 开发基于文档review进行确认后开发, 测试人员的测试基准也来源于文档,那么文档有哪些呢?,得到文档后我们需要做些什么有意义有价值的事情呢?

• 需求文档 (产品定义的需求描述文件)

  • 需求文档, 往往在于需求定义初期就需要存在了, 至少这是符合软件开发过程的一件重要的事情
  • 业务流程图, 这可以帮助你完整的考虑清楚业务的整体运转情况
  • 在拿到文档后, 我们要做的事情是理解文档需求, 并与产品/开发人员一起坐下来, 来一次产品需求分析, 这样可以在需求理解中理解所有人对这个需求的看法, 并且拆解这个需求的原本意图(这有利于测试人员在后续的测试工作中深入测试)

• 设计文档(开发人员对于开发内容的描述与解释)

  • 开发文档, 一般是开发人员的开发描述性文档, 主要用于业务的功能开发的描述与记录
  • 接口文档, 大家都有听说过接口测试, 那么需要接口测试肯定要有一个完整的接口描述文档, 不然难道需要测试人员通过抓包和猜来做这件事情么???(黑人问号脸), 所以这个时候, 接口文档就尤为重要了, 减少了开发人员与测试人员的沟通成本, 又可以让测试人员通过接口文档中的定义来追溯问题
  • 版本更新文档, 顾名思义, 根据不同的版本记录更新内容, 例如: 1.0版本为初始版本, 1.1版本增加了哪些功能, 1.2版本中我们优化了哪些看不到但确实很有用的东西

• 测试文档(测试计划于实施过程整理)

  • 测试文档一般由leader 来制定与设计, 用于一个版本周期中的测试分配与安排(我们需要几个人来做这个业务的测试?/我们对需求的理解与业务测试的时间成本控制?/我们的测试人员是否可以在固定的周期内完成这件事情?/这里有哪些风险等等)
  • 测试用例, 这个文档我想大家都会在日常的工作中用到, 接触到,并且维护了自己的用例库(例如:excel/testlink等), 测试用例, 在测试人的工作中, 是必不可少的利器, 他可以减少你猜测的成本,通过测试理论方法(如:正交/因果图)增强业务测试的覆盖面的前提下, 尽可能的减少重复的用例测试工作

讲了好多文档, 然而我们在工作中并没有文档, 甚至连它是个什么样子都一无所知......

如果我什么都没有, 我该怎么办?

这个时候,我们发现, 因为各种文档的缺失, 导致我无法开心的完成我的工作. 今天找产品确认了一件事情, 第二天还记得, 第三天忘记了, 然后发现了一个相关逻辑的bug, 当你质问或觉得这个设计不合理与产品理论的时候, 产品人员一脸无辜(我三天前有告诉过你为啥这个样子好不啦?)

文档很重要, 我们没有文档, 我们测试人员不被重视, 我们巴拉巴拉巴拉........

来吧, 做点有意义的事情, 比如, 我们先推动自己部门来完善文档, 那么如何去做?

• 需求评审ing......

  • 在需求评审会议, 拿起你的小本本, 记录每一个你理解的需求, 仔细的询问每一个你思考过的细节
  • 认真的听每个人的问题, 开发人员的疑问, 产品人员的设计解释, 流程图的过程分析
  • 思考以往的产品更新中可能存在的问题(比如更新现在的系统是否对原有系统有影响)
  • 把他们统统的整理与理解之后, 记录下来.

• 会议结束后......

  • 与相关的产品人员确认细节点, 每一个你记录下来的内容, 都很重要, 需要认真的确认
  • 需求确认完成, 你需要做一件很重要的事情, 在公司的业务群组(QQ/RTX等) 发一下你记录的确认测试内容, 并且以邮件的形式, 发给各个部门的接口人(产品/开发/测试), 这很重要

• 测试文档与过程的整理

  这可能会需要一点时间, 磨刀不误砍柴工, 希望你不是只有自己一个人在测试, 不然这很难办

  • 开始通过你会议记录的内容, 来完整的编写测试用例, 如果项目紧急到连编写测试用例的时间都没有, 那么我觉得这需要通过另外一个classify来解决问题

  • 编写用例后, 我们需要做的就是按部就班的测试了对不对?

问题来了?

我做了这么一大坨的浪费时间(至少看起来是这样的)的事情, 我为什么要这么干?

众所周知, 如果你需要在公司内部推动一件事情, 最好的办法是从上至下来推动, 是最快捷的, 而从下至上几乎是不可能成功的, So 我们需要做的是, 在测试工作中, 让更多的人发现如何做正确的工作, 文档是很重要的一个环节, 在以往的例会中你们也没少对文档中的不明确, 没有完善的问题伤透了脑子吧.

我们要做的, 就是通过我们部门内的一小步变化, 逐步影响到其他部门(当然这有些扯淡, 毕竟我们连改变自己都成问题, 怎么会改变别人呢), 然后把成果展现在leader的例会中, 我们测试同学们, 做了哪些重要的工作, 在工作中对文档的需求逐渐增加到不可或缺, 而且确实能给产品质量提升带来价值. Why Not?

从来没有人, 是生下来就会跑的, 在公司高层没有变动的前提下(突然空降了一个测试理论比你还厉害的CTO???), 我们要做的, 也并不是改变一个公司应该如何如何, 我们要做的, 是从最基础的实践中, 把理论与环境相结合, 找到最适合自己的方法, 但是..... 我们上述的方法 是非常好的一个实践方法, 为什么不去试一试呢?