blocks|key|3912455|text|不是的。需求应该来源于一个单一的点。您的开发人员可能会误解一些东西，因此您将测试的不是您的涉众要求，而是您的开发人员实现了什么(手机坏了的影响)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3912456|询问您的产品所有者将让您了解业务期望与团队实际实现之间的差距。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

No. Requirements should be originated from a single point. Your developers might misunderstand something so that you'll be testing not what your stakeholders require but what your developers implemented (effect of a broken phone). 

Asking your product owner will let you catch the gaps between what the business expects vs what your team actually implemented.

blocks|key|3945512|text|我不会说要求开发人员提供需求是“良好实践”，因为他们会对需求有自己的解释。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945513|如果可能，请始终尝试从业务分析师或产品所有者那里获得您的需求(如果他们请求更改或提供需求)。|3945514|你可以问开发商作为最后的手段..。但是，接受他们说的话，并挑战他们(总是问‘为什么’)，如果这些变化对你没有意义。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

I wouldn't say it's "good practice" to ask the developers for requirements, as they'll have their own interpretation of them. 

If possible, always try and get your requirements from the business analyst or product owner (if they're the requesting the change or providing the requirements).

You can ask the developers as a last resort... but take what they say with a pinch of salt and challenge them (always ask 'why') if the changes don't make sense to you.

blocks|key|3945587|text|问问你的团队，也许是在每日站站的时候？说你因缺乏要求细节而受阻。团队现在可以决定谁是最能帮助你的人。希望产品负责人在每日站站，并能帮助您，但至少团队教练(例如Scrum喜欢的人)可以尝试支持您解决问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945588|我希望整个团队了解并调整他们目前的重点，包括验收标准。听起来你们不是团队的一员，也不是足够紧密的合作伙伴。|3945589|此外，敏捷测试宣言建议：|offset|length|3945590|我们重视整个测试，而不是最后的测试。|blockquote|3945591|他们认为测试是一种活动，而不是阶段或切换。您可以与开发人员并行地处理相同的细节。|entityMap|0|LINK|mutability|MUTABLE|url|https://www.luxoft-training.com/news/the-agile-testing-manifesto/^0|0|0|3|6|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$F|W|G|X|1|Y]]|A|$]]|$1|H|3|I|5|J|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

Ask your team, maybe during the Daily Standup? Saying your impeded by lack of requirements details. The team can now decide whom is the handiest to assist you. Hopefully the Product Owner is at the Daily Standup and can help you, but at least the Team coach (e.g. Scrum Master like person) can try to support you to resolve the issue. 

I would expect the whole team to be aware and aligned of what they are currently focused on, including the acceptance criteria. Sounds like you are not part of the team, or not working together closely enough.

Also the <a href="https://www.luxoft-training.com/news/the-agile-testing-manifesto/" rel="nofollow noreferrer">Agile Testing Manifesto</a> suggests:

<blockquote>
 We value testing throughout over testing at the end.
</blockquote>

They suggest testing is an activity, instead of a phase or handover.
You could be working on the same details as the developers have in parallel.

blocks|key|3912468|text|无论您做什么，不要因为创建需求的过程太重，或者因为开发人员的输入被低估，而阻止开发人员进行小的改进。如果开发人员与用户有很好的联系，情况尤其如此。产品所有者有时过于专注于高层次的业务策略问题，无法认识到用户真正需要的是很少的战术改进；如果开发人员与用户谈论了很多，他们的耳朵可能离得更近。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Whatever you do, don't create a situation where developers are inhibited from making small improvements because the process for establishing requirements is too heavyweight, or because input from developers is undervalued. That's especially the case if developers have a good level of contact with users. Product owners sometimes are too immersed in high level business strategy issues to recognise that what users really need are little tactical improvements; if developers talk a lot to users they may have their ears closer to the ground.

blocks|key|3912516|text|我不认为直接向开发人员而不是向产品所有者询问需求是个好主意。在开发过程中，产品所有者应该始终是中心或共同点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3912517|让我们考虑一下，如果我们直接从开发人员那里询问需求，而他们(开发人员)只共享从产品owner...that需求中理解的那些点，那么在这一点上，无论他们从产品>>需求中理解什么，都会成为您的基础&如果(产品负责人>>+Developer)之间会存在某种沟通差距，那么当这个需求传递到链的另一个链接(Developer+>>+QA)+&+QA将根据开发人员共享的需求测试产品时，这种差距可能会增大。在这种情况下，很难决定什么是对的还是什么是错的。因此，需求必须是一个单一来源。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

I don't think it's a good idea to ask requirements directly to developers rather than the product owner. A product owner should always be centre or common point during the development process. 

Lets consider, if we ask requirement directly from developers than they(Developer) will share only those points whatever they understood from product owner...that requirement will become basis for you at that point &amp; if there will be some communication gap between (Product owner >> Developer), then this gap may increase when this requirement pass to another link of the chain (Developer >> QA) &amp; QA will test product based on requirement shared by developer. In this case, it's will be very difficult to decide what is right or what is wrong. So the requirements must be a single source.

blocks|key|3945709|text|对于敏捷过程的一些解释只有三个角色:产品所有者、开发人员和scrum主。这使得QA作为开发人员拥有一套特殊的技能。因此，他们可以在任何时候询问他们的开发伙伴，也可以在任何时候要求POs作出澄清(但最好是在改进过程中)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945710|如果可能的话，应该在sprint计划之前要求澄清，因为澄清应该进入验收标准。|3945711|即使QA与开发人员分离，就像在您的案例中一样，他们也是IT专业人员，对需求和验收标准有着独特的看法，而且他们应该始终在sprint启动之前检查接受标准的可测试性--一个不能被测试的标准可能是一个糟糕的标准。|3945712|总之，当开发人员与POs交谈时，QA应该在场，他们有权从团队工作负载的特定部分对需求有一个意见，并且作为团队努力的一部分，以一般的方式提供意见。然而，这样做会改变QA的性质。他们不再为涉众检查开发人员的工作，而是与开发人员一起满足POs的验收标准。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|K|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|L|8|@]|9|@]|A|$]]]|H|$]]

