程序员可以做qa吗

Ⅰ 有谁能告诉我软件开发中的QA主要做什么的

QA是质量管理职位，很多大公司有专门的质量管理部。
在项目开发过程，会由QA进行全程的监督，查看是否按照CMMI的标准进行软件开发。
文档是否齐备，开发基线是否明确，是否存在风险，BUG的削减是否能够完成目标之类的。

该职位的好处是加班没有那么多，有经验的QA能够协助项目经理管理好项目。
相当于一个监督员的身份。

CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型）

Ⅱ qa工程师是做什么的

qa工程师工作内容：

1、制定软件开发过程的规范与制度，监督并保证规范与制度按要求执行。

2、负责产品研发过程体系（敏捷相关流程、CMMI相关流程等）的持续优化和推广。

3、为产品研发过程规范实施提供咨询、指导和培训，确保规范流程落实。

4、负责流程规范的执行检查和审计，监督和管理不符合项问题的解决。

5、收集过程数据、统计分析过程情况并以此推动过程改进工作。

6、结合公司业务特点和业界优秀实践，提出质量改进计划。

7、协助完成各类流程审计工作。

8、负责产品质量的整体管控。

岗位介绍：

qa，测试工程师，软件质量的把关者，工作起点高，发展空间大。我国的软件测试职业还处于一个发展的阶段，所以测试工程师具有较大发展前景。

传统的软件行业还是以软件测试工程师为主，但是在新兴的互联网行业大多还是以QA来命名这个职位，也就是质量保证。

Ⅲ it行业中qa工程师主要做什么

QA即英文QUALITY ASSURANCE 的简称，
中文意思是品质保证，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员。

QA在IT企业就是个摆设，准备各种ISO9000标准要求的文件，参加各种质量管理的会议。检查各种ISO9000标准要求的节点条件是否具备。

QA不是测试工程师，也不是开发工程师，一般不得兼任开发和测试工作，否则算违反ISO9000标准要求。

其QA工程师岗位职责是：

