|
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。此外，其他文档写的很少。 |
|
|
