• 敏捷测试实践


    在绝大部分团队里面,大家遵循的流程都是开发->测试->发布这样的过程。在开发完成后,交给测试进行集成测试,发现Bug后提交给开发,开发再修改这样直到缺陷都被修复。这样的过程导致一个问题:在一个Sprint中,必须留给测试足够的时间,否则会无法交付。而且测试在一开始会比较无所事事,而到了后期又特别忙。我们曾经有个Team,最后采用方法是在一个2周的冲刺内,一周用来测试。这样的过程很显然不够敏捷,效率也不够高。

    还有一个传统的问题是开发和测试的矛盾。由于在传统的过程中,开发和测试是对立的,经常引起各种争吵。我经常看到是开发抱怨测试怎么能这么测,这么测有什么意义?但测试就认为这是个Bug。甚至有时候双方不能就这是否是个Bug达成一致。

    我们在经过一些回顾后,采用了如下方式,收到不错的效果:

    • 在Sprint开始后,测试立即对UserStory编写检查项。这些检查项大部分就是1句话,表明测试准备对这个UserStory做哪些检查。比如对一个登录功能,其中一个检查项是:连续输错验证码4次,验证码应该失效。
    • 开发人员在开发中,仔细阅读检查项,并根据UserStory和检查项一起进行开发,并按照检查项自测功能。
    • 开发完成后,测试人员立即到开发人员机器上,观看UserStory开发结果,并按检查项进行检查,同时,产品会对功能进行验收。

    这样测试人员的工作就被平摊到Sprint各个阶段,不会出现最后才参与。而且由于检查项事先写好,不容易出现开发和测试扯皮。同时这样是把测试人员作为开发Team中的一员,他职责不再是找Bug,而是协助开发人员开发合乎要求的产品;最后是整个团队更加高效、和谐。

  • 相关阅读:
    Jzoj4822 完美标号
    Jzoj4822 完美标号
    Jzoj4792 整除
    Jzoj4792 整除
    Educational Codeforces Round 79 A. New Year Garland
    Good Bye 2019 C. Make Good
    ?Good Bye 2019 B. Interesting Subarray
    Good Bye 2019 A. Card Game
    力扣算法题—088扰乱字符串【二叉树】
    力扣算法题—086分隔链表
  • 原文地址:https://www.cnblogs.com/bobdeng/p/8502813.html
Copyright © 2020-2023  润新知