什么是QA？

今天无意中看到一位先辈写的有关QA的帖子，觉得很好，所以复制下来收藏。

       总有些朋友问我什么是QA，不知道QA到底是做什么。其实我也没办法用一个纯理论的言语来解释什么是QA。把我自己的理解与经验与大家分享吧。QA其实是品质管理。为什么说是管理呢？因为QA结合了管理，分析和测试三大行业的知识。公司的研发进度，产品研发初期的标准制定及产品后期的研发都需要QA的参与，缺一不可。QA可以有效的控制研发的进度和每个环节的质量。不管任何的产品，都是以适合人使用为前题的。在产品初期制定设计标准的时候，QA能够站在消费者的角度来看待这个产品，让产品更人性化。设计阶段，QA成为一个测试者，验证每一个环节的质量，是否达到了设计标准所规定的。用当局者迷，旁观者清来形容再贴切不过了。QA就是这个旁观者。任何产品不可能十全十美，出了问题，设计者不可能一一来查找问题，因为很难有单独一个人完成整个产品设计，这时候QA就是一个分析师，查找在哪部分出了问题，节约研发的时间，解决不必要的麻烦。任何的公司都有自己的产权，而QA能很好的保护公司的产权。健全的公司，QA有很大的权力控制公司的所有技术资料。任何设计工程师不可以私自给客户公司的技术资料，这些管理都是由QA来完成的。
　　 如果想成为一个成熟的QA需要经过三个阶段的成长期。
　　 首先，先让自己成为一个优秀的测试者。有灵活的头脑，用逆向思维来思考如何做测试。不能做到与常人不同的角度去想问题，就不可能成为一个好的测试者。应庙毕业生最适合做测试者，这时候的人如一张白纸，什么也不懂，需要做的是按照自己想的方式去测试你手上的东西，不用考虑这样操作是不是会把产品弄坏，如果你弄坏了，我要恭喜你，你成功的成为了一名测试者。优秀的测试还需要有良好的记忆力，你每做的一个操作都要记住了，万一产品出现问题，你能找到发生的规律。做为一个测试者，还需要有良好的表达能力，要能将自己看见的现象描述清楚。有些人天生就对文字表达不擅长，但没关系，描述bug是有一定规则的。以下提供一个我经常使用的格式：
　　测试环境，软件版本，硬件版本，测试时间，此项测试的申请人。记录这些的目的是为了快速准确的找到相对应的人与开发环境。方便问题重现。
　　说明此bug是只出现在一个版本上，还是所有的版本都会出现，出现的几率是多少，大概出现在哪个产品模块。
　　将操作步骤写清楚。此点并不容易描写清楚，给个建议，你不需要用太多麻烦的描述，只需要列出每一步做了什么，用最简单的语言描述你当时所做的操作，最好用列表式，用数字排列出步骤的先后顺序。
　　列出问题点，只需要写出现象，不需要做过多解释，这样更容易让看报告的人明白。
　　 如果你做到了用逆向思维方式不约束的头脑去测试，用超强的记忆力，记录下自己所做的步骤，用敏锐的观察力去发现每一个不起眼的异常，用简单清楚的语言描述bug，那么你就是一名优秀的测试者了。
　　
　　 在成为一名优秀的测试者后，不要满足喔，你还没成为真正的QA，你还需要具有分析问题的能力。这个需要时间和精力来完成，没有捷径，只有努力才可以达到。但也是有方向的，向大家指个方向。QA需要了解大量的专业知识，除了要让自己了解公司所有的规格标准技术资料外，更应该让自己成为一个博学者。每个人能力有限，博学不代表要精通，但至少要知晓相关知识的大概。QA的分析能力与经验有相当大的关连。QA需要长时间来积累自己的经验，积累经验也有要领的。每次出现一个问题，都要去问为什么，为什么问的越多，经验就越多，你会在为什么中不知不觉的成长。一般五年是QA的一个阶段，五年内，QA需要默默的学习，积累扎实的基本功和经验，如果你做到了，五年后，你将发现，你成了奇缺人材。
　　 最后一点要说的是管理。QA需要管理自己内部的资料，也需要管理整个研发团队的。首先要做到的是，QA需要有正直的人品，不要因为任何的外界的因素而改变自己对公司产品的严格要求，要勇敢地说不，对不合格产品严格地打回去重新做。其次，QA需要有完善的体系来管理工作。每家公司各不相同，但我认为需要以下几个方面体系：
　　工作记录。此测试是何人完成的，何人申请的，进度如何，完成时间，要严格控制记录，如果出了问题方便找到相关的人，不是为了让谁去担这个责任，是为了能更快的解决问题。当然也有对测试者的约束力，要让每一个QA知道，要对公司负责。我通常采用一个工作记录表格，个人认为还有一个好处是给QA和其他部门的同事看。当QA全部在忙，研发工程师们可以内部自己调整case的重要性，暂时pause或者delay某个任务，调整工作，让QA的工作更有效率。
　　Test Case管理系统。这个需要一个小型数据库，将每一个测试项目详细记录下来，测试者可以将自己的经验变成文字写在里面，让后来者可以为之所用，提高QA团队的整体力量。每一个Test Case都必须根据公司的设计规格书和行业标准来编写，通过此，测试者也可以更了解公司产品的标准。
　　Bug管理系统。这个系统可以便于QA上报bug，研发工程师能很快的去解决，也可以帮QA控制产品的研发进度，push研发工程师按进度解决问题。也可以根据此来制定每一个版本的release时间表。
　　Code mangerment. 一般的公司都有这种工具，就不需要我来特别说明了，通常用的是Perforce和CVS。说明一点的是，有些公司对code管理比较乱，客户打个电话code就release出去了。不成熟的产品出去了，会让客户觉得这家公司的产品为什么如此差劲。所以如果要对公司好，就一定不可以随便开放权限。健全公司的做法通常release全部由QA发布，最后再由相对应的客户服务经理发给客户。毕竟公司的面子最重要。
　　其实对于管理方面我也只是在学习摸索，也不太清楚，先写这么多吧，以后我将给大家讲一讲具体产品方面的QA知识。

 

        每一种工作在一家公司都不是无故存在的，都会有它的作用存在。通常在面试中，都会被问到，QA在公司产品研发中的作用是什么，当然我也会常常问求职者这样的问题。那QA的作用到底是什么呢？不是一个非常重要就能概括的，今天这篇短文，总结一下，我认为的QA的作用，纯属个人观点，希望大家共同讨论。因为我做的是家用消费类电子产品，所以就以这种产品为例，写一下我的观点。
