对“还需数小时测试但马上就要上线”的思考

2024-02-22   出处: waynemroseberry  作/译者:wayneroseberry/lukeaxu

上面图片的Bing Image Creator提示是:“在类似的情况下,当你需要或感觉需要数小时进行测试和报告,而其他人认为该事物将在2小时内投入生产时,你如何管理他人的期望?” 这个问题与引发本文的问题相同。图中的人物正处于崩溃的边缘,被越来越暴力的幻觉所困扰,将办公设备扭曲成危险的工具。希望本文能够平复他们的情绪……

有人最近问了我一个关于测试时间的问题:当你需要或感觉需要数小时进行测试和报告,而其他人认为该事物将在2小时内投入生产时,你如何管理他人的期望?

这是对我写的一篇关于测试会话的文章的回应,我花了总共5小时进行测试并生成报告。当时我是在自由职业、义务性地进行测试,因此没有时间限制或截止日期。没有人告诉我可以或不可以做什么,或者我的活动是否会对产品发布产生影响。我的情况与典型的产品团队测试工程师情况非常不同。

真实的项目进程中限制了我们完成某事的时间。真实的项目是多人共同努力的成果,涉及不同层次的义务、责任、执行和决策权。

换句话说,有时候决定并非由你来做。但我想知道这个问题是否是错误的问题。

这是关于说服别人为你争取更多时间吗?

也许事态不可避免。某物已经交付,计划是在2小时内投入生产,有人看到即将发布的内容并认为至少还需要5小时的调查。这可能是在当时改变人们看法的问题。

如果是这种情况,那么你可能只能告诉那些做出决定的人你的担忧,解释你认为不知道测试结果的风险。以让他们能够理解的方式将风险表达出来,诚实地呈现他们如何看待对业务或客户可能构成威胁的可能性。

最好以书面形式进行这种讨论,以便决定有记录可查。在那之后,可能的结果有:

  1. 你得到你要求的时间,测试开始。
  2. 对产品时间表不做任何更改,但你被允许继续进行。
  3. 你被告知不要进行调。

还有一种可能性可能对你可用也可能不可用。继续测试。产品可能在2小时内投入生产,而你可能认为需要5小时来完成测试。无论如何,进行测试。即使发布可能不等你,但你提供的信息,即使在最坏的情况下也是3小时迟到,仍然可能对团队有很大帮助。

你不需要把它保密。在一个健康的工作环境中,你应该能够说:“我将继续测试,我认为需要我5小时的时间。请继续发布。我会告诉你我检查出了什么,如果我看到了什么真的很糟糕,我会尽快通知你。”

让我们谈谈权力和责任

这个问题听起来像是有人感觉自己对最终产品的质量负有责任,但却没有影响产品质量所需的权力。

测试是一项评估产品的行为,特别是针对威胁产品价值的检查,与决定如何创建、更改、构建或发布产品的工作是不同的。一些工作场所可能会让一些测试人员承担其中一些责任,但在那些时刻,测试人员实际上是在扮演不同的角色。责任与权力相伴而行。

测试人员的责任是进行测试并传达关于测试的信息。这包括关于他们认为应该进行的测试和相关风险的报告。当测试人员传达完他们的信息后,他们就完成了测试人员角色的责任。

同样,责任并不是说服任何人相信什么。责任是为决策者提供他们做出决策所需的信息。测试人员的存在是为了确保决策者了解情况。这并不是一种被动的顺从,因为真正的权力在于测试人员可以选择提供的信息。测试人员拥有这种评估,他们拥有他们进行的测试,他们拥有之前进行的检查,他们拥有分析。测试人员所拥有的一切都代表了他们对业务、产品和客户认为正确的事情所做出的决策。

这否涉及其他问题?

在距离投入生产只有2小时之前,为什么才有人进行评估,并认为在发布之前需要进行更多的测试?这种信念对其他相关人员来说是否令人惊讶?在此之前,这个变更进行了多长时间的工作?谁被告知了这个变更,所有负责进行变更、评估变更和决定是否发布变更的各方是否包括在内?

这个问题似乎涉及团队如何协作、沟通、分配责任、做出决策和管理产品风险。

以下是一些以不同方式考虑这个问题的方式:

  • 在还有更多时间影响进度和计划时,是否可以更早地进行相同的评估?
  • 测试和检查是否可以更早地进行?
  • 是否有可能对产品进行一些变更,以减少检查成本、相关风险,或将问题分解为更小、可管理的问题?
  • 是否可以对变更、迭代和计划的安排进行一些变更,使行为分布在多个提交中,从而允许检查跨越多个发布,随着变更的逐渐到来?
  • 我们是否有机制来影响暴露控制、功能启用,以便在测试开始时保护生产环境的稳定?

测试人员可以改变什么?

这取决于测试人员所控制的内容。他们在日常工作中可能拥有或不拥有自主权。

假设他们拥有更多的决策自由。假设他们很了解团队的其他成员,包括产品经理、设计师、开发人员和发布经理。如果是这样的话,请考虑以下几点:

  • 在代码出现之前就参与其中,并开始进行评估
  • 帮助团队构建一个适应变化的测试方法论,减少在发布点上的时间辩论
  • 帮助在工具、产品和流程中建立支持更好地管理测试风险的能力

测试角色的一些方面超出了编写和运行测试的范畴。其中一些方面涉及了解和改变测试的方法,并与产品的发布和构建相契合。你可以独立完成一些工作(这时你实际上承担了与测试人员不同的角色,这可能是正确的做法),或者与其他人合作完成。

其他人会做出哪些改变?

在这里,所谓的“其他人”指的是那些此刻不从事测试工作的人。可能的改变列表与上面的考虑列表相似。许多有助于简化测试的事情也会带来更好的产品设计、更好的业务扩展能力、收集反馈和应对变化的能力。考虑以下几点:

  • 与所有潜在团队成员启动变更的沟通过程,而不仅仅是开发人员或产品经理
  • 在组件和服务之间使用松散耦合的合同来分离紧密耦合的依赖关系
  • 在产品架构中构建监控和遥测功能,并具备丰富的查询和分析能力
  • 在产品中构建曝光控制和功能门控能力
  • 实施基于每个变更、功能、用户故事或项目的团队范围测试计划,并考虑风险因素
  • 在发布策略中考虑风险信息如何影响发布计划,确定“立即停止”指标以及决策哪些变更的曝光级别

还有其他一些行动可以想象,但每个行动都需要拥有决策权的人来做出决策,并采取行动来实施。这可能包括设计师、产品经理、开发人员、发布经理、业务所有者或其他许多角色。测试人员可能会为变更的这一部分做出贡献,并可能拥有其中的一些行动,但如果是测试人员进行产品代码变更、业务或流程决策的话,他们在那个时候并不真正扮演测试人员的角色。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
179° /1792 人阅读/0 条评论 发表评论

登录 后发表评论