ultraiso 深度隐藏
When a testing task comes in, the first thing we usually think about is what the requirements are. If I have to perform a test, I need to know the expectations in order to evaluate the extent to which my system under test (SUT) corresponds to them. The more requirements I have, the more test cases I can think of.
当完成一项测试任务时，我们通常首先想到的是要求是什么。 如果必须执行测试，则需要了解期望，以便评估我的被测系统(SUT)对应于它们的程度。 我拥有的需求越多，我想到的测试案例就越多。
But what if I only get high-level requirements, a short description of the core feature’s functionality, or even worse — a Jira ticket with just the title and a totally empty description field. What to do in this case? I see 3 possible scenarios here:
但是，如果我仅获得高级要求，对核心功能的功能的简短描述，甚至更糟糕的话-带有标题和完全空的描述字段的Jira票证，该怎么办？ 在这种情况下该怎么办？ 我在这里看到3种可能的情况：
- send the task back to a task owner and ask to provide more details; 将任务发送回任务所有者，并要求提供更多详细信息；
- take what you have and do your best to test the product; 充分利用现有产品并尽力测试产品；
- start on a requirements journey of your own. 开始您自己的需求之旅。
The first two scenarios are quite feasible. It’s totally OK to request the feature owner to provide more information. And I for sure understand someone who would do their job based on the task assigned. However, if you want to be more than a person executing written steps, it’s your mission to gain enough knowledge to be able to create a test coverage that is able to reveal the majority of bugs hidden in the product.
前两种情况非常可行。 要求功能所有者提供更多信息完全可以。 而且我肯定知道有人会根据分配的任务来完成工作。 但是，如果您不只是一个要执行书面步骤的人，那么您的任务就是获得足够的知识，以便能够创建测试范围，从而能够揭示产品中隐藏的大多数错误。
A missing product requirement is a potential production bug. The cost of such a bug, found after the release, is about ten times bigger than if it were found at an early development stage.
缺少产品要求是潜在的生产错误。 在发行后发现的此类错误的成本大约是在早期开发阶段发现的错误的十倍。
If you want to discover more about the requirements, stay with me. Let’s examine the requirements together, learn where to look for them, and why QA should question each piece of information they receive.
如果您想了解更多有关要求的信息，请和我在一起。 让我们一起检查需求，了解在哪里寻找需求，以及质量检查为什么要质疑所收到的每条信息。
The requirements are the set of expectations that SUT should meet. The requirements can be explicit — formally documented in a certain tracking system, or implicit — based on common knowledge about the usage, appearance, properties of a particular feature. Let’s get into details.
要求是SUT应该满足的一组期望。 根据有关特定功能的用法，外观和属性的常识，这些要求可以是明确的-正式记录在某个跟踪系统中，也可以是隐式的。 让我们详细介绍一下。
Explicit requirements represent the core idea of the feature. This is what we, testers, use to check the positive flow, to perform a sanity test cycle. If we’re talking about a business feature and not a technical task, explicit requirements are usually described by product managers as a User Story.
明确的要求代表了该功能的核心思想。 这就是测试人员用来检查正向流量，执行健全性测试周期的方法。 如果我们在谈论业务功能而不是技术任务，则产品经理通常将明确的需求描述为用户案例。
Example: “As a user, I want to add a product to a shopping cart.”
示例：“ 作为用户，我想将产品添加到购物车。 ”
This simple use case gives me a clue about my main test case: add a product to cart, check that the product has appeared in cart. Then I can think about more cases like:
这个简单的用例为我提供了有关我的主要测试用例的线索：将产品添加到购物车，检查产品是否已出现在购物车中。 然后，我可以考虑更多类似的情况：
- add same product to cart; 将相同产品添加到购物车；
- add several items of the same product to cart; 将同一商品的几项添加到购物车；
- add a few different products to cart; 在购物车中添加一些不同的产品；
- etc. 等等
Let’s imagine that we delivered an online store website with an ‘add product to the shopping cart’ feature to the end-user. What if some of our users already have experience with the logic of online stores and expect our application to work in a similar manner? For instance:
假设我们向在线用户交付了一个具有“向购物车添加产品”功能的在线商店网站。 如果我们的某些用户已经具有在线商店逻辑的经验并且期望我们的应用程序以类似的方式工作怎么办？ 例如：
- when adding a product to the cart, there is a cart icon component that shows how many products there are in the cart (we can call it ‘best practice’ for online store sites); 将产品添加到购物车时，有一个购物车图标组件，显示购物车中有多少产品(我们可以将其称为“最佳实践”，用于在线商店网站)；
- what if there’s a law in our target country which forbids the sale of certain products to persons under 18 y.o. (this requirement comes from legal); 如果我们的目标国家/地区有法律禁止将某些产品销售给18岁以下的人怎么办(此要求来自法律)；
- it could be that we’re doing a redesign of some kind and our users expect the new product to support the ‘old’ feature, like cart preview (this requirement is called product history); 可能是我们在进行某种重新设计，并且用户希望新产品支持“旧”功能，例如购物车预览(此要求称为产品历史记录)；
- and so on. 等等。
The set of requirements above was not documented, but they are all important for the product to be competitive, conform to legal requirements, and consistent with previous versions. These are the implicit requirements.
上面的要求集没有记录在案，但是它们对于使产品具有竞争力，符合法律要求并与以前的版本保持一致都非常重要。 这些是隐含的要求。
You can ask, how would QA know about these requirements? Where to look for them? Here are a few tips about possible sources:
您可以问，质量检查人员如何知道这些要求？ 在哪里找他们？ 以下是有关可能来源的一些提示：
Products History — does your product have a ‘history’? If yes, learn thoroughly the previous version(s) and pay attention to when the new product misses some of the ‘old’ features. That ‘old’ feature might be missing on purpose, but it’s a QA job to verify it.
产品历史记录 -您的产品是否有“历史记录”？ 如果是，请彻底了解以前的版本，并注意新产品何时缺少某些“旧”功能。 该“旧”功能可能故意丢失了，但这是一项质量检查工作，需要对其进行验证。
Similar products inside your company — my product is an eCommerce platform, however, at Wix, there are a bunch of other verticals that also have the Checkout Flow. In this case a ‘vertical’ is a software product that solves business problems of a particular group of users, like store owners, fitness trainers, event managers, etc. What if each vertical has a different UI, different navigation, and some custom features implemented in the Checkout Flow? I bet that’ll drive your users crazy! Good user experience practices suggest that similar products should be predictable and do exactly what users would expect.
公司内部类似的产品 -我的产品是一个电子商务平台，但是在Wix，还有很多其他垂直行业也都具有Checkout Flow。 在这种情况下，“垂直”是一种软件产品，可以解决特定用户组(如商店所有者，健身教练，活动经理等)的业务问题。如果每个垂直具有不同的UI，不同的导航和某些自定义功能，该怎么办在结帐流程中实施？ 我敢打赌，这会让您的用户疯狂！ 良好的用户体验做法表明，类似的产品应该是可预测的，并且可以完全满足用户的期望。
Similar products on the market — same as the previous, but instead of comparing similar products in your company, take a look at products of the same type and kind on the market.
市场上的相似产品 -与以前的产品相同，但是与其比较您公司中的相似产品，不如看一下市场上相同类型和种类的产品。
Developer code / System Architecture — read the code, talk to developers, ask them to draw a model of the system, check what they expect from it. Sometimes you may find hidden features you would never find unless you knew exactly where to look. It could be error handling, limitations, big data-related flows, etc.
开发人员代码/系统体系结构 —阅读代码，与开发人员交谈，要求他们绘制系统模型，检查他们对系统的期望。 有时，您可能会找到隐藏的功能，除非您确切知道要看的位置，否则它们将永远找不到。 可能是错误处理，限制，与大数据有关的流程等。
World wide known standards, regulations — Accessibility, GDPR, performance standards. Apply whatever is applicable to your product.
全球知名的标准，规定 -可访问性，GDPR，性能标准。 应用适用于您的产品的任何东西。
Analytics data — if you have access to the company’s analytics data, you have everything you need. There is no better source of info on your product and your users:
分析数据 -如果您有权访问公司的分析数据，则拥有所需的一切。 没有更好的产品和用户信息来源：
- Most popular browsers, operating systems, mobile devices; 最受欢迎的浏览器，操作系统，移动设备；
- GEO breakdown; GEO分解；
- Product funnels. 产品渠道。
User feedback — since our main goal is to satisfy our customers, we have to take care in listening to what they have to say. Take a look at their feedback: what are their main pain points, do they clearly understand the product, is there anything they’d like to add? This should give you some good ideas about what to consider as requirements.
用户反馈 -因为我们的主要目标是使我们的客户满意，所以我们必须谨慎倾听他们的意见。 看一下他们的反馈意见：他们的主要痛点是什么，他们是否清楚地了解产品，是否想补充？ 这应该给您一些关于将什么视为需求的好主意。
Just be mindful of the fact that sometimes a user can complain about how a product behaves when what they are lacking is a specific feature. It’s like when you ask someone “why do you need a glass?”. People usually say that they need it to drink water. What if they don’t have a glass? They might say they will use their hands. So the reason they need a glass is to make it convenient to drink water, which means it doesn’t have to be a glass per se.
请注意以下事实：有时，用户可能会抱怨缺少的产品是特定功能时的行为。 就像当您问某人“为什么需要玻璃杯？”。 人们通常说，他们需要它来喝水。 如果他们没有杯子怎么办？ 他们可能会说他们会动手。 因此，他们需要杯子的原因是为了方便喝水，这意味着它本身不必是杯子。
The last thing I want to talk about is that you shouldn’t perceive each requirement you get or find as the source of truth. Since we are testers, we should question our requirements the same way we question our product. Requirements may also contain bugs: misinterpretations, uncertainty, impaired integration with different product parts, conflicting conditions, etc.
我想谈的最后一件事是，您不应将获得或发现的每个要求都视为真理的源头。 由于我们是测试人员，因此我们应该像质疑产品一样质疑我们的要求。 需求还可能包含错误：错误的解释，不确定性，与不同产品部件的集成受损，条件冲突等。
Often problems with requirements arise when those come from different sources: product manager and technical lead, designer and developer, worldwide known practice and custom solutions.
当需求来自不同的来源时，通常会出现需求问题：产品经理和技术主管，设计师和开发人员，全球知名的惯例和定制解决方案。
The final set of requirements should represent a system of rules and conditions that clearly describes all product aspects and unequivocally states if certain product appearance or behavior is desirable or a bug.
最终的一组要求应代表一个规则和条件的系统，该规则和条件应清楚地描述所有产品方面，并明确指出是否需要某些产品外观或行为或错误。
As a conclusion.
作为结论。
Requirements represent people’s expectations about a given product. They are divided into explicit — formally documented in a certain tracking system, and implicit — based on common knowledge about the usage, appearance or properties of a particular feature.
需求代表人们对特定产品的期望。 根据有关特定功能的用法，外观或属性的常识，将它们分为显式 (在正式的跟踪系统中正式记录)和隐式的 。
It’s QA mission to gain as much knowledge about SUT as they can in order to create a test coverage which would be able to reveal the majority of bugs hidden in the product.
质量检查的任务是尽可能多地获取有关SUT的知识，以创建测试覆盖范围，从而能够发现产品中隐藏的大多数错误。
Here are some good tips on where to look for implicit requirements:
以下是一些在哪里寻找隐式需求的好技巧：
- Products History 产品历史
- Similar products inside your company 公司内部类似产品
- Similar products on the market 市场上同类产品
- Developer code / System Architecture 开发人员代码/系统架构
- World wide known standards, regulations 世界知名的标准，法规
- Analytics data 分析数据
- User feedback 用户反馈
Finally, each requirement you obtain should be questioned and tested the same way we test the product, because requirements may also contain bugs.
最后，应以与我们测试产品相同的方式对您获得的每个需求进行质疑和测试，因为需求可能还包含错误。
Start your requirements journey, I hope you will enjoy it!
开始您的需求之旅，希望您会喜欢！
翻译自: https://medium.com/wix-engineering/hidden-depths-of-product-requirements-892c5ec055e6
ultraiso 深度隐藏
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