一、质量管理体系：
1、QA工程师编制项目部质量管理体系策划书，经领导审批后下发执行。
2、QA工程师根据施工计划提出年度、月度监督检查计划。计划内容要依据质量管理体系文件，并每年监督检查要覆盖项目部所有部门和体系涉及的所有要素。
3、现场监督检查是随机的、不定时的，QA工程师对监督发现的不符合或缺陷做出记录，并将不符合或缺陷按重要性的不同以书面或口头形式通知责任方。目的在于向责任方提出改进工作的建议，提醒责任方引起重视，纠正不符合和缺陷。
4、巡检主要针对单位工程开工、施工过程中、三级验收及监理公司参与的四级验收之前，QA工程师提前按照程序文件要求对文件包资料进行检查，避免在监理公司验收时提出不符合，同时保证施工与资料同步，避免后补资料。
5、QA工程师汇总各类管理体系月度、年度监督检查情况，出具报告，报公司企业策划部，并对有关问题提出纠正预防措施，监督实施；
6、QA工程师汇总各部门年度体系培训计划，经人力资源管理批准后，各部门组织实施。
7、QA工程师配合质监专工参与质监中心站活动，并依据有关要求整理迎检资料，对各部门的资料提前组织检查。
8、QA工程师与各部门保持密切联系，及时解决体系运行中接口不协调的问题，如无法解决可提交管理评审输入。
9、QA工程师配合好与业主及监理公司进行的各种质保监督检查活动，及时组织对检查出的质量问题进行整改，并采取纠正或预防措施。
10、QA工程师与各专业工程师、单项工程师密切配合，抓好不合格品的控制。出现不合格品，要及时进行原因分析并做好统计记录工作，采取有效的纠正预防措施，杜绝类似质量问题再发生。
11、QA工程师根据每年公司质量体系审核、日常监督检查、质量评定情况、管理评审以及顾客反映的有关问题，进行全面的汇总统计分析，找出质量体系运行的薄弱环节。以书面报告的形式反馈相应的部门，并由其制订预防措施和质量改进目标，实现质量改进。
12、QA工程师配合好公司组织的质量管理体系内审，并对出现的不符合组织整改。
13、QA工程师配合好由认证单位组织的外审，并对出现的不符合组织整改。
14、QA工程师对有关招标文件从体系考虑角度进行审查。
15、QA工程师每周不少于一次到现场检查。
16、QA工程师每月不定期对重要进货物资、监视设备、文件包等资料进行抽检。
二、计量管理体系：
1、QA工程师组织项目部有关人员学习贯彻执行国家计量法律、法规、法令及公司程序文件。
2、QA工程师组织建立项目部量值溯源图。
3、QA工程师建立项目部管理人员网络图。
4、QA工程师负责项目部管理部门使用检测设备的日常计量管理工作。
5、QA工程师负责项目部计量检测体系的运行及日常的监督。
6、QA工程师负责项目部计量管理信息的上传下达。
7、QA工程师负责建立项目部计量检测设备台帐，并上报企业策划部。
8、QA工程师负责项目部计量检测设备的送检工作。
9、QA工程师负责批准各部门检测设备需用计划的提出。
10、QA工程师负责检测设备的封存、报废、回收等管理工作。
11、QA工程师配合人力资源做好项目部员工的计量教育、培训工作，不断更新职工的计量知识，提高员工的计量意识。
12、QA工程师配合好公司组织的计量管理体系内审，并对出现的不符合组织整改。
13、QA工程师配合好由政府机构组织的外审，并对出现的不符合组织整改。
14、QA工程师负责监督检测设备的贮存和使用情况。
15、QA工程师每周不定期对检测设备进行抽查。
16、QA工程师每月对外包队使用计量器具的情况进行抽查。
三、环境管理体系：
1、QA工程师每年组织环境因素的识别与评价，汇总报批重要环境因素
2、QA工程师汇总报批环境目标、指标、环境管理方案，并监督验证实施。
3、QA工程师组织各部门编制项目部环境管理体系文件。
4、QA工程师负责与电厂、监理公司等的外部联络，接收外部相关方的投诉。
5、QA工程师组织制定项目部环境管理体系年度培训计划, 人力资源负责培训的组织、落实和记录管理。
6、QA工程师参与项目部能源、资源的节约控制；参与自然灾害的防范，现场事故的预防、应急准备和响应；参与消防设计评审；参与确定生活和生产活动中的环保监测项目和关键特性；参与生产施工过程噪声、振动、烟尘、污水排放控制。
7、QA工程师为各责任部门的培训提供技术支持；各责任部门负责实施。
8、QA工程师每月对废弃物处理的情况进行监督检查。
9、QA工程师负责组织项目部的应急准备和响应，建立应急方案，并监督实施。
10、QA工程师对监测设备和仪器进行统一管理、每月进行抽检。
11、QA工程师协助处理环境事故，协助责任部门分析不符合项产生原因，制定并实施纠正和预防措施，QA工程师监督实施。
12、QA工程师配合文明施工员每周至少二次到现场检查，形成环境记录。
13、QA工程师协助、配合公司组织的内审工作；为管理评审提供需要的信息。
14、QA工程师负责接收公司的信息并及时传达；负责汇总项目部的信息并按要求上报。
15、QA工程师每月对主管部门环境特殊、重要岗位人员相关知识、技能的培训情况进行监督检查。
16、QA工程师每半年对法律、法规及其它要求的遵守执行情况进行监督检查。
四、职业安全健康管理体系：
1、QA工程师配合安监专工编制职业安全健康体系策划书，配合安监人员对职业安全健康体系运行的整体情况进行策划。
2、QA工程师组织编制、修订、发放项目部职业安全健康体系文件；
3、QA工程师参与安全质量会议；
4、QA工程师参与公司、项目部组织的月度、季度安全大检查。
5、QA工程师监督验证检查中提出的体系性不符合的纠正和预防。
6、QA工程师参与对工程分承包方资料的评价，并对其施加影响提出建设性意见和建议。
7、QA工程师每月对MSDS的收集和发放进行检查、每月对化学危害品的使用检查,
8、QA工程师配合安监专工对项目部的应急预案和响应方案的建立、实施情况进行检查；
9、QA工程师检查各部门目标的分解和管理方案的落实情况。

Ⅳ 我是个程序员，但是我们经理让我做QA! 我没做过QA。请问转QA好吗我在的是个小公司！

你不可能在一个小公司一直做程序员，让你做QA应该是不错的选择。
而且更多的是管理经验。

Ⅳ 北大青鸟分享选择程序员发展方向时必须知道的事

如果你是一名初学者，对编程非常感兴趣，想成为一名合格的程序员，那么这篇文章就是为你写的。

