最近，我获得了内部REST API实施的质量检查所有权。
接受标准之一是，如果用户搜索不存在的项目，则结果应该是
未找到项目“ xxx”
但是，如果我搜索名为“ xxx \ n”的项目，则会显示以下消息：检索到的是
找不到项目资源
开发人员是项目的采购订单，他侮辱我，说没有人愿意在搜索字段中输入表情符号，表情符号或特殊字符。即使没有输入任何内容，错误消息在逻辑上也是正确的。
但是错误消息不是按照接受标准所预期的。这是一个有效的错误吗？
由于特殊字符，空格等极端案例的错误被视为愚蠢的，所以工作环境变得有毒。在这种情况下怎么办？
#1 楼
上下文驱动测试原则之一是：该产品是一种解决方案。如果问题没有解决，则该产品
不起作用。任意/常用的事物定义集。
当他说
Even if someone gives, the error message is logically correct.
时，它可能意味着API-可能是计算机/软件-对错误感到满意。可能是API的消费者合同推动了此类错误处理。
也许不是！
如果您知道当前协议与实施不同，那么您有一个很好的理由提出变更请求，也就是要修复的错误。如果您不知道任何形式的协议，则可以询问开发人员/采购专员如何知道这是正确的，以及将来如何事先确定这种类型的事物是否正确。此对话可以帮助您了解有关产品开发的更多信息，或者向开发人员/ PO展示不基于用户期望的假设存在风险。
有关此的更多详细信息，我建议Cem Kaner撰写这本书“ Bug Advocacy”。
#2 楼
深吸一口气退后一步
看看大局面
与人们/老板讨论标准。有个会议。同意包括特殊字符等项目的标准。本月采取短期措施，以减轻明年的长期重复性痛苦。
并允许人类使用。
我已经忘记了自己的次数：错误地键入奇怪的字符；点击了错误的链接；错误地单击“确定”；放下我的键盘；让我的猫在键盘上行走。对于某些人来说，这些看起来可能很愚蠢或有趣，但它们却非常常见。他们发生在我身上；我的太太;工作中的朋友；个人朋友-对于一个非常小的小组来说，这就是很多。两个星期前，我放下了键盘，显示屏变成了400x600，花了我两个小时的时间来解决-而且，我非常有动力，因为（应该）是一次屏幕共享远程配对会议，接受采访！然后按照您制定的协议进行操作
还：
不要在协议之外输入错误
不要对您不喜欢但同意的部分违反协议仍然要
亲自问一问，例如遇到边缘情况时要进行3次amigos会议（product-dev-qa）
通常更喜欢问产品负责人而不是开发人员
以避免毒性并被视为愚蠢的人，在这些领域采取主动行动，就会被视为相当认真而没有毒药（尽管这取决于您的举止）
请记住专注于业务和业务目标，而不仅仅是测试和错误”。当您将错误与较低的收入或更少的客户联系在一起时，这对企业意味着更多。
评论
开发人员本身就是PO，这是主要问题。
– PDHide
19-10-31在0:02
+1代表更少的客户=代表更多业务
– PDHide
19-10-31在0:18
其次是3个好友！由于dev是项目所有者，因此可能会更加困难。您可以包括UI / UX人员，业务分析师，其他中立开发人员或质量保证人员吗？如果事情有毒，没有中立政党，我也不会尝试。多年以来，我发现我的问题和测试结果大致遍历了，效果很好。开发人员发现了问题；采购订单具有更好的视角，用3而不是1可以得出更好的想法和解决方案。结果规格更改，故事被更新或错误被记录，或者其中一些情况发生了，但这是一个集体决定。
– CKlein
19-10-31在11:40
#3 楼
对于API，我认为这是一个错误。应用程序可能会解析文本，因此对于任何无效的项目名称而言，该文本都应相同。修复，与其他问题相比。我认为您的主要问题不是技术性问题，而是您被嘲笑的事实。这是有毒的，无论您是否发现了重要的错误，都不应发生。我将注意力集中在此上，而不是辩论什么是bug或不是bug。
评论
“与其他问题相比，它很可能还不够重要。”我在想同样的事情。从技术上讲，这可能是一个错误，因为行为与规范不符。但这真的有害吗？还是因为文字不完全匹配，而是软件的行为和功能正常？如果是这样，那么拥有资源来解决此问题与将要交付此sprint / release的客户要求的其他事情有什么价值？
– CKlein
19年10月31日，11：30
“化妆”错误会使客户讨厌产品，而修复它们可以极大地改善他们对产品质量的看法。尤其是当“化妆”错误使产品看起来不成熟时。
– gnasher729
19年11月1日在13:12
#4 楼
接受标准不是一成不变的。随着我们获得新的见识，它们会发生变化。现在在您的示例案例中，问题是：“足够好吗？”我个人认为是这样。我想知道是否有毒的环境可能是因为您的行为过于严格。如果您的行为不令人满意，大多数时候人们会停止认真对待您。知道何时该站稳脚跟，何时该接受该应用程序的完善，但现在已经足够好了。 />人物，空格等被认为是愚蠢的。
与人交谈并弄清人们为什么如此行事。明确表示您不喜欢它，并同意一种更可接受的沟通方式。请记住Covey的习惯5。
习惯5：首先要理解，然后要被理解。
打算答复。”
https://www.franklincovey.com/the-7-habits/habit-5.html
我认为您可能想让人们首先理解故事的一面，而不了解并认可他们的故事。
#5 楼
情况1：如果错误消息不符合接受标准，并且如果输入的特殊字符有单独的错误消息，则将是有效的错误。验收标准提供的特定错误消息，并且您认为显示的错误消息不是特定的错误消息，因此请与开发团队讨论作为改进，它绝对不是bug，而只是对该功能的改进评论
即使它是一个“有效的错误”，也值得注意的是，并非每个“有效的错误”都值得修复！
–火星
19年11月1日在1:53
@火星以这种态度，垃圾堆积。在这种情况下，这听起来像是微不足道的修复，因此讨论此问题而不是仅仅解决它，就浪费了更多时间。
– gnasher729
19年11月1日在18:58
@ gnasher729在这种情况下，我认为现在比讨论错误本身更多的时间讨论此类错误的策略。而且许多错误都是微不足道的修复，然后需要重新测试，测试报告，由他人签署这些报告并重新交付应用程序...。
–火星
19年11月4日在23:58
@ gnasher729另外，此修补程序听起来也不是很琐碎的……您需要确定不允许使用哪些字符，在何处进行过滤等。您是否一开始就阻止用户发送它？您在后端处理吗？如果有人碰巧复制并粘贴了一个奇怪的项目名称，那么如何使用不同的编码呢？快速黑客修复可能只是为了过滤后端的换行符，大约需要30秒钟，但是在公司环境中，这可能会占用数个人工时间，并涉及多个人...
–火星
19年11月5日，0：17
#6 楼
根据错误的定义：软件错误是计算机程序或系统中的错误，缺陷，故障或错误，导致其产生不正确或意外的结果，或者会以意想不到的方式表现。测试失败，这是一个错误。
评论
马丁嗨，感谢您的答复，这个问题更多的是在道德和职业层面上，而不是理论上的问题。这些错误重要还是应该调查
– PDHide
19年11月2日在18:37
@PDHide，虽然有一个SRS，软件需求规范，它说明了输出应如何类似-当有一个测试用例时，它断言了输出应如何类似，从技术上讲，这是一个错误，需要进行修复，尽管它具有装饰性。该错误的优先级可能较低，因此，它只是表面上的，尽管已经预测了它的外观-因此没有讨论的余地（如果没有SRS和测试用例，这可能是个开放的讨论） 。
–user39770
19年11月3日在5:04
我的意思是，如果规范是错误的或错误的，仍然可以提供“为什么不这样做”的理由（例如，如果错误消息会将未经验证的用户披露相关信息），则尽管规范没有错，规范是“法律”，将与测试用例一起执行。
–user39770
19-11-3在5:21
评论
将其归档在Bug跟踪器中，然后您的工作就完成了，他们可以选择是否修复它？当然，这是一个有效的错误，因为不满足接受条件。他们可能会认为不值得修复。如果用户通过从某处复制项目来搜索项目，并且有尾随的换行符/空格/ unicode不可打印字符，会发生什么情况？
必填XKCD-小鲍比桌子
我会很担心，因为这表明API无法正确转义，并且其中可能存在潜在的安全漏洞。
如果不符合规范，则称为“有效”错误。但是，并非所有有效的错误都值得修复。关于环境变得有毒的部分听起来更像是在The Workplace上要问的问题。您将要添加更多详细信息。就个人而言，在这种情况下听起来您可能过于敏感。对于开发人员来说，告诉测试人员错误是“边缘案例”而不必担心修复的情况并不少见，但这还取决于客户是谁！