#1 楼
否。需求应从单一点出发。您的开发人员可能会误解某些内容，因此您将测试的不是您的利益相关者的要求，而是您的开发人员实现的功能（电话损坏的影响）。询问产品负责人，您将可以发现企业期望与团队实际实现之间的差距。
评论
我同意应该有一个单一的事实来源，即产品负责人，但除了询问产品负责人之外，还可以向开发人员询问要求。如果它们不匹配，则可能有助于尽早发现误解（如果尚未实现要求）或将测试集中在此特定领域（否则）。
– dzieciou
19年3月12日在11:56
如果产品所有者由于充分的理由而与应用程序的当前状态不一致，并且团队做出了相互矛盾的决定，该怎么办？可能您应该同时咨询开发人员和产品所有者。
– Niels van Reijmersdal
19年3月12日在13:08
是的，但是咨询并不意味着要求要求。向开发人员和PO询问都意味着双重工作。团队中可能还有其他角色，因此按照这种逻辑，添加新角色将增加一个步骤来协商需求。如果产品所有者与当前状态不符，那么公司流程就会出现严重问题。我并不是说质量检查人员可能会询问开发人员有关最终产品愿景的来源。但这是例外情况。显然，OP在他们的问题中没有提到“理想情况”。
– Alexey R.
19年3月12日在13:23
可能你是对的。他们可能和Scrum Master一起失败了。但。开发人员实现功能。它们可能会引入缺陷，并且可能有多种原因，例如对要求的理解不正确。我们在这里不讨论假设的PO在假设的团队中的运作情况。我们正在讨论将需求传达给团队的有效和可靠的方法
– Alexey R.
19年3月13日在6:31
这是绝对正确的。质量保证工作的一部分是确保开发人员正确理解需求。如果他们没有这样做，那么质量检查人员会收到相同的错误信息，因此质量检查的大部分目的都将丢失。 （另一个目的是找到QoI东西，例如仍然可能发生的彻底错误，崩溃或可怕的UI窗口。）
–轨道轻度竞赛
19年3月13日在16:15
#2 楼
我不会说向开发人员提出要求是“好的做法”，因为他们会对它们有自己的解释。如果可能，请始终尝试从业务分析师或产品所有者那里获取您的要求（如果他们是请求更改或提供要求的人）。
您可以询问开发人员是不得已而为之的……但是要带一点盐，然后挑战他们（总是问“为什么”），看看这些变化对您来说是否有意义。
评论
我不同意，如果敏捷开发团队可以帮助他们更轻松，更好或更快速地实现其目标，则应该可以自由更改需求。现在，代码是要求的唯一真实实现。所以我会尝试从整个团队那里获取信息，例如开发人员，采购订单和团队中的任何其他人员。
– Niels van Reijmersdal
19-3-12在11:20
开发人员应该是变革的推动者，而不是定义者。这也将消除对BA或PO的需求。如果要求背景是蓝色，但他们认为背景最好是绿色...那么首先要有要求（或BA或PO）有什么意义？
–trashpanda
19 Mar 12 '19 at 11:27
PO是为了最大化ROI并控制什么（而不是详细的要求）。我宁愿有一个开发团队来决定绿色要比盲目地遵循要求更好。在Google上了解有关41种蓝色阴影的信息。因此，尽管拥有专业知识可能会使整个团队变得更强大，但我认为敏捷团队中不需要BA或其他学科，但不会孤岛。阅读：theguardian.com/technology/2014/feb/05/…
– Niels van Reijmersdal
19 Mar 12 '19 at 13:04
关注于要解决的挑战而不是如何解决。团队应该有创造力的空间。 “如果我问人们他们想要什么，他们会说更快的马。” - 亨利·福特
– Niels van Reijmersdal
19年3月12日在16:20
@NielsvanReijmersdal“如果敏捷开发团队可以帮助他们更轻松，更好或更快速地实现目标，则应该可以自由更改需求。”没有东西会离事实很远。您的团队应该随时与产品经理交谈并提出更改建议，并且如果产品经理认为有必要进行更改，则敏捷应该使他们能够将更改纳入他们的工作流程中。但是开发人员绝对不能凭自己的认可来更改要求。太疯狂了！
–轨道轻赛
19年3月13日在16:16
#3 楼
问您的团队，也许在每日站立期间？说您因缺少需求详细信息而受阻。现在，团队可以决定谁是最协助您的人。希望产品负责人能够在日常工作中为您提供帮助，但是至少团队教练（例如像Scrum Master这样的人）可以尝试为您解决问题。我希望整个团队了解并统一他们当前关注的重点，包括验收标准。听起来您不属于团队成员，或者合作不够紧密。
敏捷测试宣言还建议：最后。
他们建议测试是一项活动，而不是阶段或移交。
您可以使用与开发人员并行的相同细节。
评论
谢谢，这正是我的想法。同样，我们的产品负责人从不参与日常站立活动：(
–Shubham Takode
19年3月12日在11:21
@ShubhamTakode这是添加到问题中的重要细节。但这可能意味着敏捷方法论没有答案，因为您并不是真正在做敏捷。
– StackOverthrow
19年3月12日在15:27
@TKK Agile并不意味着PO必须处于站立状态，但是许多团队表明它具有价值。我们可以说需求也不是很敏捷。并不是真的，敏捷评论并没有真正的帮助，最好建议检查和调整:)
– Niels van Reijmersdal
19年3月12日在15:48
@TKK我不是那种虔诚地按书行事的人。我同意“不是真的敏捷”的评论将不会具有建设性，除非OP明确要求在敏捷范例中提供答案。没有一个。
– StackOverthrow
19年3月12日在17:01
#4 楼
无论您做什么，都不要因开发需求的过程过于繁重或开发人员的投入被低估而导致开发人员无法进行小的改进。如果开发人员与用户保持良好的联系，则尤其如此。产品负责人有时过于沉迷于高级业务战略问题，以至于无法意识到用户真正需要的只是战术上的改进。如果开发人员与用户交流很多，他们的耳朵可能会贴近地面。#5 楼
我认为直接向开发人员而不是产品所有者提出要求不是一个好主意。在开发过程中，产品所有者应始终是中心或共同点。让我们考虑一下，如果我们直接向开发人员提出要求，那么他们（开发人员）将只分享他们对产品所有者的理解的那些要点...该要求将成为您的基础，并且（产品所有者>>开发人员）之间会有一定的沟通差距，那么当此要求传递到链的另一个链接（开发人员>> QA）时，此差距可能会增加，并且QA将根据开发人员共享的要求测试产品。在这种情况下，很难决定对与错。因此要求必须是单一来源。
#6 楼
对敏捷过程的某些解释仅具有三个角色：产品所有者，开发人员和Scrum管理员。这样一来，质量检查人员就可以成为具有特定技能的开发人员。因此，他们可以随时询问其开发人员，也可以随时（在理想情况下，在优化过程中）向采购订单要求澄清。冲刺计划，因为澄清应纳入验收标准。即使质量保证与开发人员分开，就像您一样，他们还是IT专业人员，对需求和接受标准都有独特的看法，并且他们应始终在冲刺开始之前检查接受标准的可测试性-无法测试的标准可能是一个糟糕的标准。团队工作量，以及作为团队工作一部分的一般方式。但是，这样做会改变质量检查的性质。他们将不再为利益相关者检查开发人员的工作，而是与开发人员一起满足PO的接受标准。
#7 楼
如果您要进行敏捷操作，那么不可以，开发团队绝对不应该是您的需求来源-这来自产品负责人，或者（如果可能的话）来自业务分析师。如前所述其他地方的开发人员很可能会对需求有自己的解释，这可能与测试人员的理解不符。这就是为什么您应该在开发过程的早期就对3种Amigos进行某种实施，以阐明每个人对需求的理解。
#8 楼
质量检查人员不应依赖开发人员。但是他们需要与Dev和BA合作的方式。特别是在完成需求分析并提出测试方案后，那些需要通过BA，DEV进行审查。
#9 楼
产品负责人（PO）或产品负责人授权的人。有时，将由PO授权的业务分析师（BA）或需求工程师（RE）来澄清和定义需求。即使在这种情况下，PO仍拥有最终授权。请注意，没有什么可以阻止您作为质量保证与DEV讨论需求的。通过这样的讨论，我发现以下两个好处。
作为质量检查人员，您可以提供一些关于您认为DEV可能错过的需求的深刻见解。 ，这可以使您重新考虑对要求的理解。
#10 楼
向开发人员询问要求不是一个好方法。尤其是在敏捷方法论领域，几乎没有文档或根本没有文档。两个建议：检查是否有可能从您的经验中获得类似用例的东西
，动手应用知识和见解，创建测试用例并讨论它可以确保您添加的功能检查足以覆盖该场景。
评论
您的敏捷环境如何？听起来测试人员不属于团队。...？团队独立工作。
这就是票务系统的用途：对票务的要求或行为描述应写在票证中。