当没有足够的时间测试时,该怎么做?

来源:互联网 发布:公务员备资料推荐知乎 编辑:程序博客网 时间:2024/03/29 00:23

PostedIn |Basicsof Software testing,Teststrategy,TestingSkill Improvement,TestingTips and resources

         当测试周期进行到一段时间后,你会经常感到没有足够的时间进行测试吗?一开始,或许一切都在你的掌握之中,但是很快的你就会执行应急计划“当没有足够的时间测试时,该怎么做?”的部分措施。

         又这个样子了,太无趣了。

         我想了想这漫长而艰巨的测试过程:刚开始测试的时候是如此的美好,但进行下去的时候情况就会变得糟糕,很迅速。这就是我的分析。

       我的测试时间哪里去了?


         首先,为什么会这样?非常多的原因,其中一些如下:

         1)不正确的评估

         如果一开始就评估不正确的话,那么事情就注定失败了。一个好的测试评估必须考虑以下几点:

任务筹备时间:

  1. 确定一个回归测试套件

  2. 创建测试数据

  3. 测试准备时间(例如:冒烟/可用性测试)等

       测试用例的维护:测试用例是可以长期使用的一项资产。它们在执行过程中肯定会发生小的更新。对于新产品,建议高达30%的测试执行时间应分配给这些小的维护任务。可能不是所有团队和项目都需要30%,但仍需要为此任务分配一些时间和精力。

       随机/探索性测试:脚本测试计数是测试估计数的主要特征。在这个世界上没有测试团队会拒绝探索你的软件即使模型主要是脚本。

        报告/通信:这个包含了会审会议/站立会,和更新工作管理工具等。

        偶然因素:标准建议25-30%来缓冲你原来的估计。但很少团队能给予这么多的时间,即便那样,也应当尽可能的留一点喘息的空间。

        团队和它的能力:如果你加入了一个新的团队或者他们是第一次使用一个工具,你可能需要留出一些时间来训练。根据你和你一起工作的团队,定制你的估计值。

推荐阅读=Checkthis for more information on test estimation success andmethods

        2)不稳定的构建和其他技术问题:

        冒烟/可用性测试失败:部署到QA环境,当在AUT的基本试验失败后,就没有任何质量保证团队可以对测试执行做些什么弥补。这是真的,当发生这种情况的时候,我们可以做一些其他任务,但它仍然不会填补测试周期时间。所以,这是浪费时间的一个主要因素。

       测试数据难以获得的:对于每一个测试项目都是必须的。没有及时将测试数据加入到质量保证环境中,这也是另一个阻碍因素。有时,测试人员可以通过创建和管理自己的测试数据来解决这一问题,但这有些费时的,可能不总是在点上。

       环境问题:环境部署失败,服务器总是超时,许多这样的问题消耗掉测试时间。这可能源于一个事实,一些公司(不是全部)破坏了一个好的,适宜生存的环境:保障有效的QA。他们经常试图获取低容量的服务器,并做一些设置。这真是一个很短暂的修复,没有人有任何好处。事实上,它可能会为了测试质量而付出代价和损失宝贵的测试时间。

       3)缺乏有关各方之间的协议:

      Thismight be a rare problem with teams following Agile orSAFedue to the close circles they work in, but many teams still sufferfrom disagreement or miscommunication as to when Dev, Ops, and QA issupposed to receive deliverables from one another. Hence, delays.

     了解沟通的微妙之处=>HowBusiness, Development and QA Can Work Together to Get the ProjectCompleted

      既然我们知道了这些问题,这里有一些方法来解决它。

      测试人员如何能够有足够的时间进行测试?

                 1)准确估计。有疑惑时可以过度估计一个合理的边界,但不能低估。不要忘了根据你的团队、工具和过程来进行估计调整。Whendone, seek official sign off so everyone is aware and is in kept inthe loop.

                 2)以历史数据作为参考–测试管理工具是你最好的朋友。

                               早期发布的版本测试周期采取了多少时间?

                               什么样的问题导致了以前的测试周期中断?

                               大多数测试用例在测试通过之前有多少个运行?

                               报告了什么缺陷?

                               什么样的缺陷导致了测试被中断?

                 3)问以下的问题,在关键时刻作出相应的规划:

                               找出项目中重要的功能?

                               找出项目的高风险模块?

                               用户最能看到哪个功能?

                               哪个功能对安全性影响最大?

                               哪些功能对用户的财务影响最大?

                               应用的哪一个方面对客户最重要?

                               哪部分的代码是最复杂的,因此最容易犯错?

                               哪些部分的应用程序是在匆忙或恐慌的情形下完成的?

                               开发人员认为应用的哪些方面风险最高?

                               什么样的问题会引起最糟糕的关注

                               什么样的问题会引起大多数客户的投诉?

                               什么样的测试可以很容易地覆盖多个功能?

                考虑到这些点,可以在更短的时间约束下,大大降低项目发布的风险。

                4)使用测试管理工具。这将大大减少前期准备,报告和维护的时间和精力。

最流行的测试管理工具的选择,checkout here:

               5)没有太多我们可以做的关于不正确的构建/技术问题,但有一件事可以且帮助:看单元测试结果。这将给我们一些指引,构建是否成功,什么样的测试失败了,所以我们不重新发明轮子。

如果您的测试管理工具支持“集成”,那么您就可以不用大惊小怪的,这样您就可以更好地了解应用程序的稳定性了。

              6)经常测量你的生产力和进展。别让状态报告成为一个外部团队的利益的可交付成果。确保你密切监视你的每日目标和你有足够的能力完成他们。

        另外,千万别掉入速度VS.质量的经典难题。因为,当你报告说,一天50bug,如果你是超级生产的话,它可能会出现。但是如果他们中的大多数都是无效的,那么就该自己好好反省反省了。

        因此,监督,监督和监督再多一点。

        结论:

最后,尽管防范与措施非常的全面,但如果你依然觉得自己时间紧迫,请寻求帮助。

       大多数团队都愿意参加一个作战室会议,让事情回到正轨。

       关于作者:这些有用的测试技巧是由STH团队成员SwatiS.提供的

       现在,你的什么技巧使你在规定的时间内提供一个质量测试服务?还有,上面这篇文章中的哪些点与你共鸣?

我们感谢您的反馈,珍惜你的读者。感谢你的阅读!          

0 0
原创粉丝点击