恋爱素质？成为开发者！
恋爱素质？成为开发者！
原文：https://medium.com/hackernoon/love-quality-become-a-developer-9339d60dbcd6
如果你热爱质量，你应该考虑成为一名开发人员
Random drawings I’ve made for this post
作为一名以全职人工测试员的身份开始软件工作的工程师，我相信在以连续交付方式构建软件的同时，实现质量的最有效方法是将开发作为主要活动，交付实际的产品代码，并提倡将 QA 作为一个单独的角色。
这是一次尝试，带你了解软件行业中正在出现的争论、事件以及模式，它们强烈地鼓励我这样想。
猪身上的口红
不久前，在我脑海中引发火花的一个论点来自于谷歌测试工程总监 James Whittaker 博士在 T4 的一次演讲，他在演讲中说，你不能构建一个产品，然后在这个产品上再涂上质量。他的观点是，测试一个糟糕的软件只会表明这个软件实际上是糟糕的。
单独测试对提高一个已经存在的软件的质量没有任何帮助，已经太晚了，问题已经存在了。
那时我是一名质量保证顾问，是的，我知道敏捷测试，是的，我在做自动化测试，但是有些事情感觉不对或者至少是次优的。
信仰危机
我开始怀疑我所扮演的 QA 角色是否太以测试为中心，大部分时间都是被动的，并且专注于工具。在大多数情况下，答案是肯定的。通过快速搜索软件质量实践，你可以得到同样的结论。我确实接触了社区、博客帖子和一般的文献，QA 写的几乎所有东西都与反应过程和工具有关，当你进行测试自动化时，应该使用或避免这些工具。即使是著名的敏捷测试书对我来说也感觉过时了，因为它仍然在开发人员和测试人员以及谁应该做什么之间引起了不希望的分离。
我觉得我只是在扮演一个支持者的角色，有点像开发人员的拐杖。我觉得我应该亲自动手，直接负责我非常关心的软件质量的开发，这种感觉日益强烈。
当我得知 TDD 不适合 QAs 时
在 QA 的职业生涯中，有一天他会听说这个著名的首字母缩略词，仅仅通过听到它，就好像是对 QAs 意味着什么，因为它的名称中有 test 这个词。但是当你开始阅读一些书籍时，现实是测试驱动开发是一种设计活动，旨在从外到内逐步指导一小部分行为的开发。除非你有足够的技术知识知道如何让一个测试因为一个合理的原因而失败，然后驱逐它的实现，否则你绝对没有理由为 TDD 而烦恼。
这些知识对我来说真的是一个游戏规则的改变者，为什么一个实际上有助于构建高质量软件的技术却不适合 QAs 呢？当然，软件质量不仅仅是 TDD，但是这种认识让我更加质疑我的角色的影响范围。
你可能会说与的开发人员结对会让 QA 熟悉 TDD 过程，但是如果 QA 不够专业，不能真正理解正在发生的事情，他或她可能只会看着开发人员推动结对，并试图解释他在做什么，这会大大减慢整个过程。另一方面，如果 QA 实质上是技术性的，他可以通过成为一名开发人员而产生重大影响。
开发和质量应该是原子活动
为了自己的工作，很少有人愿意承认的事实是，如果你有足够能力关心质量的开发人员，没有一个只能充当 QA 的人，团队会更好。我知道这是一个严厉的肯定，但请原谅我。质量应该在软件创建之前和创建的时候就内置在软件中。你不能把质量委托给后面的阶段(给猪涂口红)。质量是核心问题，而不是附加问题。通过把质量保证变成一个职位头衔，公司无意中得到了完全相反的肯定。
开发者路径
成为一名开发人员感觉像是一个 QA 的自然的下一步，就像我一样是一个技术性很强的 QA。我有足够的自动化背景来开始。当然，成为一名开发人员需要的不仅仅是职位的改变，但是我被激励了。我在网上课程和个人小项目中学习了很多我觉得更舒服的技术。更重要的是，我开始像没有明天一样编码。
然后是我作为开发人员的第一个项目，我真的很担心能否熟练掌握技术堆栈中的每一项技术，但是你猜怎么着？团队中的其他开发人员也是如此。这种感觉让我们不断追求技术上的卓越，并且这种感觉在一定程度上是健康的。
团队中没有 QAs，我感觉自己像个间谍，我致力于在软件创作的每一个时刻注入质量，从故事叙述中使用我从令人惊叹的 Specification By Example 书中学到的东西，与我的搭档一起进行 TDD，根据像 Clean Code 这样的书籍中的想法对代码质量采取行动，甚至促进所有团队参与的短期探索性测试会议。
整个团队把质量作为核心原则。它就像病毒一样传染给每个人。其他开发人员对我(作为一名开发人员)建议的质量实践非常开放，事实上他们渴望最大化他们现有的关于质量的知识。没有角色的界限，团队可以自由地变得多功能和自组织。
我终于感觉到我对我们交付的软件质量产生了重大影响。
结论
我觉得 QA 作为一个角色在给定的时间框架内是必要的，但随着时间的推移，有必要彻底打破这种做法，否则质量将不会成为行业的核心问题。
我的个人经验告诉我，作为一名开发人员，我能够对交付的软件质量产生更大的影响，因为人们倾向于遵循他们在日常工作中实际看到的实践。例如，作为一名 QA，我可以推荐开发人员去做 TDD，但是作为一名开发人员，我可以通过做 TDD 来证明它确实有效。
“如何”并不是这篇文章的真正范围，我想要的是揭示“为什么”。因此，请继续关注更多与“如何做”相关的内容。
励志推荐人:
戴夫·阿斯特斯和史蒂文·贝克- RSpec 和 BDD
更多的测试。较少测试人员
戈杰科·阿季奇- 与敌人共眠
