IT干货网

Thoughtworks是如何做测试的

xmjava 2022年03月04日 编程设计 187 0

1. 要不要写测试用例?

   实际上,我在Thoughtworks的这几年工作中,几乎很少使用过测试用例去测试,在手工测试中,大多数时间都是在做探索性测试。

  这三年中,也会偶尔会碰到一些特别复杂的流程需要写一个测试用例做指导,测试过程中虽然依照步骤去测试,但是当我看到系统的反馈有特殊地方后,往往会让我立刻联想到新的测试途径去尝试,直到尝试完了,可能才会返回到刚才的用例步骤中。

  实际上,IT系统实际上是非常复杂的系统,有很多细节点需要注意,如果这些点都用文字写成测试用例,那工作量及其庞大,很难全部写完。所以对于复杂的业务场景,我们可以先构思一些主流程的测试脚本,然后在每个步骤中,根据IT系统给你的反馈,去判断和选择下一步该如何测试,而不是死死依据测试用例去测试。如果需要完全依据测试用例去测试,这时候我们可以让自动化脚本去做。而QA更应该发挥人的主观能动性,根据系统的不同去做不同的判断。

  这里的前提是QA应该对IT系统的各类细节知识了解的非常丰富。

2. 谁写自动化脚本?

   基本上绝大多数的自动化测试脚本都是开发写的,包括UI自动化测试。有比较高的单元测试覆盖率,和包含主要业务流程的UI自动化测试,以及对微服务的集成测试等。如果我在测试中发现了一个Bug,通常会看是否需要开发去补充对应的自动化测试。有了高覆盖率的各种自动化测试,我可以投入更多数时间去做探索性测试,去发现那些单元测试、UI自动化测试和集成测试没有发现的Bug。

  有时候我也会去写UI自动化测试,例如,当程序员开发一些微服务时,为了隔离微服务并让单元测试运行的更快,团队使用了mock方法,但这种方法会有一些弊端,例如测试多个微服务之间的调用时,边界处如果有Bug往往会出现漏测,因此我补充写了一些E2E脚本跨多个服务之间,去测试完整的流程,避免漏测的现象。

 

3. 当开发说这不是个bug怎么处理?

   首先我会去分析开发人员认为个bug不用修复的原因是什么,可能会是以下这几种之一:

  A. 界面和UI设计稿不同,或者大部分地方和设计稿相同,有些细节地方不同。这种情况下,一帮我们会认为UI的审美意识更好一些,如果开发仍然不愿意修复,那最好引入UI设计人员一起讨论。通常讨论后,UI认为有些细小bug不影响整体风格的可能就不需要修复了,另外一部分对用户体验会造成影响,是需要修复的。  

  B. Bug只出现在特定浏览器上,例如bug只出现在IE10或者手机浏览器chrome28上。这时候,我会根据统计真实用户行为的软件,例如Adobe 的Omniture分析结果,去确定现在需要支持的浏览器类型。通常,一个产品有大量的用户,需要支持的浏览器类型就比较多,但是由于开发人员有限,往往优先支持Top10的浏览器类型。如果IE10或者chrome28还在Top10,那就以此和开发人员沟通说bug需要修复。如果不在Top10的浏览器列表,那就不用修复。有些特定Bug可能还会引入PM,BA等人一起确定是否需要在特定浏览器上修复。

  C.有的Bug是易用性问题。开发人员作为技术工作者,熟悉电脑和各种快捷键等,因此可能使用起来觉得没问题,但产品的真实用户中各种类型人都有,例如有年纪大对IT不熟悉的,甚至有色盲、或者其他障碍的,那么从这些用户的角度去说服Dev这个bug是否需要修复。

   D. 有些Bug修复的effect过大,开发说不值得去修复。这类通常也要和PM, tech lead,BA一起讨论一下。可能出现三种情况:

    情况1. 如果这个bug的投入产出比大家都认为不合适,而且影响比较小,可能就不修了,但是最好有个文档去记录已知的不需要修复的bug。

    情况2. 第二种是大家觉得需要修复,但是因为工作量太大,现在没有时间修复,那么建卡,放在Jira的backlog里,等团队有时间了,由PM决定什么时候开始做这个卡。

    情况3. 第三种是大家觉得虽然工作量大,但是因为对用户影响较大,现在就修复。那么需要现在建卡,并安排高优先级立刻着手修复。

   最后,如果当QA和开发有分歧的时候,可以适当的引入PM,BA,Teach lead,UX等来共同做一个决策。

 

4. QA的日常工作是否包含大量文档、产品部署的杂事?

  没有。我们产品部署到无论是测试环境、类产品环境还是产品环境,都是全自动化部署的。所以每当开发提交代码后,会自动部署到测试环境中。这里不需要QA手工参与,节省了很多时间。

  由于不需要写测试用例,也节省很不少时间。有些公司要写测试日报或者每周测试报告,这里都不需要。也不用写性能测试报告,我把性能测试结果记录在Jira卡中,和团队分享就可以了。我记得今年就写过几个概要的产品测试策略文档,以及十多篇测试经验分享的Blog。此外,其他文档写的很少。


评论关闭
IT干货网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

ThoughtWorks QA推荐书籍