　　一家公司看准了一个产品市场，准备去做研发了，那么，市场部的人员会做市场调查，看看用户对于这种产品的需求是什么。这时候QA就要介入进来，共同reivew这份需求，我给这份需求书起个名字‘MKR’。研发部门会根据MKR来制定公司的产品规格书。从制定公司产品的spec开始，QA就需要介入了。QA需要站在终端用户的角度来考量这份spec所定义的东西是否符合用户的使用习惯，是否符合行业标准，是否与业内通行的默认的潜规则一致，等等。如果QA认为有任何的错误，都应该及时向研发部门提出异议，这样才能从最初期保证产品的质量。要知道产品的致命缺陷通常都是因为设计理论本身就有问题，导致后端开发人员无法弥补，而最终产生严重后果。在这点上，QA需要积极地与PM合作，推动研发部门改正不合理的设计方案。做为家用消费类产品，我们要以终端用户的使用习惯为最终的要求。
　　在spec制定出来以后，QA就要投入到紧张的工作当中。在研发人员开发的同时，QA需要制定出test plan和test case。
　　QA如何制定test plan呢？
　　这项工作需要与项目经理和design team的人使用共同完成。首先，我们需要从PM那里得到project schedule，根据schedule来制定QA的test plan。test plan包括产品测试的具体内容，release schedule，release test plan and schedule, code management，QA的工作流程和参与人员的工作安排与职责。
　　test case是一个非常详细的工作，我就不在这说明了，这需要经验，根本也不是三言两语可以说得清楚的，但可以介绍一下大的方向。写test case的宗旨是让测试变得最简单，看case的人哪怕完全不懂，是个新手，也能按照case去完成测试的工作，并且给出测试结果；尽量减少人为的经验因素带来的影响，将需要测试的方面，和有可能被忽略的方面都要写进去，让case成为一个众人经验的集合，达到case的最大功效。
　　当然test plan制定以后不是一直不变的，需要大家一同来review，而减少QA本来有可能带来的失误，因为是人都会有想不到的，有犯错误的时候。这个就需要QA与PM和design team的人去沟通，需要大大小小很多的review meeting来解决。这个时候千万不要怕麻烦，这个时候偷了懒，危机就在后面等着你。这时候会遇到很多困难，design team的人通常很难合作，因为对于那些研发工程师来说，这种meeting是非常讨厌的，肯定会排斥。但就是被排斥，得不到合作，也不可以放弃，QA应该坚持自己的原则，这里就会考验到一个人的沟通能力了。
　　上面的工作都做完了，QA会得到小小的休息时间。按步就班的做事，开始跟着PM和研发进度走。到了产品研发成熟期，客户会出现，这时候，QA又会起到重要的作用。在这里提一下，有些健全的大公司，把QA分成了两个team。与研发部门合作，只做产品研发测试的development QA，与客户打交道，接受客户投诉，帮客户产品质量把关的customer QA，我们公司在发展的后期，就出现了CQA和DQA。如果说公司QA分成这两部分，那么QA的工作就变成更为复杂。
　　DQA的使命只是维护研发期的产品质量，我们把这种产品叫reference design products，而CQA的使命是维护客户的产品质量。
　　不管是在产品的研发中，还是在客户产品的质量维护中，QA还有一个重要的职责，就是推动力，QA要成为工程师们工作的推手。人都有惰性，不要期望每个人都自觉地努力工作。QA的通常做法是，每周给出一个进度报告，做一次bug review。通常研发部门的工程师非常讨厌这种会议，那没办法，我给大家一个小方法。QA把每目前严重的问题分列出来，详细到把每个负责的工程师所属的bug全部列出来，告诉工程师们这些bug需要被fixed时间，然后群发email，当然不要忘记CC给老大们喔，这样才够power。当然，态度不可以太强硬，最好在邮件结尾加一句，如果有困难，可以提出，meeting中商量。通常都会有人接受meeting。一个研发工程师手中通常不会只有一种产品，那么就会有冲突的时候。QA需要问清楚优先级和工程师的难处，尽量解决，这样才能达到良好的协调。协调好了，工作效率会更高。不过，有些公司，把这类工作交由PM来做，但本人认为，推动公司的产品质量朝更好的方向发展，是QA义不容辞的责任。
　　整理这些也不容易，我目前只想到这么多了，以后想到再补充吧。下次我会详细给大家介绍QA的工作流程。