关于我在敏捷web测试流中的工作流程整理

关于测试流程的一个整理，起因是在工作中的时候，发现真正的工作流程没有那么的严格和细致，或者说没有这么死板和繁琐，所以具体执行的过程会根据项目（或者看心情）来简化工作流程步骤。

但是简化后的流程会有遗漏和不规范的地方，实际过程中也会由于缺失了一些环节，影响开发、测试过程或者最终上线；比如需求的不规范导致快上线了还不明确需求情况、开发进度不明确导致压缩测试时间、测试流程不严谨导致生产问题，各种各样等等之类的问题。

所以我发现每个项目中，如果开发、测试、产品、leader每个人都处在一个各自顾自己的分割状态下，那么在每个环节都可能会出问题。必须要有一个人可以从需求-开发-测试-上线这个迭代过程中监控全局；一般来说leader作为项目领导者，在这方面有优势，但是leader也很忙呀，要忙面试、催进度、项目问题、出差、和需求甲方周旋等等的事情，所以项目里事情总要有人做的，测试在这种情况下，就要有监控项目全局的主动思维。所以从项目开始就要：和产品催需求、和开发催进度、测试到位，一直到迭代上线后持续关注。

在每次迭代进程中遇到问题，我都总结起来，想出问题出在哪，以及解决方案是什么；主要来由测试这个岗位的职责来看能否解决问题，下面就是我自己整理的一个工作流程，不是很全面，但都是出过问题后，发现需要做的一些流程，也希望看到这些文字的同学也能一起探讨。

 

一：需求迭代开始

    1.需求评审会，清楚需求，并与产品大致搞清楚需求细节

    2.原型、UI与需求的对照（需要产品、测试过效果图）

    3.每个列表写需求说明，形成文档方便后期测试

    

二：测试前

    1.测试用例编写，及时与开发、产品对照具体细节

    2.考虑测试用例的测试范围、方法

    3.列出测试计划

    4.跟踪开发进度流程进度

    

三：测试中

    1.基础测试用例测试（保证生产环境测试数据）

    2.全量-主要流程功能测试（前端后台）

    3.交叉测试

    4.产品验证评审

    4.兼容性测试

    5.下架测试数据，生产系统还原

    

四：测试后

    1.生产持续验证关注问题

    2.测试问题总结反思

    

一些其他思考：

    关于bug的严重程度，是根据系统功能性，还是用户体验性来评判。

    例如一个功能的提示信息很笼统有歧义。对于系统功能来说并不怎么影响，但是对于用户看来可能就是很大的问题，会理解错意思。从功能层面来说是小问题，从用户使用来说算不是小问题。

又比如订单流程的一个判断逻辑写错了，但是造成的影响可能只是展示数据不对，状态也可能不大对。对于系统开发和需求层面肯定是一个大问题，但是对于用户来说可能根本不关注这个东西，对错逻辑也体验不出来。这种功能上的绝对问题，在用户层面可能是可以忽略的小问题。

    这个思考主要是针对bug严重程度划分时，不同的参考标准会有不同的结果。在实际测试过程中，这种问题要解决比较难；主要有两点：第一，从bug规范来说，我发现提bug的时候，有些人不管什么bug都是默认的严重程度，甚至有时候提bug只有一个标题，没有内容描述（不是初级测试，是工作了很多年的测试了，可能时间越久越来越随意？），这就需要测试团队统一bug的格式规范。第二，这种描述不准确、引导介绍缺失的问题，应该从产品设计层面就开始注意了，一个测试人员要针对产品的易用性提出意见，并且产品能够采纳是不容易的一件事。

所以实际测试中各种流程、标准能够精准执行吗？