从初学者成长为一名合格的程序员需要一段时间的磨练，每个人付出的时间和做事的效率不同，我不好评判你需要多长时间才能学有所成。北大青鸟http://www.kmbdqn.com/认为站在求职的角度，能开发出实用的软件、网站、APP等才叫学有所成。

程序员的发展方向计算机涉及的知识非常广泛，不可能在短时间内全部学完，即使公司的CTO也不可能样样精通，初学者要选定一个方向，不要想着把客户端软件、网站、APP都开发出来，这在短时间内是不现实的。相信我，你不是神！

1、Windows开发

主要是开发客户端（PC机上的软件），如QQ、迅雷、360等，需要学习C/C++、WindowsAPI、操作系统原理、数据结构、算法等。

2、游戏开发

需要你有Windows开发的基础，再学习DirectX图形编程、Socket通信、游戏服务器架设等。

3、Web开发

也就是做网站，分前端和后台。后台主要负责服务器端的编程，需要学习Java、PHP、Python等一门Web开发语言；前端主要负责网页的设计，需要学习HTML、CSS、JavaScript等。随着互联网的崛起，人才需求量大，工资高，很大一部分程序员都在从事Web开发。

4、底层服务

NB的程序员都在搞这些，例如编写一个线程池为上层提供服务。工资比普通的程序员高。

5、算法

也是NB的程序员在搞，一般不注重编程语言，而是侧重解决问题的方法和效率。工资比普通的程序员高。

6、移动开发

包括IOS和Android，你可以开发APP，也可以开发游戏，需要学习Java（针对Android）、Objective-C（针对IOS）、Swift（针对IOS）等。

7、软件和硬件结合

包括嵌入式和单片机，不仅要会写代码，还要了解硬件，所以入门门槛比较高，知识也比较庞杂，学习时间长。选择该方向最好有数字电路、模拟电路和汇编的基础，非常适合电子信息工程专业的同学。

这个方向的同学，大部分去了中兴、华为等以生产电子产品为主的公司，工资虽然没有一般的程序员高，但是还说得过去。不过随着智能硬件的崛起，这部分工程师的春天或许就要到来了。

8、测试（QA）

一款产品问世需要大量的测试才能投放市场，QA（QualityAssurance，译为“品质保证”）人员就是为程序员把关的，如果程序员的作品不符合产品需求或者Bug太多，QA有权驳回，这时就会影响程序员的绩效。

QA不但要能看懂代码（大概理解什么意思），还要掌握一定的测试技巧，更重要的是心思缜密，有耐心有毅力，女生比例很高。

拿到融资的创业公司、规模不大的公司、一些国企等给的待遇也不错，年薪也可以超过10万。

Ⅵ 在IT公司做QA有发展前途吗有上升空间吗

QA在软件开发流程中是很重要的角色，是项目支撑人员中协助项目经理完成质量监控，质量审计，质量问题跟踪以及项目关键流程的制定的角色。地位非常重要，而且需要掌握深厚的相关业务知识。做好了的话前途很大，主要还是看个人能力的情况。QA能够做好的话，如果再懂一些对应的业务，都是可以向项目经理转型的：）

Ⅶ 我们需要专职的 QA 吗

