一本以
另一本为辅，我的文章对于那些尚未找到“自己的风格”并且不确定从何入手的人来说，可能是一种行动指南。
有人回答说我在写“共同的事实”，但与此同时，我在“有用”，“现在需要什么”等类别的评论和个人信息中收到了很好的回应。 但是还有问题。 在很大程度上，这些问题归结为在其职业生涯中未通过一次质量检查的“痛苦”：
- 如何与开发人员有效互动？
- 如何与他们一起安排工作，以使他们接受：对项目还有其他意见，即质量检查的意见，这也很重要吗？
- 如何鼓励他们互动，例如，在未配置为共同工作的情况下构建联合测试自动化时？
- 如果您所使用的技术堆栈中的技术技能根本不够，该如何处理？
我必须马上说这个话题非常敏感，要谈论这个话题，您必须始终在不损害开发人员和质量保证本身的骄傲的前提下保持平衡。 因此，请您冷静地阅读，并尝试突出一些有用的观点并在实践中加以尝试。
引言
首先，正如实践所表明的那样，通常那些没有按照专业要求进入开发的质量保证人员
- 根本不自信。 他们无法做到听到自己的声音，因为他们听不清声音，说话不合理，表达了持续的怀疑。
- 他们害怕犯错误并承担额外责任；
- 由于技术知识不完善而变得复杂。
其次，团队中的开发人员将质量检查视为附件，它只是在将产品提供给客户之前按了按钮，或者根本没有想到如何与他们互动。 这可能是由于以下事实：
- 他们仍然将质量检查视为10到20年前的测试人员，当时他们还真的是。
- 他们以前以完全相同的方式运作的所有质量保证和行为方式，并且他们根本不知道会发生什么；
- 原则上，他们不知道质量检查工程师工作的本质是什么，因为他们根本不需要它-他们的技能得到了发展；
- 代码开发已经很成熟，更改其中的某些内容只是懒惰。
让我们从第一个问题开始。
质量检查工程师！ 春季大扫除
努力了解您的职业
如果您想改变世界，请从自己开始。 在我们的话题中众所周知且非常相关的事实。
作为质量检查工程师，弄清楚自己所担任的职位并不会真的伤害您。 如果您的项目仍然遵循瀑布式架构的原则，而您只是由手动测试员雇用，他就像企业中的OTK一样，检查最终产品的准备情况，那么这是一回事，这里的一切都非常透明。
而且，如果您现在已经是一名全面的质量检查工程师，现在已经几乎成为通用工程师，那么这意味着您在[1]中由专业人士确定的职责不仅是测试成品，而且还直接参与组织其创建过程以及与参与者之间的互动整个项目。 请记住，没有清晰的团队流程和团队组织，几乎不可能获得优质的产品，因此，在此领域，质量检查的声音应该听起来充满自信和明确。 为了防止错误的出现，而不是事后解决-这是组织良好的团队。 质量保证小组的工作是尽最大努力减少错误的数量。 （圆圈关闭。）
因此，首先要回顾有关QA工程师职业的原则，类型，测试级别和措辞的所有基本知识。 理解臭名昭著的“我是谁？” 和“我为什么在这里？”
查找问题的答案
专业的自我探索结束后，为自己制定一个计划，要做的事情，可以从我的文章中汲取灵感或制定适合自己情况的计划。 您的活动的每一点都应该对您自己清楚-为什么要这样做，如何执行，要有什么好处。
只有在这种情况下，您才能对项目充满信心。 即使到目前为止您只知道“为什么”和“有什么好处”问题的答案，但您却不知道“如何”。 从您看到工作的最前面这一事实就已经充满信心，正确制定任务是80％的成功。
下一步是写下您需要解决的问题，以便回答“如何”问题。 然后去找这个人，也就是说，与团队讨论-在专门组织的会议中，在公司之间进行聊天或在厨房里非正式地喝一杯咖啡都没关系。 重要的是，您的项目中必须有不同经验，其他知识的人，使用这个有用的信息库，进行交流，询问，所有事情都将得到澄清。
抛弃不完美的体验
如果您很害羞，或者生活中总是极力追求领导者的极简主义者，那么很难发挥QA的作用。 因为QA工程师是工程师，所以他是开发人员，但是与此同时，我们发现自己处于具有不同技术和体系结构堆栈的项目中，而开发人员则拥有自己的专业知识。 认识到您对某些人来说是“话题”，这意味着将自己写成“弱链接”。 这就是我的问题，我为此苦苦挣扎了很长时间。 “是我需要说的，我不知道，我不知道，我不明白吗？！” -不止一次，我在讨论所有技术方面时陷入僵局。
但是直到最后，我才终于意识到，不知不觉是一种耻辱。 我为继续“隐藏在壳中”而不是试图找出来感到ham愧。 保持沉默，似乎通晓，对自己来说是很重要的。
您已被录用，他们会阅读您的简历（您将确保自己的能力；）），在面试中与您交谈，然后就被录用了。 因此，您的技术技能对每个人都很好，而雇用您的人已经猜到了期望。 因此，跳到头顶上现在是没有意义的。当您说“我从未尝试过，但是我想弄清楚，帮助我理解这个和这个问题”时，这是绝对正常，健康和正确的情况（不要仅仅把最主要的观点带到荒谬的地步。知识-定义和公式-从互联网上学习）。 而且，当您向他人表明您不了解这种技术背景时，首先，他们已经觉得有必要进行更简单的沟通，其次，您可以以清晰的良心提出清晰的问题。 如果您编写代码一次或两次并且完全了解项目的内部架构，那么您可能会直接参与开发，对吗？
我最喜欢的小窍门是，在我有能力时，总是以行为，建议和友好的言语帮助他人，这又伴随着他人互相帮助我的渴望。
不要害怕犯错
认为工作流涉及所有可能选项的讨论是理所当然的。 真理源于争执。 您的任务不是正确的，而是找到最佳的解决方案。 而且，如果您想提供某些东西，但又害怕听起来会很愚蠢，那么请相信我，我看到了多少支球队，最无动于衷的沉默寡言的同事看上去是失败者。 认识到我们的一些错误，支持最佳创意并为实现这些创意做出积极贡献是一个健康的工作流程。
请记住，电影《莫斯科不相信眼泪》中的穆拉维耶娃女主角在进入图书馆之前就摆好了位子：“如果你脱口而出，自信地脱口而出-那就是所谓的观点”。 确实有效。
不要害怕将无法处理的任务召唤给自己。 请记住，您在团队中工作，并说有些事情没有解决，并向团队寻求帮助是正常的。
即使您在工作过程中得出“不必这样做”的结论，也将是进步，因为下一步就是寻找最佳解决方案。
发布过时的标准，展望未来
这些因素使质量保证处于低位，在团队中发现的重要性不是那么重要，也不是那么重要。 虽然您自己这样认为，但您却低估了这种趋势，a，进食。
您每天工作，每天都在努力，使产品和团队变得更好，您花费时间和精力，您的职位位于项目框架中-这意味着它是重要且必要的。 仅此而已。 不要为自残行为留有余地，也不要为那些认为您的地位比他低的人留下“嘲讽”的余地。 这些时候，当有简单的猴子测试仪手动测试仪被遗忘时，将来，QA工程师是“一支精锐的特种部队，其成功取决于出色的战术和现代武器” [2]。
请记住，如今在诸如Microsoft和Google之类的领先公司中，“开发人员应对质量负责。 如果产品在释放后破裂，那么锥体将飞向造成问题的开发商，而不飞向没有发现问题的测试人员” [2]。 因此，在这样的公司中，拥有质量保证团队将有助于开发优质产品是开发人员的特权。
而且，您无需再回顾过去的刻板印象，就可以在公司中引入高级原则。
但是，我再次回到一个事实，那就是您需要在项目中不断发展。 如果您参加了该项目，已经过去了六个月，但是您仍然没有提出有效的测试自动化方法，不要试图弄清楚团队正在做什么，不要分析现有的自动测试，那么您就不是书本上所写的精英。
我知道有些团队根本没有QA工程师的职位。 而且，如果您今天已经在努力使自己沉浸在项目中，并学习如何与开发人员一起编写自动测试，则有一天您甚至可以在这里出售您的能力，并成为在那里进行测试的软件工程师。
质量检查工程师！ 微调团队合作
当您自己完成工作后，就该与开发人员建立协作了。
最重要的
- 您的行为对团队应该是透明和透明的。 最简单，最有效的方法就是将任务传达给他们。 如果您无缘无故地开始询问他们“您在这里进行什么样的测试？”，“但您应该编写这样的测试”的请求，那么第一个（保护性）反应将是“你要去哪里？！”，“你/谁批评我的工作？！”。 他可能已经煮了一周的早午餐，最后呼出气，然后由质量检查人员得到。 因此，请提前告诉他们您将要做什么，为什么以及对项目和团队有何好处。 准备土壤。
- 您参与先验开发应该被视为一种祝福，因为它可以从本质上改善开发人员的工作。 成为他的伴侣。 例如，进行教育-告诉客户可能如何使用该功能，已经发生了哪些错误以及应该避免哪些错误，这意味着一起考虑哪些测试以及为什么重要。 不要以当务之急的方式交流。 您甚至可以求助于心理技巧-注意那些在某些最终报告中以“我们都做得很好！”格式增加自测范围的人。 感谢您的工作总是很高兴。 具有自动测试覆盖范围的传统质量检查评论也是共同努力的动力。
让项目上的更改变得流畅。 如果您有一天早上上班说：“我已经读过一篇有关哈布雷的文章，那么您将开始在有条件的平台上拍鞋子，摇晃空气，他们说，现在我将向您展示库兹金的母亲！”，他们会奇怪地看着您，这是事实。 是的，面对所有方面的问题，对您来说将是困难的，人们将不可避免地希望放弃改善质量保证工作的整个想法。
更好地为每个人设置一些可以理解的小任务，实现它们并承担以下任务。 小心翼翼地前进，时间过得很快，有一天可以回头。
回答特定问题
在
我的第二篇文章提供了质量保证和开发的紧密合作之后，观众从“我们尝试过，但开发人员的团队负责人并不想见面”类别中退出。 从目前的专业发展水平来看，我只能提供以下建议。
友善并以智慧对待自己，使那些不按预期接受您工作的人平静下来。 在我的实践中，我遇到了许多不同的开发人员，并且所有真正专业上成熟的人总是来找我见面，总是得到帮助，我们取得了出色的共同成果，他们都感到满意。 可惜的是，那些“ s鼻涕”和“向你挥手告别”的人属于“专业青少年”类别。 他们还没有学会去应付自己的感觉，认为自己是最右翼的人（身体年龄在这里不起作用）。 他们根本不知道如何在团队中工作，而您是其中不可或缺的一部分。 您可以帮助他们成长，但是不幸的是，有些人永远都不会成长。 在这里，您只能通过领导层的支持以及将为您提供支持的其他团队的集体权威来影响他们。 如果您知道最好的方法，请分享！
还有一个有趣的问题，即如果您还不知道如何阅读开发人员代码，而又无法弄清楚他们的自动测试，该怎么做。
我将答案留在这里，以免丢失，也许有人会派上用场。 如果您看不懂它，我会坚持在PR说明中包含已开发的自动测试列表，并专注于它。 我认为，这是质量检查团队的全部权利和责任，即尽可能了解自动测试产品的覆盖范围，否则质量保证的整个概念就会消失。如果我们考虑包括开发人员在内的整个团队时间紧张的情况，那么我会坚持要求进行审查集成自动测试覆盖关键/战略场景。 对于所有其他情况，我记录了单独的任务，以备后用。 在任何项目中，都有无期限的平静时期-因此值得产品经理/团队负责人/ Scrum Masters集中精力介绍如何包括这些任务：它更复杂-让开发人员自己做，自己学习最简单的方法。
结论
我不能说上面写的所有内容一定会对您有所帮助，毕竟，我感觉我自己的专业声音和风格会伴随经验并遇到麻烦。 这是不可能的，以及如何通过模具将他人的工作脚本应用于您的项目。 但是，如果我的随意性提示您不要忍受自己不喜欢的时刻，并且脑海中有想法可以为自己，对团队，对产品做好事，那么我就白白浪费了时间。 是的，不要以为我描绘的QA Shark知道一切，也知道一切。 我不断学习和改变。 我很清楚，一年之内我的工作原则可能会发生变化。 总是对反馈很满意，我很乐意从您的经验中学到，写；）
如果您想阅读一些东西来增强自己的动力，请从两本精彩的书开始，这是我在课文中提到的：
1.软件测试的基础：ISTQB认证
多萝西·格雷厄姆（Dorothy Graham），雷克斯·布莱克（Rex Black），埃里克·范·维嫩达尔（Erik van Veenendaal），伊莎贝尔·埃文斯（Isabel Evans）
2.如何在Google上进行测试
詹姆斯·惠特克（James Whittaker），杰森·阿邦（Jason Arbon），杰夫·卡罗洛（Jeff Carollo）
谢谢大家的关注！