Some interpretations of the agile process have only the three roles: product owner, developer, and scrum master. That leaves the QA as developers with a particular skill set. So they can ask their fellow developers at any time, and they can also ask for clarification from the POs at any time (but ideally during refinements).

If in any way possible, clarifications should be requested before the sprint planning since clarifications should go into the acceptance criteria. 

Even if QA are separate from the developers, as in your case, they are IT professionals with a distinctive view on the requirements and acceptance criteria, and they should always check acceptance criteria for testability before the sprint starts -- a criteria that cannot be tested may be a bad criteria.

Summarized, QA should be present while developers talk to POs, they are entitled to have an opinion on requirements from their own specific part of the team workload, and also in a general way as part of the team effort. Doing that would change the nature of QA, however. They would no longer check on the developers' work for the stakeholders, instead they would with the developers in fulfilling the acceptance criteria of the POs.

blocks|key|3912601|text|如果您正在执行敏捷操作，那么开发团队绝对不应该是您的需求来源--这是来自产品负责人，或者可能是无法使用的业务分析师。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3912602|正如在其他地方所指出的，开发人员很可能会对需求有自己的解释，这可能与测试人员的理解不匹配。这就是为什么您应该在开发过程的早期就对3+Amigos进行某种实现，以澄清每个人对需求的理解。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

If you're doing agile then no, the development team should definitely not be your source of requirements - this comes from the Product Owner or, potentially if they are not available, a business analyst.

As noted elsewhere devs quite possibly will have their own interpretation of requirements which may not match the testers' understanding. This is why you should have some kind of implementation of the 3 Amigos early in the development process to clarify everyone's understanding of the requirements.

blocks|key|3912529|text|QA不应依赖于开发人员的需求。但他们需要与Dev和BA合作。特别是在完成需求分析之后，当他们提出测试方案时，他们需要使用BA、DEV进行检查。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

QA should not rely on Developers for requirement. But they need to work with Dev and BA collaborate way. Specially after requirement analysis done and when they come up with test scenarios, those need to review with BA ,DEV

blocks|key|3945897|text|产品负责人(PO)或产品负责人授权的人。有时，业务分析师(BA)或需求工程师(+requirements，RE)会得到PO的授权来澄清和定义需求。即使在这种情况下，PO也将拥有最终的权力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945898|请注意，没有什么能阻止您作为QA与DEV就需求进行讨论。我从这些讨论中发现以下两个好处。|3945899|作为QA，您可以提供一些您认为DEV可能遗漏的需求的不错的见解。|ordered-list-item|3945900|作为QA，您将从DEV获得一些洞察力，这将使您重新思考对需求的理解。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|L|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|M|8|@]|9|@]|A|$]]]|I|$]]

Product Owner (PO) or the person who is authorised by the Product owner. Sometimes, a Business Analyst (BA) or a Requirement Engineer (RE) who would be authorized by the PO to clarify and define requirements. Even in that case, the PO will have the final authority. 

Please note nothing stops you as the QA to discuss with DEV on requirements. I find the below two benefits from such discussions. 

<ol>
<li>As a QA, you could provide some nice insights about the requirements which you think DEV might have missed out.</li>
<li>As a QA, you would get some insights from the DEV, which could make you rethink about your understanding on the requirements.</li>
</ol>

blocks|key|3912699|text|向开发人员询问需求并不是一个好方法。特别是在敏捷方法论的世界里，几乎没有或根本没有文档。两项建议：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3912700|检查是否有可能获得类似用例的东西。|unordered-list-item|3912701|根据您的经验，掌握应用程序知识和洞察力，创建测试用例并对其进行讨论，以确保您添加的功能检查足以涵盖该场景。|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|I|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|J|8|@]|9|@]|A|$]]]|G|$]]

It's not a good approach to ask the developers for requirements. Especially in the world of agile methodology, there will be little or no documentation at all. Two recommendations:

<ul>
<li>check if there is any possibility to get something like a use case</li>
<li>from your experience, hands-on with app knowledge and insight, create test case and discuss it to ensure the functionality checks you added are enough to cover the scenario.</li>
</ul>

Considering Agile software development process. Is it a good practice to ask developers directly for requirements rather than the product owner? The development team had already gathered some requirements from the product owner, as they are ahead with development. Ideally, from whom QA should gather the requirements?

Should QA ask developers for requirements?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

考虑敏捷软件开发过程。直接向开发人员询问需求而不是产品所有者是一种良好的实践吗？开发团队已经从产品所有者那里收集了一些需求，因为他们在开发中处于领先地位。理想情况下，QA应该从谁那里收集需求？

问QA应该向开发人员询问需求吗？
EN

回答 10

Stack Exchange QA用户

Stack Exchange QA用户

Stack Exchange QA用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问QA应该向开发人员询问需求吗？EN

回答 10

Stack Exchange QA用户

Stack Exchange QA用户

Stack Exchange QA用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问QA应该向开发人员询问需求吗？
EN