上面图片的Bing Image Creator提示是：“在类似的情况下，当你需要或感觉需要数小时进行测试和报告，而其他人认为该事物将在2小时内投入生产时，你如何管理他人的期望？” 这个问题与引发本文的问题相同。图中的人物正处于崩溃的边缘，被越来越暴力的幻觉所困扰，将办公设备扭曲成危险的工具。希望本文能够平复他们的情绪……
有人最近问了我一个关于测试时间的问题：当你需要或感觉需要数小时进行测试和报告，而其他人认为该事物将在2小时内投入生产时，你如何管理他人的期望？
这是对我写的一篇关于测试会话的文章的回应，我花了总共5小时进行测试并生成报告。当时我是在自由职业、义务性地进行测试，因此没有时间限制或截止日期。没有人告诉我可以或不可以做什么，或者我的活动是否会对产品发布产生影响。我的情况与典型的产品团队测试工程师情况非常不同。
真实的项目进程中限制了我们完成某事的时间。真实的项目是多人共同努力的成果，涉及不同层次的义务、责任、执行和决策权。
换句话说，有时候决定并非由你来做。但我想知道这个问题是否是错误的问题。
这是关于说服别人为你争取更多时间吗？
也许事态不可避免。某物已经交付，计划是在2小时内投入生产，有人看到即将发布的内容并认为至少还需要5小时的调查。这可能是在当时改变人们看法的问题。
如果是这种情况，那么你可能只能告诉那些做出决定的人你的担忧，解释你认为不知道测试结果的风险。以让他们能够理解的方式将风险表达出来，诚实地呈现他们如何看待对业务或客户可能构成威胁的可能性。
最好以书面形式进行这种讨论，以便决定有记录可查。在那之后，可能的结果有：
- 你得到你要求的时间，测试开始。
- 对产品时间表不做任何更改，但你被允许继续进行。
- 你被告知不要进行调。
还有一种可能性可能对你可用也可能不可用。继续测试。产品可能在2小时内投入生产，而你可能认为需要5小时来完成测试。无论如何，进行测试。即使发布可能不等你，但你提供的信息，即使在最坏的情况下也是3小时迟到，仍然可能对团队有很大帮助。
你不需要把它保密。在一个健康的工作环境中，你应该能够说：“我将继续测试，我认为需要我5小时的时间。请继续发布。我会告诉你我检查出了什么，如果我看到了什么真的很糟糕，我会尽快通知你。”
让我们谈谈权力和责任
这个问题听起来像是有人感觉自己对最终产品的质量负有责任，但却没有影响产品质量所需的权力。
测试是一项评估产品的行为，特别是针对威胁产品价值的检查，与决定如何创建、更改、构建或发布产品的工作是不同的。一些工作场所可能会让一些测试人员承担其中一些责任，但在那些时刻，测试人员实际上是在扮演不同的角色。责任与权力相伴而行。
测试人员的责任是进行测试并传达关于测试的信息。这包括关于他们认为应该进行的测试和相关风险的报告。当测试人员传达完他们的信息后，他们就完成了测试人员角色的责任。
同样，责任并不是说服任何人相信什么。责任是为决策者提供他们做出决策所需的信息。测试人员的存在是为了确保决策者了解情况。这并不是一种被动的顺从，因为真正的权力在于测试人员可以选择提供的信息。测试人员拥有这种评估，他们拥有他们进行的测试，他们拥有之前进行的检查，他们拥有分析。测试人员所拥有的一切都代表了他们对业务、产品和客户认为正确的事情所做出的决策。
这否涉及其他问题？
在距离投入生产只有2小时之前，为什么才有人进行评估，并认为在发布之前需要进行更多的测试？这种信念对其他相关人员来说是否令人惊讶？在此之前，这个变更进行了多长时间的工作？谁被告知了这个变更，所有负责进行变更、评估变更和决定是否发布变更的各方是否包括在内？
这个问题似乎涉及团队如何协作、沟通、分配责任、做出决策和管理产品风险。
以下是一些以不同方式考虑这个问题的方式：
- 在还有更多时间影响进度和计划时，是否可以更早地进行相同的评估？
- 测试和检查是否可以更早地进行？
- 是否有可能对产品进行一些变更，以减少检查成本、相关风险，或将问题分解为更小、可管理的问题？
- 是否可以对变更、迭代和计划的安排进行一些变更，使行为分布在多个提交中，从而允许检查跨越多个发布，随着变更的逐渐到来？
- 我们是否有机制来影响暴露控制、功能启用，以便在测试开始时保护生产环境的稳定？
测试人员可以改变什么？
这取决于测试人员所控制的内容。他们在日常工作中可能拥有或不拥有自主权。
假设他们拥有更多的决策自由。假设他们很了解团队的其他成员，包括产品经理、设计师、开发人员和发布经理。如果是这样的话，请考虑以下几点：
- 在代码出现之前就参与其中，并开始进行评估
- 帮助团队构建一个适应变化的测试方法论，减少在发布点上的时间辩论
- 帮助在工具、产品和流程中建立支持更好地管理测试风险的能力
测试角色的一些方面超出了编写和运行测试的范畴。其中一些方面涉及了解和改变测试的方法，并与产品的发布和构建相契合。你可以独立完成一些工作（这时你实际上承担了与测试人员不同的角色，这可能是正确的做法），或者与其他人合作完成。
其他人会做出哪些改变？
在这里，所谓的“其他人”指的是那些此刻不从事测试工作的人。可能的改变列表与上面的考虑列表相似。许多有助于简化测试的事情也会带来更好的产品设计、更好的业务扩展能力、收集反馈和应对变化的能力。考虑以下几点：
- 与所有潜在团队成员启动变更的沟通过程，而不仅仅是开发人员或产品经理
- 在组件和服务之间使用松散耦合的合同来分离紧密耦合的依赖关系
- 在产品架构中构建监控和遥测功能，并具备丰富的查询和分析能力
- 在产品中构建曝光控制和功能门控能力
- 实施基于每个变更、功能、用户故事或项目的团队范围测试计划，并考虑风险因素
- 在发布策略中考虑风险信息如何影响发布计划，确定“立即停止”指标以及决策哪些变更的曝光级别
还有其他一些行动可以想象，但每个行动都需要拥有决策权的人来做出决策，并采取行动来实施。这可能包括设计师、产品经理、开发人员、发布经理、业务所有者或其他许多角色。测试人员可能会为变更的这一部分做出贡献，并可能拥有其中的一些行动，但如果是测试人员进行产品代码变更、业务或流程决策的话，他们在那个时候并不真正扮演测试人员的角色。
