 测试左移应该怎么移？是不是测试就应该去帮产品经理梳理需求，帮BA分析系统需求。不，我认为在敏捷中测试左移要做的是尽早的去介入测试，从需求评审的时候多问问产品经理，做这个需求的价值在哪里。不需要否认产品经理给出来的解决方案，往往产品经理发的需求是从业务方获取的，业务方是整个公司最靠近客户，知道客户有哪些痛点亟待解决的人。作为测试应该从以下几个方面进行左移： 1、基于用户故事进行用例设计 设计 什么是用户故事？用户故事在软件开发过程中被作为描述需求的一种表达形式。 为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。 所以用户故事从需求角度描述就是一个用来确认用户和用户需求的简短描述。所以针对于这个需求测试可以进行一些测试功能的测试设计。此时测试应该根据用户故事并且结合系统来进行测试用例的设计，例如作为一个app用户，我想要登录来进行商品浏览。那么这时候测试要考虑的是，哪些地方需要登录，登录有哪些场景，登录的token失效时间等等，这些都是需要去考虑的。 2、针对AC和DOD进行关键价值验证 标准 AC（Acceptance Criteria，验收准则），用户故事的验收标准包括快乐路径（Happy Path）与意外场景（Exceptional Scenario）。对于使用的客户来说，这些是能产生直接或者间接的经济收益的功能。所以这些关键场景的验证能给项目带来最大化的收益。作为测试来说，也是要有效保证这些AC的成功验收。 DOD（Definition Of Done，完成定义），如何理解完成定义呢？完成定义是Scrum团队大家自己来制定的规范。这里表示一个用户故事符合这些规范了才能定义为完成，不同的活动有不同的完成定义。每个团队的DOD都会不一样，这个时候是开发要针对这个用户故事进行测试。 3、寻找测试的价值 价值 作为一个敏捷测试工程需要实现端到端的价值交付，需要具备传统QA+QC的双技能栈，不仅需要拥有测试的技能栈还要跳出测试的思维，从更宽更广的维度去看问题。不要每天去跟开发纠结这里的文案问题，那里的样式问题。我们需要从更高的价值维度去思考当下的问题。 相关文章： 
|
|
|
