专栏首页FunTester测试人员常用借口

测试人员常用借口

无论我们试图建立一个网站多么完美,我们都一定会犯一些错误。错误是不可避免的,无论多么微小。这就是为什么我们不能保证没有错误的发布,甚至在进行了不同类型的全面测试之后,例如压力测试,跨浏览器测试,响应测试等。在投入生产环境之前,请考虑流程中涉及的各种类型的测试。依然可能在上线的版本中发现问题。

出了问题,就要解决问题,不管是测试过程中发现的还是上线以后用户反馈的。但在解决问题的过程中,测试人员需要起到积极的推动作用。当然理想很丰满现实很骨感,有的人总是能找到各种各样的理由逃避问题和责任。

下面分享一些测试人员经常遇到过或者使用过的各种接口,有些我自己也用过。

Chrome上没问题,其他浏览器上应该也没问题

因此,当你测试了一个网站,遇到了一些错误,然后将其转发给开发团队。他们修复了该问题,并将其转发给您或您的测试团队以供验证。您仔细地对整个网站进行回归测试,以检查更改是否影响了任何现有功能。一切都很好,您进行了确认,因为从系统(而不是浏览器)测试网站时,您没有发现任何错误。一旦更改生效并投入生产,客户使用与您不同的浏览器便开始抱怨UI和跨浏览器兼容性问题。

如果该软件在Google Chrome或任何其他浏览器上都能正常运行。但是请记住,就像人类对所有事物的理解不同一样,浏览器也是如此。如果代码与一个浏览器兼容,则不必所有浏览器都以相同的方式解释代码。测试人员需要确保自己的网站在所有浏览器上都提供一致的体验和行为,不能忽视跨浏览器测试。

专注于预定的测试用例场景

测试人员最常见的借口之一:他们的工作只是遵循分配给他们的预定义测试用例。但是,测试人员必须超越专注于预定义的测试用例场景。如果执行预定义的测试用例是任何组织唯一关心的问题,那么采用自动化测试会更好。自动化测试和手动测试应该齐头并进。因此,预定义的测试用例最终实现了自动化,测试人员将有更多的时间提出更好的测试方案。开箱即用的思考是测试工作的一部分,必须分析当前项目的开发计划的风险,并强调探索性测试。

部署构建和调试问题不是我的工作

已经批准了整个发行版。现在,您要做的就是等到DevOps投入生产。但是,真的必须等待吗?如果您认为部署构建是开发人员的头疼问题,估计要多问问自己几遍了!您是否有能力利用可用资源来采取富有成效的行动?如果是,为什么每次都依赖开发人员?您需要做的就是触发构建并部署适当的措施,没有理由等待。毕竟,您具有使您的工作更轻松的权限和能力。你为什么不能自己做?

部署是员工面临最多失败次数的情况之一。但是,您知道此类失败的最大好处吗?他们会提示您再次调试并学习新知识。如果有什么鼓励您提出问题或浏览器搜索,那将始终是您的最佳选择。

没有足够的时间进行测试

没有足够的时间是世界上几乎所有事物的最普遍借口!在某人无法完成某件事的那一刻,他们在这里为自己的失败指责。测试人员,让我们面对现实吧。要测试的因素太多了,您将永远没有足够的时间来完成这一切。没有足够的时间测试,这并不意味着最终会因此导致时间管理失败。实行有效的时间管理并确定测试程序的优先级至关重要。

我没有测试IE,因为它已经过时了

Internet Explorer是一个兼容性解决方案。我们不支持新的Web标准,尽管许多站点运行良好,但如今开发人员基本上很少在Internet Explorer进行调试。如果考虑到测试Internet explorer浏览器兼容性测试的时间,很增加很多不必要的工作量。

不!如果考虑到当前用户的属性和潜在用户的属性,Internet explorer兼容性测试时必要的。

昨天测试了该功能,不需要再次测试了

如果您认为在报告BUG后就完成了工作,那是错误的。您可能会说您已经执行了详细的测试,并将错误传达给了开发人员。但是作为测试人员,您必须意识到报告错误有时会导致代码更改。有时,更改可能会影响以前的功能。

回归测试是所有SDLC的最基本方面。无论花费多长时间或重复多少,其重要性都保持不变。作为一名测试人员,我了解通宵的工作以便发布及时的修补程序,短促的发布窗口会造成很大的损失。有时候,我们在回归测试上懈怠。

因此,重要的是要检查修改后产品是否工作良好。必须做好执行频繁检查的准备,并确保没有剩余的回归缺陷。

我认为无法测试此功能

这是到目前为止我遇到的最荒谬的借口之一。令人惊讶的是,有许多测试人员使用它来逃避他们不了解的功能的测试。考虑一下,您测试环境中的每个功能都已经由开发团队进行了测试(或者调试)。如果开发人员知道某个特定功能正在运行,并且能够在沙盒环境中对其进行测试,那么就必须有一种方法来对其进行测试!

