我与开发人员和业务分析师进行了交谈，他们同意由于预算原因，没有更多的工作要花费在改善这个问题上。
作为当前公司政策，对于我们提出的每一个问题，我们都需要提供解决方案。
我认为我不应该留这个问题，有什么解决办法？
。
#1 楼
首先，“没有技术解决方案”并不完全正确。根据我的理解，技术解决方案实际上非常简单。改进Excel宏以提供更好的验证
，或者使应用程序的导入功能更强大，以防止错误（中止导入）并将问题值清楚地传达给用户。
我建议您首先进行基本的风险分析：
会发生多少次？
发生时会对业务产生什么影响？
/>
作为测试人员，您需要提供质量和风险方面的建议；管理层决定。如果您告知此问题将使公司损失资金（*），那么您敢打赌他们会立即修复该问题。 ：）
如果没有，那么对于用户来说，这只是个不便。如Yu Zhang所说，在这种情况下，他们应该通过手册或指南来意识到这一问题。
（*）亏损既可以是直接的，也可以是间接的，例如：效率降低，声誉受损导致客户流失，错误的输入数据导致事件，进而导致服务台和IT上的可用资源减少，...
#2 楼
您需要认真努力才能继续解决这个问题；我本来应该放弃的：-)总之，您仅有的验证来自Excel，而开发人员不会对此做任何事情；您想知道如何才能提高软件质量。
软件项目在完成预算或时间之前用完预算或时间的情况并不罕见，例如所有软件都有缺点甚至是错误（这就是我们发布补丁的原因。）
不知道该项目的所有细节，我个人将提供的解决方案是：
弄清最终用户是谁，例如谁在使用此Excel工作表。
他们可能是更注重技术的用户还是不太懂技术的用户？
推荐负责此用户手册编写过程的业务分析师（您需要针对其预期用户量身定制本手册）显示哪些输入错误，哪些输入正确。如果需要，您甚至可以向业务分析人员提供草稿。
记录这种不良的验证机制将来可能引起的潜在风险。
如果没有技术解决方案，则您所要做的至少是提供防止最终用户键入无效输入的文档。如果您没有自动验证机制来防止错误，那么您将必须教育最终用户以防止错误。
#3 楼
考虑问题的含义。不修复会带来什么风险？如果导入未经验证的数据会怎样？人们可能会死吗？人们会受伤吗？企业可能会亏本还是客户？企业可能必须向他人支付赔偿吗？如果风险很高，请与您的经理进行另一次交谈。在系统中。您应该使自己了解不修复它的风险。对于该解决方案，您可以简要描述几个可能的选项。
为电子表格创建正确的验证器。
在用户文档中描述该问题，并说明用户必须创建数据仔细地解释了格式错误的数据的某些后果。
什么也不做。只需记住它是系统的限制。
#4 楼
问题的标题您不是在说没有技术解决方案的bug，而是公司目前不打算解决的问题。
将该问题的标题更改为“如何报告我知道该公司当前不希望解决的错误”。
解决方案建议
现在写的问题可以读成好像您需要解决问题才能提交错误票一样。
我敢肯定事实并非如此（如果是您的问题，公司）。您的意思是您需要提供解决方案建议。
做什么
如果是这样，通常情况下，您知道该问题暂时无法解决，因此不应以任何方式阻碍您提交该错误。
即使没有足够的预算来解决此问题，问题仍然是一个问题。时间并提交错误，因为这样做很有用：
它记录了问题所在米尽管不太可能每个产品的用户都在使用产品之前先检查其错误记录，但仍有可能有人会并且他会意识到他在使用产品时需要考虑这个问题。
它增加了将来修复该漏洞的可能性：开发人员每次对其进行认真思考时，都会频繁看到该错误凭单，并且：
他们中的某些人可能已经对如何解决这个问题形成了一个很好的主意，以至于它很快就会变得便宜而且便宜，因此很可能就可以完成。当重新考虑所有现有的错误以进行修复时（例如，在开发新的主要版本时）。
在那个时候，很有可能有时间/预算来解决该主题的问题，但是如果没有，不是一个错误条目，很可能没人会知道，因此不会发生。
即使没有错误条目，也有可能有人记住它并带来它，但这不太可能。
请注意，即使投影出出生时的寿命很短，您不会再去修复其余的bug，经常会更长寿，因此bug报告将比您预期的有用。
有关临时缓解措施的进一步报告
但是，知道此时不会修复该错误仍然可以为您提供有用的信息：
好，没有预算/是时候适当地解决问题，但是通常可以采取一些廉价的临时缓解措施来防御它：在这种情况下，您很可能会在文档和/或警告中警告用户。
这不是替代解决方案，因为在软件内部进行适当，安全的验证可能会更好；因此，您仍然应该在请求中进行完整验证的错误，但是您还应该在文档和/或输入过程中报告请求添加警告的请求。
您很可能需要提交为此需要一个单独的错误条目（除非您的错误跟踪系统支持在同一票证中指定临时缓解措施-我不知道有什么办法）。
安全性
请注意，如果该问题可能导致安全问题，那么将其发布给用户可能不是一个好主意：如果该应用程序是内部应用程序，则很可能没问题，如果您不太担心内部威胁，则可能最好不要。
但是，我敢肯定，没有公司会发布具有已知安全漏洞的软件！ （此处需要一千个ROTFL gif文件）
评论
最后一点需要几千个ROTFL gif。
–史蒂夫·巴恩斯（Steve Barnes）
17年7月13日在6:53
#5 楼
同意FDM提供的解决方案。但是我建议您解决所有此类问题。获得列表并获得业务分析师的确认后，由于预算限制，这些问题将无法解决，只需提交这些问题，并在excel表中提及这些问题即可维护测试方案。
在这样，将在
错误跟踪系统（例如JIRA）中进行跟踪
excel工作表（测试方案）
此外，您想向所有利益相关者发送电子邮件，明确指出这些问题将不会得到解决。礼貌的方式，以便也有记录。
现在，关于错误的解决方案，您可以检查漏洞是否会对业务产生影响，如上文其他成员所述。
#6 楼
作为当前的公司政策，对于我们提出的每一个问题，我们都需要提供解决方案。我不认为我应该保留此问题，有什么解决方案？
我建议，如果您想做一些违反当前公司政策的事情，则应该与管理层合作以更新当前公司政策。也许允许没有解决方案的错误。如果公司不这样做，您可能需要接受一个解决方案才能提交错误。嗯。
#7 楼
作为当前公司政策，对于我们提出的每一个问题，我们也需要提供解决方案。我认为我不应该留这个问题，这里有什么解决方案？
您建议解决方案（或可能的解决方案，从速成，成败和-适当），然后让业务经理决定采用哪种方案，并担心预算和资源。
质量保证不能保证质量。它只能为业务决策者提供有关系统，其状态和检测到的错误的信息。要做决定取决于企业。
评论
提供解决方案还是提供可行的解决方案？您可以只放入所需的解决方案，而将解决方案的安排留给“何时解决”，即永不解决。第二个@ pjc50的评论。如果需要针对每个问题提出解决方案，但是否真正解决问题的决定是分开的，那么您就没有问题。
FWIW这是一个糟糕的政策。遇到问题的人员通常没有资格分析问题，确定是错误还是功能并找到解决方案。即使他们在那一刻，他们也可能正忙着做其他事情（他们可能不高兴他们发现了问题）。最终结果是不会提出合法问题。相反，应在发现问题后立即提出。分诊应该在一个单独的步骤中进行处理，可能由其他人处理，并且问题跟踪程序过去通常会...跟踪问题。
请阐明“提供解决方案”的含义。这是否意味着您应该猜测原因，并且如果要尝试解决该问题，最合理的解决方法是什么？还是意味着您应该提出一些您认为可行的解决方案（如@ pjc50所要求的那样）？或者是其他东西？无论意味着什么，一个负责发现缺陷的人都无法提供“解决方案”，这将使许多缺陷报告进入报告者的“太难”堆，从而使缺陷永远不会得到报告。
“解决方案：禁用功能。”