有不同的观点，有争论总是一件好事，这样可以引发大家的思考。所以，对于我的这篇博文，如果你赞同我的观点，我会感到高兴，如果你会去认真地深入思考，我也会高兴，如果你反对，没关系，可以讨论。在此之前，我想说明一下我观点里的这个“专职QA”是怎么定义的。其是很多公司成立的专门做测试的技术人员，仅测试不开发。这些QA对于软件开发技术并不熟悉，甚至不懂。我经历过一些公司都有专职的QA团队（专职的测试人员），自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟，我越来越怀疑专职QA存在在意义。我的观点不一定对，但请让我鲜明地表达一下——我觉得是不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选，这必然是未来的趋势 （因为我已经看到了中国程序员的进步，相比起10年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。在我正在展开说明之前，我想引用两篇文章：两篇文章一篇是 “On testers and testing”(中文翻译)，本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。他在文章中表达了这几个观点——大多数的开发团队并不需要一个独立的测试角色。即使要有，那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook，还是30年前最初的NT团队，很多伟大 的产品都是出自没有或很少测试人员的团队。开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”，这是一篇很不错的文章。他在文章里提到了分工的必要性，比如第三方的鉴定机构，并且也指出了分工的一些问题，比如，画地为牢的分工，无明确责任的分工，等，这些问题直接命中了分工的要害。我隐约觉得，我和邹欣的很多观点是相同的，我们内容上是相同的，只是形式上还有分歧。另外，我的观点太鲜明了，从而容易导向极端的理解。你看，我们都同意，Dev要懂测试，QA要懂开发，只不过分工不同，既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧。（另外，我个人觉得不懂开发的测试人员不可能测试得好） 我的故事我再说说我最糟糕的QA经历吧，这个公司的QA部门只做测试，他们的leader觉得所有的test design和test 的过程都不需要Dev参与，他们是独立于Dev之外的部门，他们几乎不关心Dev的设计和实现，他们只关心能跑通他们自己设计的test case。但是去执行Test Case的时候，又需要Dev的支持，尤其在环境设置，测试工具使用，确认是否是bug方面，全都在消耗着Dev的资源，最扯的是，他们对任何线上的问题 不负责，反正出了问题由Dev加班搞定。我有一次私自review他们的test case的时候，发现很多的test case这样写到 –“Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在test case design的时候，没有说明test environment/configuration 是什么？没有说明test data在哪里？Test Case、Test Data、Test Configuration都没有版本控制，还有很多Test Case设计得非常冗余（多个Test Case只测试了一个功能），不懂得分析Function Point就做Test Design。另外，我不知道他们为什么那么热衷于设计一堆各式各样的Negative Test Case，而有很多Positive的Test Case没有覆盖到。为什么呢，因为他们不知道开发和设计的细节，所以没有办法设计出Effective的Test Case，只能从需求和表面上做黑盒。在做性能测试的时候，需要Dev手把手的教怎么做性能测试，如何找到系统性能极限，如何测试系统的latency，如何观察系统的负载（CPU，内存，网络带宽，磁盘和网卡I/O，内存换页……）如何做Soak Test，如何观察各个线程的资源使用情况，如何通过配置网络交换机来模拟各种网络错误，等等，等等。测试做得也不认真，大量的False Alarm，都是环境问题，比如：安装新版本后没有重启服务，没有使用新的配置文件，网络配置，等等，等等。在项目快要上线前的一周，我又私自查看了一下他们的Test Result，我看到5天的Soak Test 的内存使用一直往上涨，很明显的内存泄露，这个情况发生在2个月前，但是一直都没有报告，我只好和我的程序员每天都加班到凌晨，赶在上线前解决了这个问 题。但是，QA部门的同学们就像没发生什么事似的，依然正常上下班。哎……为什么会这样？我觉得有这么几点原因（和邹欣的观点一样）给了QA全部测试的权力，但是没有给相应的责任，QA没有体会过软件质量出问题后的痛苦（解决线上问题的压力），导致QA不会主动思考和改进。QA对Dev的开发过程和技术完全不了解，增加了很多QA和Dev的沟通。QA对软件项目的设计和实现要点不了解，导致了很多不有效的测试。注：我无意在这里贬低QA的能力工作。只是我看到了QA因为没有参与开发的一些现实问题。我的观点邹欣对于分工出现的问题给出了两点解决方法：充分授权和信任（Empower team members）各司其职，对项目共同负责（Establish clear accountability and shared responsibility）我的观点是， 理论上正确，操作上太虚了。这就像我们国家喊的“为人民服务”的口号一样，没有具体的方法，根本无法落实。我无意在这里贬低QA的工作，我也无意因为这个事走向另一个极端。但是，我在现在公司的经历，还有很多新兴公司的做法，我越来越觉得软件开发，真的不需要专职的QA，更不需要只写代码不懂做测试的专职的Dev。观点如下：1） 开发人员做测试更有效开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及Soak Test 等。开发人员知道怎么测试是最有效的。开发人员知道所有的function point，知道fix一个bug后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。很多开发人员只喜欢写代码，不喜欢做测试，或是他们说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。另外，我始终不明白，为什么不做开发的QA会比Dev在测试上更专业？ 这一点都说不通啊。2）减少沟通，扯皮，和推诿想想下面的这些情况你是否似曾相识？QA 做的测试计划，测试案例设计，测试结果，总是需要Dev来评审和检查。QA在做测试的过程中，总是需要Dev对其测试的环境，配置，过程做指导。QA总是会和Dev争吵某个问题是不是BUG，争吵要不要解决。无论发现什么样的问题，总是Dev去解决，QA从不fix问题。我们总是能听到，线上发生问题的时候，Dev的抱怨QA这样的问题居然没测出来，QA也总会抱怨Dev代码太差，一点也不懂测试，没怎么测就给hand over 给QA了。QA总是会push Dev，这个bug再不fix，你就影响我的进度了。等等，等等。如果没有QA，那么就没有这么多事了，DEV自己的干出来的问题，自己处理，没什么好扯皮的。而一方面，QA说Dev不懂测试，另一方面Dev说QA不懂技术，而我们还要让他们隔离开来，各干各的，这一点都不利于把Dev和QA的代沟给填平了。要让Dev理解QA，让QA理解Dev，减少公说公有理，婆说婆有理的只站在自己立场上的沟通，只有一个方法，那就是让Dev来做测试，让QA来做开发。这样一样，大家都是程序员了。3）吃自己的狗食真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。在我现在的公司，程序员要干几乎有的事，从需求分析，设计，编码，集成，测试，部署，运维，OnCall，从头到尾，因为：只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。所以，真正的工程师是能真正明白软件开发不单单只是coding，还更要明白整个软件工程。只明白或是只喜欢coding的，那只是码农，不能称之为工程师。4）其它问题关于SDET。全称是Software Development Engineer on Test。像微软，Google， Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少，在Amazon是非常少的。那么像这样的懂开发的专职测试可以有 吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样的程序员分工合理吗？把程序分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET在实际的操作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。如果你说Dev对测试不专业，不细心，不认真，那么我们同样也无法保证QA的专业，细心和认真。在Dev上可能出现的问题，在QA也也会一样出现。而出了问题QA不会来加班解决，还是开发人员自己解决。所以，如果QA不用来解决问题，那么，QA怎么可能真正的细心和认真呢？如果你说不要QA的话，Dev人手会不够。你这样想一下，如果把你团队中现有的QA全部变成Dev，然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效？你有没有发现，在重大问题上，Dev可以帮上QA的忙，但是QA帮不上Dev的忙。第三方中立，你会说人总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是Dev交叉测试呢？你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。你可能会说吃狗食就是个笑话，因为如果是我，我把干烂的事，就离职走人了，让别人去吃我的狗食。这个在现实中 的确会发生，也是很现实的。但是想一想，你为什么在一开始让他把事干烂了？另外，如果你的团队在设计评审和代码评审里没有把好关，让某人把事给干烂了，那 么这个人的离职带来的问题还是这个团队来扛，于是整个团队都在吃自己的狗食，挺公平的。痛苦过一次，你的团队下次怎么干了，就不敢乱招人了，就不敢随意评 审代码了，就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。关于系统集成测试。所谓集成测试，就是把多个开发团队开发的模块集中起来测试。因为开发人员可以无法看到全 局，不了解别个团队的系统，所以需要有统管全局的专职的QA进行测试。对这个方面，我并不反对，在实际操作过程中，好像的确用专职的做集成测试的QA更有 效一些。不过，这还是不能让我停止去思考两个问题，1) 如果开发人员看不到全局，他能开发出更好的软件吗？2）这个全职的做集成测试的QA难道不能是各个团队的骨干Dev来组成吗？关于自动化测试。所谓自动化的意思是，这是一个机械的重复劳动。我想让测试人员思考一下，你是否在干这样的事？如果你正在干这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动，总有一天都会被机器取代的。关于线上测试。我们都知道，无论自己内测的怎么样，到了用户那边，总是会有一些测试不到的东西。所以，有些公 司会整出个UAT，用户验收测试。做产品的公司会叫Beta测试。无论怎么样，你总是要上生产线做真正测试的。对于互联网企业来说，生产线上测试有的在玩 A/B测试，有的玩部分用户测试，比如，新上线的功能只有10%的用户可以访问得到，这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人 员。好吧，我暂时写这么多，我会视大家的讨论再补充我的观点的。—– update —–一些人觉得我是在泄私愤，我能够理解为什么我会被这样误解，但是没有关系，很多新东西新观点总是会被误解的，我坦然面对。（全文完）

