Contents
在Wiki上，QA指的是品质保证。实际上，QA就像他名字所赋予的责任一样，承担了对质量的保证，但却不是只有QA对质量的负责，而是整个团队对整个产品的负责。
QA的使命有很多种解释：
- 报更多的bug
- 保证产品的质量
- 快速定位问题
- 快速找出问题
- 对产品质量提出评估
- 改进产品
- 控制成本、帮助预测
- ...
在我看来，QA的职责是：提供高测试覆盖率的测试案例，尽快尽早发现问题，准确报告问题，定位问题，借此来保证产品质量。
在Agile中，测试人员为了更快测试，在Dev开始coding之前就开始requirement review。尽量在早期发现design上面的issue，而不是后期才发现，那会儿的代价也会越来越高。于是，QA几乎在coding之前和之后，都处于忙碌的状态中，已经不再是那种跟着DEV走的状态了。
QA在一定程度上，是BA A，PM A, PjM A和DEV A。正是QA的存在，整个team在明确自己的当前状态。此外，测试人员报bug的速率DefectArrivalRate也能够在一定程度上面反映产品的质量，是项目开发的明灯。
《测试之美》第一章中提到测试人员因为一个泄露bug的案例而偷笑的故事。他们测试过，知道有这样的issue。但是PM和PjM决定不修这样的问题，所以QA不会因此而负责，相反，他们会偷笑。但是他们之前告诉过你这事。
但是QA也常常会迷失，注意在那不是很重要的area去测试。这也不能够怪QA，在QA眼里，所有的area，都尽可能测到。只能够说，priority不是那么高而已。QA侧重的是缺陷，而客户注重的是满足自己需求的功能。测试需要常常和BA，PM以及客户（如果可能）沟通，拿到第一手资料，帮助以后的测试。
你为啥不修这个？DRE为啥要这么算？为什么会出现这个bug？为什么之前没有？为什么这个是P3的，明明是P2的issue？什么是DAR？能够说明什么？产品为什么要这么设计？市场是什么？运营呢？我们可以这样改进不？
QA，永远对这个世界充满着好奇。
QA的视觉是悲观的，有时候又不得不在悲观中形成一种难以捉摸的幽默。“哈哈，我又发现一个bug！” 很难理解发现bug还会高兴的事儿。但是，QA是最能够接受现实的人：“改变了不了现实，就只能够改变自己！”
此外，QA的心理素质要好一些才行，否则，在如此悲观的环境里面不会得到快乐的。
QA是痛苦的：发现不了所有的问题，找不完所有的bug，覆盖不了所有的scenario，不可能写出完全覆盖的test plan，没有也不可能有completed测试，所有的issue没有办法修完。。。种种纠结，种种挣扎。
QA怀着美好的希望，希望每个issue都能够被fix掉，但是事实是不可能的。同时，QA也是聪明的。“好嘛，A、B、C你都可以不修了。但是，D是必须要修的！” 如果你不修D，那么他就要求你修A、B、C。
QA不适合去做PjM，因为QA总是希望所有的东西都修好。所以，QA一般需要BA/PM的介入，必要的时候告诉QA这个可以不去理睬。注意：PM对于这种问题的处理、分析的角度，对于QA来说，是很重要的一个部分，有助于QA下次报bug的时候衡量priority。
QA发现问题的时候，要定位问题出在哪里，即find the root cause。一般步骤为： code change areas > core function > main function > reliability > common scenario > rare scenario. 随着产品前台，后台的了解深入，越加可能找到重要的问题。
曾经我试图去拯救世界。当时，修好的bug又再次重现，自己就想冲过去抽DEV：“这个是怎么回事嘛？！前天还是好好的！” 后来，我毕竟没有能够拯救世界，也差点闹得和DEV水火不容。沟通那事，对于QA很重要，要让别人很舒服地帮你做事又不伤感情，还是比较困难的。
就拿环境稳定性来说吧！环境不稳定，对于测试的进度有很大的影响。需要告诉上面的头头们，否则，他们以为你们没有做事呢！