功能性故障是与软件的功能相关的问题。例如：按钮无法提交表单，搜索不响应用户输入，应用程序崩溃。每当您执行操作时，而网站/应用程序不按您的预期响应，可能会出现功能性问题。由于我们对客户产品的信息有限，对其实施的了解也不足，因此很难确定观察到的行为是有意的还是实际上是一个问题。根据经验进行有根据的猜测，并通过测试不同情景来分析产品行为，可以帮助您找出答案。
如何确定应用程序行为是否是功能性问题：
尝试弄清楚一个功能是是否按特定方式设计的，还是实际上出现了问题。单独测试它以及与其他功能的组合，以发现潜在差异。
考虑客户可能的意图，并考虑产品可能只是按照实际实现的方式工作。
找到证据表明某些东西不按照应该的方式工作。支持您的主张。
例如：网上商店的功能与您所了解的其他网上商店不同。这并不意味着功能出现了问题。客户可以根据他们的需求来实现其产品。
例如：您声称某个表单字段没有经过验证，这是一个问题。是否有任何迹象表明他们打算对该字段进行验证？通过显示在某些情况下字段已经经过验证但在其他情况下没有经过验证的证据来支持您的主张。如果没有提供证据，那么这只是一个未经证实的主张。
在阻碍功能时，视觉或内容问题变成了功能性问题，因此应报告为功能性问题。
如果某个功能在不同情景下始终以相同的方式工作且没有明显问题，那么它可能是有意的（不是问题），您只是建议进行更改（可用性建议）。
严重性评估：
在判断问题的功能严重程度时，必须考虑多个因素：问题的功能影响，问题的程度，是否存在解决方法或是否是阻止程序执行的问题，是否存在潜在的和显著的销售损失，以及是否可以将此问题与同等严重性的其他问题进行比较。
一种直接的方法是查看问题的功能影响。考虑一个功能不可用有多严重。辅助功能不会阻止用户追求他们的目标 - 除了主要功能出现故障。问自己在整个产品背景中，该功能的重要性如何。
功能问题影响多少人、产品或物品是问题程度的决定因素。例如，“加入购物车”按钮是否在网店的所有产品详细页面上都不起作用，还是只在特定页面上不起作用？是否只有一小群用户受到问题的影响，还是所有人都受到影响？
考虑一下是否可以通过替代路径或选项来实现目标，或者某个功能仍然不可用。当您能够直观而轻松地绕过问题时，这种所谓的解决方法使您仍然可以实现目标。有解决方法的问题的严重性较低，而没有解决方法的等效问题则更为严重。最后，如果主要功能出现故障而没有解决方法，那么它就是一个阻止程序执行的问题。
估算潜在的销售损失是一种次要方法，因为通常只能假设人们可能如何对问题做出反应。尽管如此，请考虑潜在损失的高低。如果产品的价格相差几分钱或数百美元，这将产生重大差异。
最后，您还可以将您的问题与同一团队领导已经在此测试中批准的问题进行比较，以找出您的严重性级别是否合适。
我们对功能性问题有三个严重性级别：
低：
对产品的使用影响很小。
产品显示了意外的行为，但一般使用不受影响。
只有少数用户、产品或物品受到影响。
某个功能/功能出现故障或不可用，但有简单的解决方法可以解决问题。
高：
对产品的使用影响严重，但主要功能保持完好。
许多用户、产品或物品受到影响。
重要的功能出现故障或不可用，且没有解决方法。
重要功能出现故障或不可用，但有解决方法（因此不是阻止程序执行的问题）。
关键：
问题阻止应用程序或网站的核心功能。
阻止用户继续主要流程，例如结账流程。
问题导致运行应用程序或网站的公司潜在和显著的销售损失。
常见评估：
我们有一个具有固定严重性级别的案例列表。上述评估方案不适用于该列表上的案例。由于该列表将随时间更新，请定期查看。
边缘案例问题：
边缘案例问题是指在不寻常的方式下使用某个功能时出现的问题。使用典型数据和典型用户操作时，功能不会出现故障。以下是一些示例：
即时操作，例如在单击按钮后最小化应用程序
反复执行相同的操作，例如打开和关闭菜单
仅在不寻常的一系列操作后才出现的任何问题
每种情况必须单独评估。与我们的客户相关的边缘案例问题将被报告为低级问题。不相关的案例占了大多数边缘案例问题，将被拒绝。
强制性问题
通过不典型的行为或特殊条件来强制出现问题通常超出了我们客户的范围，因为这些问题与正常用户行为不符。以下是不典型行为或特殊条件的示例：
同时点击多个元素
随机按按钮
快速多次点击按钮
将窗口大小减小到不典型的尺寸
完整的RAM或内部内存导致意外行为
使用非官方、测试版或修改过的操作系统版本