一. 要不要写测试用例？ 　　
　　实际上，我在 TW 的这几年工作中，几乎很少使用过测试用例去测试，在手工测试中，大多数时间都是在做探索性测试。
　　这三年中，也会偶尔会碰到一些特别复杂的流程需要写一个测试用例做指导，测试过程中虽然依照步骤去测试，但是当我看到系统的反馈有特殊地方后，往往会让我立刻联想到新的测试途径去尝试，直到尝试完了，可能才会返回到刚才的用例步骤中。
　　实际上，IT 系统实际上是非常复杂的系统，有很多细节点需要注意，如果这些点都用文字写成测试用例，那工作量及其庞大，很难全部写完。所以对于复杂的业务场景，我们可以先构思一些主流程的测试脚本，然后在每个步骤中，根据 IT 系统给你的反馈，去判断和选择下一步该如何测试，而不是死死依据测试用例去测试。如果需要完全依据测试用例去测试，这时候我们可以让自动化脚本去做。而 QA 更应该发挥人的主观能动性，根据系统的不同去做不同的判断。
　　这里的前提是 QA 应该对 IT 系统的各类细节知识了解的非常丰富。

二. 谁写自动化脚本？
　　基本上绝大多数的自动化测试脚本都是开发写的，包括 UI 自动化测试。有比较高的单元测试覆盖率，和包含主要业务流程的 UI 自动化测试，以及对微服务的集成测试等。如果我在测试中发现了一个 Bug，通常会看是否需要开发去补充对应的自动化测试。有了高覆盖率的各种自动化测试，我可以投入更多数时间去做探索性测试，去发现那些单元测试、UI 自动化测试和集成测试没有发现的 Bug。
　　有时候我也会去写 UI 自动化测试，例如，当程序员开发一些微服务时，为了隔离微服务并让单元测试运行的更快，团队使用了 mock 方法，但这种方法会有一些弊端，例如测试多个微服务之间的调用时，边界处如果有 Bug 往往会出现漏测，因此我补充写了一些 E2E 脚本跨多个服务之间，去测试完整的流程，避免漏测的现象。

三. 当开发说这不是个 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 等来共同做一个决策。

四. QA 的日常工作是否包含大量文档、产品部署的杂事？
　　没有。我们产品部署到无论是测试环境、类产品环境还是产品环境，都是全自动化部署的。所以每当开发提交代码后，会自动部署到测试环境中。这里不需要 QA 手工参与，节省了很多时间。
　　由于不需要写测试用例，也节省很不少时间。有些公司要写测试日报或者每周测试报告，这里都不需要。也不用写性能测试报告，我把性能测试结果记录在 Jira 卡中，和团队分享就可以了。我记得今年就写过几个概要的产品测试策略文档，以及十多篇测试经验分享的 Blog。此外，其他文档写的很少。

五. 平时发现多少 Bug？
　　我大概统计一下，我们每天做的 story card 里，有 70%~75% 左右会被移动回开发修改 Bug。其中大多数情况下，一张卡有 3 到 8 个 Bug（我们这里通常一张卡会是 1 到 3 个人天），最多有过一张卡将近 20 个 Bug，但这种情况是极少数才会发生的。

六. 开发做测试为什么有天然的优势
　　如有让你测试一个叫 “八星高颗粒子旋转通道” 的东西，你会测试吗？基本上没有几个人能测这个东西，因为没有人知道 “八星高颗粒子旋转通道” 是干什么的。但如果你恰好是 “八星高颗粒子旋转通道” 的技术开发人员，你做出了这个东西，那你对整个构建过程很熟悉，对每个影响最终产品质量的变量都有过切身的体验，那你就知道哪里容易把产品破坏掉，也知道哪些变量和输入有可能是做这个东西的人有可能遗漏的。因此你就容易发现这个产品的缺陷。
　　而开发人员做测试的天然优势一，就是他非常了解做这个产品的整个过程，明白整个过程中有哪些变量会影响产品质量。他也知道自己在做开发时候，往往会疏忽大意遗忘那些点没做，因此也能预判到别人会在哪里出现遗漏和缺陷。因此开发经验越多，做测试越容易。

七. 如何培养开发的测试能力
　　今年上半年时间，我主要工作的中心转到帮助开发团队提高测试能力上。我们有 11 个开发，一个 QA，有时候测试忙不过来，也会让开发去从 ready for QA 列捡卡测试。我之前采用的方式是，写一些 blog，分享一些测试经验，以及和开发一起结对测试。其中结对测试是传递知识比较有效的方式，开发和我坐在一起，共同使用一个大显示器，做探索式测试，根据系统的反馈决定接下来测试的内容。
　　不过我现在又了解到了另一种提高开发测试能力的方法，以后有机会可以尝试一下：这个方法是 QA 不去测试任何一张卡，全部卡都由开发去测试。QA 主要做两部分工作：
　　第一步，在每张卡上加上注释，说明这张卡要关注的测试点，或者和开发面对面沟通一下需要着重测试那些点。
　　第二步，当开发交叉测试完后，必须给 QA 演示他测试的过程。这时候 QA 如果认为没有问题，那么这张卡就挪到 done 了。如果 QA 发现一些问题，那可能会修改之前写在卡上写的测试注释，同时，开发会补充测试这些之前没有测到的路径。
　　上面这种方法好的原因是：
　　* 开发如果把 Bug 漏到产品环境后，经过几次教训，他自己测试的能力必然提高很快。
　　* 一个能做好测试的开发，他自己开发出的代码质量也必然会提高很多。减少 Bug 的出现可以节省一大笔项目成本。

八. 和一群优秀小伙伴合作的体验
　　刚来 TW，能明显感觉到大家的技术能力不错，而且公司的技术交流氛围也很好。和一群优秀的技术达人合作，有几个好处：
　　* 沟通起来比较顺畅，说到技术点，都能一点就彼此都明白。
　　* 团队每个人都追求高质量的产品，如果研发实践没做到位，大家都不舒服。例如单元测试覆盖率补够，code review 不充分等，大家都会尽量避免。
　　* 看到缺陷会积极的去修复，不推诿。
　　* 经常性的 retro 回顾会议，对项目进行持续的改进。

九. 测试工作的成就感。
　　到目前为止，我很爱测试工作。每次探索式测试，就像从迷宫中寻找出路，或者像是解题过程，从各种蛛丝马迹中寻找可能存在的产品缺陷，这是测试让我感到愉快的第一部分内容。 第二部分内容是，在大部分情况下，我会从每张卡上找出一些列的问题给开发，等开发完成后，我可以感觉到这部分的产品质量已经不错了。有好的产品质量是让我感到有成就感的另外一部分原因。