Ⅷ 什么是QE，与QA区别是什么

主要区别是，性质不同、从业资格不同、工作职责不同，具体如下：

一、性质不同

1、QE

QE，一般指质量工程师。

2、QA

QA，一般指测试工程师。

二、从业资格不同

1、QE

质量工程师是专门从事质量管理工作的人员，除了必须具有相应的质量管理知识和专业知识，相应的思想素质、智力素质和身体素质外，还应当具有必要的心理学知识和相应的心理素质。

2、QA

在企业中一般称为软件开发测试工程师（Software Development Engineer in Test，SDET）。一般为具有1-2年经验的测试工程师或程序员。有良好经验的测试工程师可以成长为产品/项目组的测试组长（SDETLead）或软件质量经理（SQA Manager），负责软件质量保证，进行测试管理和领导测试团队。

三、工作职责不同

1、QE

①、进行产品质量、质量管理体系及系统可靠性设计、研究和控制。

②、组织实施质量监督检查。

③、进行质量的检查、检验、分析、鉴定、咨询。

④、进行产品认证、生产许可证、体系认证、审核员和评审员注册、质量检验机构和实验室考核等合格评定管理。

⑤、调节质量纠纷，组织对重大质量事故调查分析。

⑥、研究开发检验技术、检验方法、检验仪器设备。

