在敏捷软件开发中工作时，您经常会看到接受标准的引用。虽然这句话听起来可能不必要地令人困惑，但实际上很简单。尽管并非每个团队都使用它，但这对于成功的发布可能至关重要。那么什么是接受标准？
接受标准的技术定义是，“软件产品必须满足的条件必须被用户，客户或系统级功能（消耗系统）所接受的条件。“
简而言之，接受标准是有关新软件功能如何工作/外观的详细信息（也称为要求）的列表。这确保了：
作为日常用户，当您遇到错误时，通常不会停下来思考：“也许此问题仅在Windows 10上的Chrome版本89上发生！”你为什么要？大多数人期望网站和应用程序在其系统上正常工作 - 特别是如果他们不使用深奥的旧版本的Internet Explorer。
如果您从事软件开发方面的工作，最好记住遇到它的用户，即“边缘外壳“错误就是一切。但是，如何确保发现这些特定环境的错误？
即使找到了它们，您也如何优先考虑它们？毕竟，对于100％可能的设备/浏览器/屏幕尺寸组合，您的应用程序或网站永远不会看起来完全完美。与大多数事情一样，找到平衡是关键。
请继续阅读以了解有关为什么交叉浏览器测试很重要的信息，以及如何正确做到这一点。继续阅读→
Sprint计划是大多数敏捷团队所做的事情。但是，当每个团队都有不同的需求时，并不总是有一种“一件尺寸合适”的方法。结果，并不总是清楚质量检查的作用。质量保证是否应该是冲刺计划过程中不可或缺的一部分？还是应该告诉测试人员吉拉董事会并遵循截止日期？请继续阅读以了解质量检查的角色如何以及应该如何适应冲刺计划过程。
首先。QA甚至是有在短跑计划中的角色？毕竟，许多公司的日常答案可能是“否”。但是要拥有最好的软件开发和敏捷过程可能，应该是“是！”
QA每次冲刺只有大量的测试时间。因此，确保测试人员可以为时间表中的所有门票提供完整的测试覆盖范围是一个好主意。
冲刺中的一些门票还需要质量保证的高级计划。例如，他们可能需要编写测试用例，查看设计文件或提出后续问题。质量保证者将从一开始就知道哪些门票在冲刺中，而不是接近末端，就会更加准备。
当您在应用程序或网站上测试新功能时，认为拥有测试用例是一种最佳实践。理想情况下，将给予测试人员验收标准对于正在开发的功能。当质量保证准确知道功能应该或不应该做什么时，编写测试用例就足够容易了。（如果您感到迷失，请参阅我们的文章解释测试用例。）但是你如何编写测试用例没有要求？
毕竟，在一个快节奏的敏捷过程的现实世界中，您不会总是拥有它们。遇到具有简单描述的JIRA票，并且没有真正的要求列表，这很常见。当然，您可以要求负责人添加它们。但这并不总是很清楚应该是谁。（开发人员？项目经理？产品经理？更高？）
在许多情况下，任务可以来回传递这么长时间，它将测试过程延迟几天 - 如果您最终完全得到要求。继续阅读→
当您在领域工作质量检查测试，您不可避免地会遇到对质量检查负面看法的人们。尽管这种情况可能经常发生，但有多种方法可以解决。如果您可以确定何时在噪音中持续下去以及何时向后推，那么您将能够容纳任何被抛弃的东西。
总体质量检查和开发人员关系应该是协作的。与尊重质量保证的开发人员合作可能很棒！但是，对质量检查的负面看法的最常见作用往往是工程师。请记住，这并不总是工程师的错。
一些QA测试人员可以以他们的方式屈服报告错误。他们可能将其视为对开发人员的自我价值的个人批评。自然，如果开发人员认为自己受到个人的批评，他们可能会做出防御能力。（了解有关如何与开发人员合作的更多信息质量检查和开发人员关系）继续阅读→
什么是用户接受测试？
