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