⑦、制定质量技术法规并监督实施。

⑧、设计、实施、改进、评价质量与可靠性信息系统。

2、QA

（1）、测试人员

①、编写测试计划、规划详细的测试方案、编写测试用例。

②、根据测试计划搭建和维护测试环境。

③、执行测试工作，提交测试报告。包括编写用于测试的自动测试脚本，完整地记录测试结果，编写完整的测试报告等相关的技术文档。

④、对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案。

⑤、提出对产品的进一步改进的建议，并评估改进方案是否合理，对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。

⑥、为业务部门提供相应技术支持，确保软件质量指标。

（2）、测试组长

①、 对软件质量负责。

②、 根据需求制定软件质量指标。

③、强调一定吻合客户要求的质量标准。

④、制定测试计划。

⑤、 领导制定测试用例和测试环境。

⑥、对测试进行评估。

Ⅸ 软件开发中的SD、SE、QA和RD是什么意思

SD:软件开发
SE;软件开发工程师
QA;QA也就是英文QUALITY ASSURANCE 的简称，中文意思是品质保证。
RD:则是指Research and Development(研发)。
在测试过程中，经常遇到需要和RD、PM沟通的问题。

1、写case时，对需求文档内容存在疑问。

解决办法：

1）先找之前参与需求评审的QA，询问；

2）问开发该需求的RD：查看RD排期，是否已经，或即将开始开发，若RD未开始开发，很多时候，他们也不是很了解需求内容。

3）若影响case的编写，可在企业微信上，直接问PM。若问题较多，可直接找PM当面询问。

4）若不影响case的编写，可在case里做标记，在case评审时抛出，请PM回答。

2、在开始测试的前一天，找RD确认是否能正常提测。有时RD反馈无法正常提测。

解决方法：

1）一定要确认影响提测的原因，如果当前自己排期内可消化，可在与其他RD沟通，并在自己排期内做调整。

2）一定要确认可以提测的时间点，如果是由于server端导致delay，是否可以让端上RD给个入口，端上先mock数据先测。

3）若端上或server有delay，一定要告知直接领导。

4）delay有可能导致风险，一定要及时抛出，若需要报risk，一定告知RD，一定及时在Jira提risk。

5）若严重delay，且server或端没有配合尽快解决，可邀请领导加入微信群，催促大家尽快完成；若问题非常严重，可邀请领导的领导加入微信群（谨慎邀请），催促大家尽快完成。

3、在测试过程中，遇到RD无法解决的bug，同时无法解决的bug数量不多。

解决办法：

1）告知PM：bug详情、RD反馈无法解决。

2）若PM表示不修改，则在Jira上对应的bug上备注并关闭bug（备注中要标明具体PM）。

3）若PM表示要修改，在企业微信上拉群：QA、RD、PM，在群里告知该问题，@RD和@PM，反馈实情，让RD和PM商量，并给出最终结果。

4、在测试中，若遇到RD无法解决的bug，同时QA感觉该问题比较影响体验，可告知PM且与PM达成一致后，拉微信群，@RD，反馈bug，让RD修改。

5、若QA感觉需求设计有问题，可与RD达成一致后，与RD共同反馈给PM。

