我是一名中高级开发人员，去年对编程感到精疲力尽，而且我一直在探索将职业转变为测试/质量保证（例如技术写作）的可能性。我希望这个问题不在这里。我已经在Programmers网站上提出了要求，并得到了mod的指导。
有一些原因使我认为我对QA的评价要比对Development的评价要好：
“ Meta “知识工作”与“知识工作”
我自然地（从后退一步）分析已经存在的事物要比实际上深入研究（在磨刀石上进行研究）要好得多他们。例如，我擅长分析和分解感兴趣的主题并在其上撰写博客文章，但是我擅长创意写作-我必须自己提出所有内容。
对自己作品中的问题盲目
这是一个普遍存在的人类问题（这就是为什么作家需要编辑器而开发人员需要独立的质量检查的原因），但我认为我的情况很糟糕：我非常不擅长退后一步并看到自己工作中的问题（即，在开发方面：不良的初始预检测试）。在我的整个编程生涯中，我始终将高于平均水平的愚蠢显而易见的漏洞检查到源代码管理中。回退并在我自己的代码中查找问题非常困难。
另一方面，我非常善于发现其他人代码中的错误和可用性问题。例如，当别人破坏某些东西时，在获取最新的代码更改时，我常常是第一个注意到行为变化的怪人。
这与第一点有关：“元”知识的工作。我擅长从后退的角度分析某些内容，而且我并没有专心研究自己。
解决问题是一种挑战
当我不得不直接创意/修改所有权时，我真的不喜欢处理棘手的问题（例如模糊，难以跟踪的错误）带来的挑战。这又归结为“元”知识的工作-当我忙于某种事情并且必须自己完全解决时，我很容易感到沮丧和不耐烦（因此没有专心和低产）。但是当我在外面看着时，这种情况不会发生-例如。分析一个我最终只需要彻底记录下来并转给其他人的问题。
如果我不承认其中一部分只是想通过而不是最终负责某事。但这与我的分析技能配合得很好，相对于深入研究细节和做事，这比后退和分析要好得多。
重复的容忍度
这有点消极，但无论如何我想掩盖它，因为许多开发人员都认为测试/质量检查很无聊且重复。因此，我只想在它涉及之前就对它进行介绍：我对重复性工作有很高的容忍度，这似乎比较无聊。再说一次，由于“元”知识工作的原因，我很高兴地注意到某些事物发生了细微的变化，因为它之前运行了1000次。但是，只有我自己写的不是代码！
结论
请原谅，但我想尽可能清楚地说明要点。我特别希望听到曾经做过质量检查和开发工作的人员的意见，而且还希望获得普遍意见，以重新定义我作为潜在的测试人员或质量检查工程师的想法。附言毋庸置疑（作为一名在各种工作领域拥有10年经验的开发人员），我与Testers / QA有很多联系，并且对他们的工作有很好的了解。我过去做过一些（相对非正式的）质量检查-职位没有专门的测试人员，而开发人员测试了彼此的工作。对于它的价值，我总是比开发本身更喜欢它！
问题：我作为开发人员学到的技术是否可以很好地转化为执行质量检查？刚刚添加了一些说明。我认为我夸大了不想承担责任的意义。作为分析人员，我要比直接创建和修改事物要好得多。基本上，这归因于这篇文章中描述的思维方式的差异。对于开发中涉及的创建，修改和分析技能的特定组合，我的能力和耐心不是很好。但是当我离开一步并进行几乎纯净的分析时，我就会大放异彩（并享受更多）。
#1 楼
您描述了一些对测试人员有利的技能：分析技能，发现缺陷的能力和重复性。您似乎也对测试感兴趣。您自己承认的潜在劣势：不愿承担最终责任，并且在较小程度上不愿意从头开始。
您已经习惯了开发人员的薪水也许是开发商的声望。准备放弃两者。尽管有些测试人员的薪水高于开发人员，但总的来说，测试人员的薪水要低一些。尽管有一些摇滚明星测试员因在组织中的角色而受到高度赞扬，但作为一般规则，测试员被认为与开发人员同等必要，但价值却不如开发人员。当产品或项目取得巨大成功时，开发人员比测试人员更有可能在公司会议上获得支持或提及。如果这对您很重要，请适当设定您的期望。这并不是说测试很糟糕。在适当的情况下，这是一项很好的工作，但不像成为开发人员。
工作的性质取决于情况。在我的第一个测试工作中，我是测试负责人。这需要组织起来，花费大量时间进行沟通，与对测试没有兴趣的开发人员打交道，跟踪许多项目级别的信息，并对重大事务负责。它还需要一些轻型开发技能。这是一项很好的，有意义的工作，我的努力为我赢得了称赞。考虑到您的背景，这对于您可能是一个很好的角色，但是您必须愿意拥有它。
编辑：这里有一些关于QA聘用以及开发工作与测试工作之间关系的很好的讨论：拥有开发人员经验或背景对测试人员的效率有什么好处？，如何为测试职位做准备？，您应如何面试质量保证职位？测试人员对软件的看法与开发人员的看法有何不同？ （如果您搜索SQA，也会发现其他名称。）
评论
+1谢谢。我绝对不分阶段谈论薪资和声望，但我可以理解您对承担责任问题的意思。不过，我应该指出：这个人被实际的一线创造者（而不是被淘汰的分析仪）所放大。
– Bobby Tables
2011年9月9日下午0:30
@ user246回复：您的编辑+链接：谢谢。那些很有见地。多数情况下，这是一种很好的方式（可以肯定的是，与测试相比，我在测试方面的投入更大）。
– Bobby Tables
2011年9月11日23:04
#2 楼
改变职业总是挑战。作为一名招聘经理，当有人想改变职业并被录用到我的团队时，总是会发出危险信号。我在这里看到了一些。你说你被开发人员精疲力尽了。这是可以理解的。那么，您是否认为质量检查比较“容易”？不太可能导致倦怠？准备与面试官深入讨论。我希望我的QAers能够非常努力地工作（有时我们比开发人员更努力，有时则不然）。我不希望有人想到这是一个让事情轻松的机会。
您提到分析而不是创意。至少在我的团队中，质量保证人员必须经常具有创造力。
感谢您对不承担责任感到诚实。大多数质量检查部门都需要承担很多责任。在某些商店中，质量检查是生产的守门员-那里的责任很高。
我以前曾聘请前开发人员加入质量检查（哎呀，我曾经是开发人员）。但在从开发人员向质量检查人员的直接过渡中，这种情况并不常见。准备好面对一些棘手的问题，这些问题涉及您为什么选择质量检查作为目标，以及招聘经理如何知道您也不会很快就被淘汰。
您是否可以转换？进行您当前公司的质量检查？通常，这是最简单的转换类型。
祝你好运！
评论
+1谢谢。我应该澄清：在我自己直接进行工作并自行创建（直接更改工作的具体对象）的情况下，承担责任对我来说确实是一个问题。当工作包括分析后退内容时，它不会出现。我认为部分原因是信心：与埋葬在细节中相比，我在退一步和看到细节方面要好得多-擅长某些事情等于更有信心去掌控它。这绝不是一个完全不负责任的普遍问题。
– Bobby Tables
2011年9月9日在21:42
#3 楼
如果我不承认其中一部分只是想让自己承担责任，而不是成为最终负责某件事的人，我会在理智上不诚实。
在SQA您对功能的责任要比开发人员要高。当令人讨厌的错误进入生产环境时，您全都注视着您，您必须执行RCA或说明如何错过它。如果这会造成收入或帐户损失，请准备承受更大的压力。正如在另一个答复中提到的那样，您将永远不会获得流畅运行功能的荣誉，只有在出现问题时才会被注意。
您提到了重复的容忍度，这是一个必要特征。您是否还准备好迎接脑子麻木的点击和打字？自动化始终是目标，但令人怀疑的是，您会避免长时间的无聊的手动测试，尤其是在完全回归过程中。
我并不想说服您-只是想澄清一下几点。听起来您知道自己的能力和最适合的专业。我从前端开发人员转到了质量检查人员，并且没有回头。很幸运，我可以在同一学科的团队中工作，因此我可以两全其美。
正如另一位评论者所述，您失去了一点声望和薪水，但工作满意度却是比付出或尊重更重要。我说去吧。
评论
+1谢谢。请参阅我对Joe Strazzere的帖子re：责任的评论。就声望和薪水而言，我一点也不在那儿。
– Bobby Tables
2011年9月9日在21:48
#4 楼
几年前，我做出了同样的选择。我是一名测试人员，后来进入C ++ C＃开发，然后又回到测试中。我仍然喜欢编写代码，并且在测试中有一些编码机会。我之所以退缩的主要原因是，在开发过程中，我发现我最享受的是错误修复。我知道这听起来有些琐碎，但我发现解决问题的方面比编写新功能更吸引人。测试非常像错误修复编码，而不是功能编码。我在使用特征编码时遇到的问题是，当您要添加到现有代码库中时，您基本上就适合该框架。这里的所有其他注释都非常有效，您应该仔细考虑它们。迁移到测试总是被您的任何同事视为下一个步骤-就是这样。
要记住的另一件事是，测试人员处于周期的最后，他们在需要运送之前拿到东西。有时请注意，质量是质量的水平，而不是绝对的水平（绝对没有缺陷）。最后，您仍然必须始终愿意为要解决的缺陷而战，同时要了解您并不是发布产品的最终决定权。
评论
+1有趣。是的，我非常了解必须发布不尽人意的政治，等等。我发现处于开发阶段的压力更大，因为试图在最后一刻挤压更改/修复通常会破坏其他事情，并且因此，我讨厌看起来很糟糕。当我处于测试方面时，我并没有发现它很糟糕-我只是记录了许多未解决的问题，并指出“不要说我没有警告您这个缺陷仍在发行中。”但是我可以想象，在某些环境中，这也会带来压力。
– Bobby Tables
2011-09-12 23:27
#5 楼
开发人员已经有20年的开发经验，然后才转向过去四年来所做的测试，一点也不后悔。关于必须提出所有内容的第一点引起了共鸣-我非常擅长完成程序，但不擅长启动程序
问题解决-您举了一个在跟踪难以修复的错误时感到沮丧的例子。那就是作为测试员的我喜欢做的事情之一，当该问题消失时，您会意识到使它具有可重现性的原因是什么？
还有一点-是要进行测试还是质量检查？或两者 ？您真正必须做的一件事就是不要再给它们打电话了:)
评论
阐明您认为测试和质量检查的不同之处可能对您很有用。在某些软件组织中，这些术语可以互换使用。
–user246
2011年9月11日17:30
我应该澄清一下：我喜欢追踪错误，我只是不喜欢成为必须修复它的人，或者不喜欢冒险通过这些更改破坏其他东西的人。只是成为某种东西的“直接执行者”，而不是纯粹对我不起作用的纯分析器。很难解释，但是非常真实。是的，回复：user246的问题，测试和质量检查之间的实际区别是什么？在与我合作过的组织中，它始终是可互换的。
– Bobby Tables
2011年9月11日下午22:06
测试-您测试产品（即QC），并定义制造产品的质量保证程序。试试Michael Bolton的这篇文章-测试人员：摆脱质量保证业务-developmentsense.com/blog/2010/05/…
– Phil Kirkham
2011-09-12 6:57
#6 楼
首先，我要赞扬您对自己的优缺点进行诚实，透明的内在检查。我觉得不够。盲人的想法：我认为这是“偶尔看不到森林的树木”的一种变体，我有时会因此而遭受痛苦。开发人员和测试人员都必须保持整体心态，并从整体上看待该程序，永远不要忘记有很多不同的部分（模块）一起流动。这种整体思路也适用于测试用例，脚本，场景等。甚至是你写的。只要您能做到，就听起来不错。需要思考的问题：您是否有一位同事可以审查您的测试文档并就这些文档提供诚实的反馈？
解决问题的思想：您提到容易感到沮丧和不耐烦。虽然从来都不是“门垫”（因为现在缺少更好的词），但测试人员确实需要有一定的耐心。指出某人工作中的缺陷，特别是如果该人的身份存在于该产品中，则可以“测试”您和您的耐心。沟通技巧必须出色。就个人而言，我必须从“销售”的角度来看一个错误。我可以将此错误“出售”给开发人员的最佳方法是什么？和/或管理-如果开发人员不会给我时间？如果您认为错误是高优先级的（在您眼中）说一个安全漏洞，而他们却说低优先级（“没有人会这样做”），您如何看待自己的反应？我保证这种情况会发生。耐心的蚱hopper。
容忍重复的想法：一个字一个字，这部分是我。自1988年以来，我一直从事质量检查（以一种形式或另一种形式），这是我的2美分重复费用。当我阅读本文时，出现的危险信号是：浪费时间。这里的危险是舒适区。必须区分一个有用的重复测试和不产生结果的测试，应该对其进行修改或完全扔掉。出色的测试人员将始终保持灵活性，并知道何时放手。
我可以添加的唯一一件事，也许您已经以开发人员的身份进行了处理，这是一个出色的测试人员，需要准备好捍卫他们的信念，并为（预期的）推迟做准备。正如user246正确提到的那样，测试人员是工程师的阶梯。尽管我天生就是要测试并且不关心这一点，但是仅凭这一事实并不能使某些人满意。这将极大地影响他们决定是否从开发过渡到测试的决定。
编辑补充说，我从来都不是开发人员，所以我的回答不是从以前的开发人员角度出发。质量检查是我的热情，一直如此。
评论
+1谢谢。好点。 :)我也要使用“看见森林换树木”这个词。我认为我在开发中遇到的所有问题都具有相同的根源，这就是为什么不不断提及“元知识工作”而难以提出不同观点的原因。当我直接参与知识资本的创建/更改时，我真的无法解释为什么我在细节上有问题，但是当我只一步之遥时，我却无法解释。但这是整个过程的关键。 :)
– Bobby Tables
2011年9月9日在21:52
#7 楼
我的两分钱，主要是根据您的一个观点-重复容忍度
这有点消极.........我写的自己！
如果您做重复无聊的工作，那么您的工作将被自动化或者您将被离岸国家的低成本资源所取代。
去年编程严重烧尽了。
没有详细介绍，这是怎么发生的？您有10年的经验。如果您生存了这么长时间，那么您可能可以生存更长的时间。如果我是你，我不会选择一个花哨的，技术上具有挑战性的项目。我会选择开发中的常规内容。
评论
这是一个问答网站，而不是论坛。如果您想问“这是怎么发生的？”之类的问题，请在评论中进行。另外，请注意，问题来自四年前。
–user246
15年7月17日在20:04
我不想阻止您参加stack1，但这实际上并不能回答问题。当然，当我看这个问题时，事实证明没有问题可以回答。 OP描述了他的处境，说他正在寻找别人曾经做过的事情。它根本不问任何问题。因此，我不能完全责怪您未回答一个不存在的问题。该问题应该已经（并且将要结束），因为没有实际的问题。
–corsiKa♦
15年7月21日在23:50
评论
嘿，到这里参加聚会有点晚了，但这实际上没有一个“问题”，因此无法真正回答。并不是说下面的“答案”中没有智慧，因为确实存在，但是应该知道，这不是应该在Stack Exchange上提出这种体裁的问题。发布新标题以尝试使之成为一个可回答的问题。但是，即使进行了标题更改和问题插入，也仍然感觉像“告诉我您的个人经历”，这根本不是问题。
重新命名以查看是否可以重新打开