测试软技能
It’s not flexibility, can-do attitude, or patience. These are all important, of course, but there is one that stands out above all — diplomacy!
这不是灵活性，可以做的态度或耐心。 当然，这些都很重要，但是最重要的是外交！
Here’s a succinct definition:
这是一个简洁的定义：
the art of dealing with people in a sensitive and tactful way
以敏感和机智的方式与人打交道的艺术
Given this definition, we can argue that diplomacy is a perfect blend of the most vital soft skills a tester should have:
有了这个定义，我们可以说外交是测试人员应该具备的最重要的软技能的完美结合：
Communicative: a project has many stakeholders — technical, sort of technical, and not technical at all. So you have to speak at least three different languages with each group. Developers, managers, users, automation engineers, other testers — all speak using their own jargon.
交流的 ：一个项目有很多利益相关者-技术的，某种技术的，而不是技术的。 因此，每个小组必须至少讲三种不同的语言。 开发人员 ，管理人员，用户，自动化工程师和其他测试人员-都使用自己的行话讲话。
Empathetic: developer needs != business user needs. Not only do stakeholders speak “different” languages, but they also have different perspectives and sometimes conflicting interests. We have to learn to be on everyone’s side, no matter how paradoxical it may sound.
善解人意：开发人员需求！=业务用户需求。 利益相关者不仅会说“不同”的语言，而且他们也有不同的观点，有时甚至是利益冲突。 无论听起来多么矛盾，我们都必须学会站在每个人的一边。
Tactful: not just reporting issues, whether in requirements or software, but doing so without being arrogant or “I told you so” attitude.
机智 ：不仅报告问题(无论是需求还是软件问题)，而且不要表现出傲慢或“我告诉过你”的态度。
Diplomacy is interwoven in nearly everything you do as a QA professional: bug reporting, emails, meetings, 1-to-1 conversations. I see developers as the most important stakeholders for both test analysts and automation engineers, and so this article highlights four key diplomatic actions you should start doing immediately.
外交几乎与您作为QA专业人员所做的一切交织在一起：错误报告，电子邮件，会议，一对一对话。 我将开发人员视为测试分析师和自动化工程师的最重要利益相关者，因此本文重点介绍了应立即开始采取的四个关键外交措施 。
1.对开发者做出个人承诺 (1. Make personal commitments to the developer)
In his superb YouTube lecture on testing, James Bach says that he tries to “charm” developers by giving them a piece of paper with 13 commitments.
詹姆斯·巴赫(James Bach)在YouTube上关于测试的精湛演讲中说，他试图通过给开发人员13项承诺的方式来“吸引”开发人员。
I recommend watching the entire lecture, but here’s a shortened list from 1h 31m 17s:
我建议观看整个讲座，但这是从1h 31m 17s起的简短列表：
You don’t have to use this exact wording, and you can phrase it any way you like, but the message you should deliver is clear
您不必使用这种确切的措词，也可以按自己喜欢的方式措辞，但是您应该传达的信息很明确
“I am on your side, I am here to help you, and I shall do so to the best of my ability”
“我站在您的身边，我在这里为您提供帮助，我将尽我所能”
Try to sit down with a developer over a cup of coffee, chat, and try to get this message across. They are important, and you’re here to help them. When you do so, you’re being communicative.
尝试与开发人员坐在一起喝咖啡，聊天，并尝试传达此信息。 它们很重要，您在这里可以为他们提供帮助。 当您这样做时，就是在交流 。
2.提出简单的外交建议 (2. Make a simple diplomatic suggestion)
QA people are the bearers of “bad news” — we find bugs and this means developers have more work on their plate. But you can frame it differently and turn “bad news” into “good news”.
质量检查人员是“坏消息”的承担者-我们发现了错误，这意味着开发人员还有很多工作要做。 但是您可以采用不同的框架，将“坏消息”转变为“好消息”。
Here’s THE sentence that helped me build a smooth relationship with 4 out of 5 developers, especially in 1-to-1 conversations:
这句话帮助我与五分之四的开发人员建立了良好的关系，尤其是在一对一对话中：
“I just wish for us to find and fix bugs in QA environment and not in production”
“我只希望我们在质量检查环境而不是生产环境中发现并修复错误”
There are three important things to unpack here:
这里需要拆解三件重要的事情：
“us” — place yourself and the developer in the same team. “You” and “I” are unnecessarily divisive. You want to minimize any kind of division. If possible, sit at the same desk by their side as you say this, not opposite or across the table. It may not be possible with an increasing trend to work from home, I get it.
“我们” -将您自己和开发人员置于同一个团队中。 “您”和“我”是不必要的分裂。 您想最小化任何划分。 如有可能，请与您说的话坐在他们旁边的同一张桌子上，不要在桌子对面或桌子对面。 我知道，在家办公的趋势可能越来越大。
“find and fix” — even though we all know who will do the finding and who will do the fixing when it is used together with “us”, it sounds more like teamwork. (and it is!)
“查找并修复” -尽管我们都知道与“我们”一起使用时谁来做发现，谁来做修复，但这听起来更像是团队合作。 (是！)
“and not in production” — have you ever met a developer who is keen on fixing prod issues late in the evening under severe time pressure? Me neither. That’s something any sane person wishes to avoid. And YOU just made a suggestion to prevent this highly stress-inducing activity.
“而不是在生产中” –您是否遇到过热衷于在深夜的时间压力下在深夜解决产品问题的开发人员？ 我也不。 这是任何理智的人都希望避免的事情。 您只是提出了一个建议，以防止这种高度诱发压力的活动。
You may have stated the obvious, but it helps! You just reminded them that you are here to help them do part of their job (bug fixing) in a less stressful situation. You are being empathetic.
您可能已经说了明显的话，但有帮助！ 您只是提醒他们，您在这里是为了帮助他们在压力较小的情况下完成部分工作(错误修复)。 你很同情 。
However, there are two things that reduce the value of the above statement and the strength of the impression that it makes: bug-to-noise ratio and bug report quality.
但是，有两件事会降低上述声明的价值以及它所产生的印象的强度： bug噪声比和bug报告质量 。
3.您的错误报告是您外交官的面Kong (3. Your bug report is your diplomat’s face)
The nice diplomatic things you say must be backed by high-quality work. Your promises must not ring hollow.
您所说的美好的外交事情必须得到高质量工作的支持。 您的承诺绝不能空洞。
Bug-to-noise ratio: do investigate issues properly before writing up a bug. Consult with the developer beforehand if necessary. Why? You keep a decent level of competence and trustworthiness when you report at least 4 valid bugs out of 5. We all report duds sometimes, that’s OK. But if it’s the opposite, and over half of what you report turns out to be invalid, then why should developers waste their valuable time paying attention to you and your non-issues?
错误与噪音的比率：在编写错误之前，请先进行适当的调查。 如有必要，请事先与开发商联系。 为什么？ 当您报告至少5个有效错误中的5个时，您会保持相当水平的能力和信任度。有时我们都报告呆板，这没关系。 但是，如果相反，并且您报告的一半以上是无效的，那么为什么开发人员应该浪费宝贵的时间来关注您和您的非问题？
Once I had a streak of reporting several non-bugs due to insufficient domain and SUT understanding, and I felt quite worried that I’m damaging my reputation with the developers. I reassessed what I was doing wrong and improved. I also had an informal conversation with the developers and explained what led me to make those mistakes.
由于对域和SUT的了解不足，我报告了一些非错误，这让我非常担心，因为这会损害我在开发人员中的声誉。 我重新评估了我做错了的地方并加以改进。 我还与开发人员进行了非正式对话，并解释了导致我犯下这些错误的原因。
I openly admit that I am a fallible human being and I will try harder next time!
我公开承认我是一个容易犯错的 人，下次我会更加努力！
2. Bug report quality: you might report only valid and critical bugs, great! But if your reports are short, vague, and don’t have the usual useful information, then you are making developers work much harder than they should.
2. 错误报告质量 ：您可能只报告有效和严重的错误，太好了！ 但是，如果您的报告简短，含糊且没有常用的有用信息，那么您将使开发人员的工作比他们应做的要艰辛得多。
Your bug reports should contain, among others:
您的错误报告应包含以下内容：
- A clear description 清晰的说明
- Link to relevant requirement section 链接到相关需求部分
- Steps to reproduce 重现步骤
- Expected vs. actual result 预期与实际结果
- Reproducibility (100% or randomly occasional?) 重现性(100％还是偶然？)
- Relevant log snippets or screenshots 相关日志片段或屏幕截图
Each missing point from the above means more effort for the developers. And who likes to spend more time on a task than necessary? Make it easier for them to accept and process your bug.
上面的每个遗漏点对于开发人员来说意味着更多的努力。 谁愿意在一项任务上花费更多的时间呢？ 使他们更容易接受和处理您的错误。
“If you’re a diplomat, then your bug reports are your diplomatic face*!”
“如果您是外交官，那么您的错误报告就是您的外交面Kong*！”
*Especially if you never personally met the developers who read your reports because they are located in a different office.
*特别是如果您从未亲自遇到过阅读报告的开发人员，因为他们位于不同的办公室。
4.在门口检查你的自我 (4. Check your ego at the door)
Ego ruins professional relationships real fast. Don’t be arrogant and don’t be condescending. Especially after you made promises such as “I am here to provide a service to you” and “let’s work on quality together”.
自我毁灭了真正快速的专业关系。 不要自大，不要自高。 特别是在您做出诸如“我在这里为您提供服务”和“让我们共同致力于质量”之类的承诺之后。
There is one area where you should monitor your Ego very closely — rejected bug reports.
在一个区域中，您应该非常密切地监控自我-拒绝的错误报告。
“How could they?! I’ve spent an hour figuring out how to reproduce it, writing up a report with all the details and screenshots!”
“他们怎么可能？！ 我花了一个小时弄清楚如何重现它，并编写了包含所有详细信息和屏幕截图的报告！”
It’s human to feel this way sometimes. However, it’s not a good idea to do any of the following:
有时会有这种感觉是人类的。 但是，执行以下任何操作都不是一个好主意：
- Reopen the bug without any comment 重新打开错误，不加任何评论
- Reopen the bug with a non-constructive comment (“THIS IS A BUG!”) 使用非建设性评论重新打开该错误(“这是一个错误！”)
- Escalate to management 上报管理
Doing any of the above is being the opposite of tactful. It’s a lose-lose! If you’re wrong, you won’t look good for insisting on the wrong thing. If you’re right — you just made someone else look bad! And they won’t like you for it.
进行上述任何操作都与机智相反 。 这是输球！ 如果您做错了，那么坚持坚持做错事情就不会好看。 如果您是对的，那么您只是使别人看起来不好！ 他们不会喜欢你的。
You may decide not to raise this issue at all if it’s relatively trivial. You did your job and reported it, it wasn’t accepted, you remember that you should pick your battles and move on.
如果这个问题比较琐碎，您可以决定根本不提出这个问题。 您完成了工作并报告了该工作，但未被接受，您还记得应该继续战斗并继续前进。
But you may be sure that you’ve uncovered a serious flaw and you need to fight for it. The best thing to do is to try and talk to the person who rejected your bug in private (chat or face-to-face, which is always better) and try to convince them to reconsider, because reasons A, B, and C! If they accept your reasoning — they will reopen the issue themselves and won’t lose face. And if they refuse — then respectfully state that you will ask other stakeholders for a second opinion. Now you’re being tactful!
但是您可以确定已经发现了一个严重的缺陷，需要为此奋斗。 最好的办法是尝试与私下拒绝您的错误的人交谈(聊天或面对面，总是比较好)，并试图说服他们重新考虑，因为原因A，B和C！ 如果他们接受您的推理-他们将自己重新提出问题，并且不会丢脸。 如果他们拒绝，则请尊重地声明您将要求其他利益相关者征求第二意见。 现在，您变得机智了 ！
结论 (Conclusion)
- Being diplomatic isn’t easy, but it’s oh so worth it! 外交并不容易，但这很值得！
- Continuously remind developers that you want to help them, not criticize them 不断提醒开发人员您想帮助他们，而不是批评他们
- Write high-quality bug reports if you wish to be taken seriously 如果您希望认真对待，请撰写高质量的错误报告
- Be tactful. Don’t make people look bad. Help them look good! 机智 不要让别人看起来不好。 帮助他们看起来不错！
This article is part of the “Tales of an opinionated SDET” series.
本文是“ SDET故事集”系列的一部分。
Andrejs Doronins is a professional Test Automation Engineer and a Pluralsight course author. If you wish to learn test automation — check out my courses — a free trial will give you access to them and the entire library of 7000+ other courses.
Andrejs Doronins是一名专业的测试自动化工程师，也是Pluralsight课程的作者 。 如果您想学习自动化测试-请查看我的课程- 免费试用将使您可以访问它们以及7000多种其他课程的整个库。
翻译自: https://medium.com/javarevisited/the-most-important-soft-skill-of-a-tester-77a9fc7347f2
测试软技能
297
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