6、在测试中，遇到RD无法解决的bug，同时无法解决的bug数量较多。

解决办法：

1）将问题一一统计，在企业微信上拉群：QA、RD、PM，在群里告一一抛出问题，@RD和@PM，反馈实情，让RD和PM商量，并给出最终结果。

若遇到特殊情况：

1）很多bug，RD反馈无法解决，PM反馈要修改，但RD和PM僵持不下，没有结果。

2）有的bug，QA感觉严重影响体验，但RD反馈无法解决，PM反馈当前版本不修改。

3）当前需求无法解决问题太多，严重影响用户体验。

4）若严重delay，且server或端没有配合尽快解决。

解决办法：

1）告知直接领导当前情况。

2）发邮件：列表格，将各个bug一一记录，加上RD的反馈，和PM决定当前版本是否修改，将表格添加到邮件中，在测试结束前，发邮件，邮件里@RD和@PM，使其在某个时间点前作出回复确认当前情况。邮件抄送给直接领导、QA全员。

3）如果问题很严重：严重影响用户体验，告知直接领导当前情况，找明明说明当前情况。

4）可邀请领导加入微信群，督促大家尽快处理当前问题；若问题非常严重，可邀请leader加入微信群，督促大家尽快处理当前问题。

7、在参加需求评审前，先阅读一遍需求文档，如果有疑问，需要记录下来，可在wiki的需求文档上直接对有疑问的地方备注提出问题，在参加需求评审时，直接提出，问PM。

若在需求评审上，有未确定的内容，在需求评审的checklist上，是否通过一栏，填写：“未通过”，并备注未通过原因，以及未确定的内容。需求评审后继续跟进，督促PM对会上未确定的内容作出解答，或开二次评审，需求上有更改、添加、删除的内容，督促PM在wiki上做相应的更改。

8、在测试过程中，PM作出的需求更改、需求添加，都要及时督促PM更新到wiki文档上。

9、向RD询问bug引入原因的时候（尤其是以前没有该bug，最近都没有对该部分作出修改，但是测试中发现了该bug），有些RD不配合查找bug引入原因。

沟通方法：

Ⅹ 我是学软件的，想转作QA测试，谁了解这一行都需要做什么

QA即QualityAssurance，它所关注的是对质量的测量及检查，还有通过改进过程来提高软件的质量，依次来指导软件的发行。QA关注产品生命周期的管理以及验证软件是否满足已定义的质量标准和用户协议。QA不是要对软件进行剖析以找出问题，而是要验证软件是否可能在一套给定的条件下工作。
1.安全测试
应用上线前的安全测试是必不可少的一个环节，需要对基础的用户名、密码进行检查，同时检查是否存在安全漏洞。尤其是如果这个应用是高度机密的应用，更应该与网络专家和安全专家合作，在检查过程中尽可能多地做好安全防控。
2.压力测试
一个应用任何时候都应该经过最大负载的压力测试，模拟这个应用在使用过程中需要提供什么支持，这样就可以验证该应用是可以应对这个负载的。如果应用运行在互联网上，压力测试的边界也应该从交易执行的地方扩展到全球的互联网节点。有时候在不同地区的互联网带宽或者服务是有限的。当应用在压力测试中出现故障的时候，可能意味着必须给这个应用分配更多的处理能力或者存储空间——或者必须开放交替的互联网通道以实现能够支持特定地理区域所需的带宽和服务水平。通过在压力测试场景下与网络专家和应用开发者的配合，可以识别这些潜在的检查点，这样就可以在部署应用之前解决这些问题。麦塔软件采用了最新的技术架构，创新的高并发大数据考试引擎设计，在大并发情况下性能稳定，降低客户了运营维护的成本。
3.用户测试
即使一个应用可以正常执行设计好的功能，但是如果用户无法理解或者无法使用的话，这个应用基本上就没什么用处。这就意味着在应用测试中应该与最终用户配合以确保该应用能够方便用户使用。如果不这么做，应用就不会被使用。
4.多界面部署
如果应用将要部署在多种终端上的话，该应用的用户界面外观和大小应该针对每种终端进行调整。在正式上线之前应该检查这些不同界面在各种设备上的可使用性，并检查加载时间等因素。
5.用户支持
在部署应用之前，技术支持部门应该对用户做一个系统的培训，指导用户如何安装、使用该应用，同时对使用过程中出现的问题及时给予技术支持。