可能是,您可能无权访问某些功能中使用的系统。在这种情况下,您需要与开发人员合作,并要求他们向您展示该功能的工作原理以及如何对其进行测试?然后,尝试不同的测试用例并尽可能发现BUG。

指责开发人员的代码

责备他人是逃避不愉快状况的最简单方法。软件行业中的一些测试人员趋向于将开发人员承担所有令人讨厌的责任。毕竟,如果错误出在开发人员的工作上,没有人会责怪测试人员!当您指责开发人员的问题时,那么他很有可能会选择回击。

但是这种盲目推卸责任的方法是完全错误的,不仅对团队有害,对自己也有害,会让以后的合作更加困难,会让组织在平息愤怒和理清责任上的时间大大增加从而延长发布周期。

用户不了解程序

因此,现在甩锅的循环已经从开发人员转移到了用户!

在任何情况下都不要忘记进行可用性测试。企业的所有努力都取决于用户体验。在可用性测试期间,请不带任何偏见地从小白用户的角度进行测试。

在测试环境上运行ok

这是一个借口,对测试人员而言只是合乎逻辑的,而对其他人则没有。似乎在测试阶段运行良好的应用程序不一定可以在生产中完美运行。原因可能有多种,在网站上进行测试时,经常无法获得网站进行生产的实时流量和所有情况。

作为测试人员,应该在从测试环境提供批准之前彻底了解生产环境以及两者的差异。

总结一下

测试人员在软件开发生命周期中扮演着极其重要角色。为了生意兴隆,必须为客户提供满足需求又拥有良好体验的产品。为了确保这一点,测试人员需要测试产品并从最终用户的角度对其进行分析。发现BUG后,他们需要将相关信息传达给开发团队。然后致力于消除缺点并部署各种纠正措施。测试人员需要意识到,他们需要摆脱借口的习惯。这将有助于他们的职业发展,并促进公司的发展。相应地进行分析和测试会带来更好的产品和出色的客户体验。


本文分享自微信公众号 - FunTester(NuclearTester),作者:FunTesting

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-12-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • DevOps中的测试工程师

    DevOps需要在各个阶段进行协作,因此,使开发人员和测试人员从敏捷孤岛式转变为一个在各个阶段中所有成员不断参与的运营已变得非常具有挑战性。

    八音弦
  • 成为自动化测试的7种技能

    当我开始担任手动测试人员时,我不喜欢编码。但是,当我逐渐进入自动化领域时,对我来说很清楚,如果没有对编程语言的一些基本了解,就无法编写逻辑自动化测试脚本。

    八音弦
  • 17种软件测试人员常用的高效技能-下

    测试人员通常被误认为是应该只测试产品的人。但是,有时开发人员可能错过了重要信息。软件测试人员应该负责这种情况,并指出缺乏信息。 此外,最重要的软件测试技能之一包...

    八音弦
  • 成为自动化测试的7种技能

    当我开始担任手动测试人员时,我不喜欢编码。但是,当我逐渐进入自动化领域时,对我来说很清楚,如果没有对编程语言的一些基本了解,就无法编写逻辑自动化测试脚本。

    八音弦
  • 有关测试流程中的问题

    最近在带一个学生,是一个超级认真、努力的学生,布置的作业和学习点都会认真去完成,我能感受到他是在尽心尽力地去做好,从提出的问题中就能看到这个变化,由以前的很外行...

    王豆豆
  • 为什么自动化测试难以推广

    为什么自动化测试难以推广 2005 第一次接触自动化测试,十年已经过去了,着眼身边的企业,真正实施自动化测试的企业非常少。 大部分企业,测试仍然处在,点鼠标阶段...

    netkiller old
  • 如何通过缺陷分析来改进软件工程?

    “项目结束后的总结工作中,是否对bug做过详细的总结和分析呢?如果有,是怎么做的呢?”

    张树臣
  • 手动测试存在的重要原因

    在移动应用测试方面,手动测试是不可避免的。在这个快速数字化转型的时代,移动应用程序已成为最有利的商业模式。不断变化的情景也影响了测试空间。在可能的情况下应用自动...

    八音弦
  • 测试人员必看-做好自动化测试的7大技能

    随着敏捷和DevOps等新时代项目开发方法逐渐取代旧的瀑布模型,测试需求在业界不断增长。测试人员现在正在与开发人员一起工作,自动化测试在许多方面极大地取代了手动...

    优测utest
  • 选择手动测试还是自动化测试?

    在软件测试行业中,争议最大的话题是“更好的是手动测试还是自动化测试”。尽管自动化测试最常谈论流行语,并且正在慢慢主导测试领域,手动测试的重要性不可忽视。

    八音弦

扫码关注云+社区

领取腾讯云代金券