很少有人会在面试中爱上您的项目，而当您征服新市场时您会为之骄傲。当同事们的专业水平达到最佳状态时，这会变得更加令人愉悦，而在您的团队中，您会感觉就像在家人的怀抱中。我很幸运，不仅找到了这样的项目，而且很早以前就开始影响其中的测试过程。我将告诉您我们对最佳流程的理解包括哪些内容；我们如何获得月度发行以及它们如何为我们工作；以及我们如何适应检疫条件。
我们的项目是一个远程学习系统（LMS，学习管理系统），全世界不同国家有700万人使用它。该系统包含1000多个网页和大约10,000个测试用例。
现在，该项目雇用了大约15个开发团队-来自挪威的客户方和来自俄罗斯的Arcadia方。我8年前加入了这个项目，担任质量检查人员。在过去的两年中，我一直担任质量检查负责人，参与了测试过程的优化。
最佳过程的概念中包含什么
我们的主要任务是满足最终用户的需求，其中包括创建新功能和系统支持。特别要注意系统的速度和在重负载条件下的工作稳定性。
开发过程应首先主要实现业务目标的可持续实现，例如按时并按商定的质量水平完成工作。但是开发人员也应该对过程感到满意，以便使参与过程的每个人都满意。在我们的团队中，我们为我们建立了一个最佳流程，这是实现这一目标的方法。
开发过程一般：
a）满足团队需求的开发方法
我们使用Scrum和sprint持续3周。在冲刺之前，会先介绍其目标，并为此冲刺制定一套要求。接下来是计划，在该计划中，我们评估所有任务并确定将包含在sprint中的任务集。在sprint结束时，将进行Sprint审查，在此我们演示所有已完成的任务并宣布已实现的目标。这种方法对我们而言是最佳的：在sprint中，我们设法提供足够数量的新功能，同时修复并测试来自最终用户的一定数量的bug-将sprint时间的10％分配给此类bug。
排队：团队负责人，开发人员，测试人员。我们团队中开发人员与测试人员的比例为3：1。此比率使得可以均匀地实现sprint目标-流程参与者之一没有空闲时间：开发人员进行任何更改时，测试人员将创建或更新与此更改相关的测试用例。开发完成后，测试人员将检查更改，然后开发人员将继续进行sprint中的下一个任务或帮助进行测试（在测试大规模更改时这是必需的）。
产品负责人在每个冲刺开始时设定目标和要求，并在结束时接受它们。此外，每个团队都有一个Scrum Master来帮助解决新出现的问题。
为了使团队能够执行与sprint任务没有直接关系的各种活动，并且考虑到各种风险，完成sprint任务所需的时间为团队总工作时间的80％。也就是说，在常规冲刺中每天2个小时被保留用于通信，各种会议和研讨会以及修复冲刺中发现的错误。
b）明确的要求和良好的计划
为了确保计划不会拖延，并且由于先前未知的细节以及在sprint过程中已经添加的费力的其他更改，sprint不会成为失败，我们尝试仅将具有足够清晰和精确要求的更改纳入sprint。如果与变更有关的项目区域对于团队来说是未知的，或者在计划过程中出现了产品负责人无法回答的许多问题，则团队可以冲刺一个任务来研究该区域或研究任务，从而产生明确的要求甚至是某种原型。
c）回顾
修正错误也很重要。这适用于sprint和发行版。碰巧我们没有时间做某事，或者我们必须加班才能准时-例如，如果有必要对发布进行预测试（并且这些是公司将来希望避免的额外费用）。因此，我们进行回顾，讨论在冲刺或发布中的好与坏，并制定措施避免将来出现此类错误。
d）管理支持
有时会出现无法在团队层面解决的问题或情况-您需要更改流程或让公司管理层参与决策。看到他们想要帮助您并准备在这种情况下为您提供支持非常重要。在我们公司，一切都很好-这关系到Arcadia和客户方面的管理。讨论了所有问题，总能找到一个使各方满意的解决方案。
e）而且，我认为基本的是良好的沟通。对我而言，公司所拥有的是舒适工作的主要优势之一-仁慈，愿意折衷。
这适用于每个人：团队的每个成员，产品负责人，Scrum负责人，公司的管理层以及过程中的许多其他参与者。每个人都可以提出问题和讨论，开发人员可以就需求对测试人员进行咨询，并共同决定如何（从开发角度和从测试角度）进行最佳更改。反过来，产品负责人则与团队保持联系，迅速解决所有问题，并始终力争达到冲刺目标的一半。Scrum Master随时准备为您提供帮助：查找其他资源（测试人员/开发人员，如果他们是sprint或发行版所必需的）或建议如何最好地及时组织sprint。
测试过程：
a）与编写测试用例有关的质量保证标准（准则）。
在我们的项目中，测试用例是有关系统功能的主要详细文档，因此请多加注意。对于团队所做的每项更改，都会编写一个新的测试用例或更新一个现有的用例。
以前，当系统还没有那么庞大时，测试用例就以相当详细的方式编写，并包含各种特定步骤，但是现在这种方法已变得无法接受-更新此类测试用例需要花费大量时间。因此，我们（质量保证负责人）已经制定了标准，其主要要求是编写具有预期结果的测试脚本，而不是测试用例中的详细步骤。
b）与冲刺测试有关的质量保证标准。
已经制定了Sprint测试标准，以确保每个团队都进行良好的质量更改。
这些标准基于最大的测试范围，其中包括：
- 直接测试团队所做的更改（功能，必要时还可以使用UI）；
- 更改后，使用清单对系统进行测试：这是强制性检查，包括测试残疾人的可访问性，检查翻译，检查现有数据，使用特殊字符进行测试，安全性检查，测试移动应用程序中的更改以及其他检查...
c）与发布测试有关的质量保证标准。
发布过程及其中使用的标准将在下面详细讨论。
d）使用自动回归测试。
创建用于回归测试的自动化测试使团队的工作变得更加轻松-现在，如果您需要在命令更改后检查某些区域，则可以简单地针对系统的所需区域运行回归自动测试（如果该区域被自动测试覆盖）。另外，如果系统的某些部分因团队变更而中断，则回归自动测试将检测到这一点。
e）测试人员的互助，开发人员的互助。
我们没有太多的测试人员（平均，每3名开发人员只有1个测试人员），此外，他们不时地将精力从用于测试发行版的sprint任务中转移出来，并且可能没有足够的时间来完成所有工作。
在这种情况下，总是有其他团队的测试人员提供的工作量较小，可以提供帮助。质量检查主管或Scrum Master可以帮助您找到这样的测试人员。此外，如果已经为他们编写了测试用例，则开发人员可以帮助测试sprint中的更改。
f）测试人员之间的沟通。
为了进行交流，使用了Microsoft Teams中的聊天功能，其中每个人都可以提出问题并迅速收到答案，而其他测试人员则可以找到最新信息。我们还每月举行一次质量检查会议，测试人员可以互相分享他们团队的当前任务，并可以讨论任何问题-测试方法和/或与测试人员不熟悉的领域相关的测试案例的位置；有关发布的问题（未来发布团队的组成，更改测试时间表）；在缺少发行版中的严重错误后添加了其他强制性检查等）。
通过以上方法，您可以确保在安静的操作模式下进行高质量的测试。
:
我们过去每季度发布一次。在这样的时间范围内，团队对每个版本进行了很多更改。这种变化量肯定需要发布前的回归，因此回归有一个单独的时间框架，所有团队都与之相关。这通常需要大约2周的时间，测试人员和团队开发人员都参与了回归。
一段时间后，自动测试开始用于发布测试过程中的回归。并非所有回归测试都包含自动测试，有些是手动测试的。总的来说，这减少了回归测试的时间，但是由于系统的大小，完全回归仍然很耗时。
整个开发周期如下所示：
显而易见的是，这种发布方式不是最佳的，过度劳动密集型的，并且无法快速而灵活地满足最终用户的要求。发布过程的方法需要进行更改，因此决定更频繁地发布-每月一次。
当我们转向月度发布时，很明显，在发布测试阶段没有时间运行回归-即使是部分自动化的回归测试。现在，整个发布准备期仅需2周。因此，现在仅在必要时（如果开发人员报告需要对系统的特定部分进行回归），则在sprint中进行回归。
但是由于在测试版本的阶段，不仅需要检查新功能，还需要检查系统的一般状态，因此我们开始使用稳定化而不是回归。
稳定性包括：
a）每个团队测试此版本中包含的新功能；
b）关键区域测试是对系统主要区域的基本功能的测试（显然，它比完整的回归周期所花费的时间要少得多）；
c）测试在此版本的团队变更中发现的错误。
现在，整个开发周期如下所示：
让我们考虑准备发布所需的其他内容。
当稳定工作完成且释放包的质量良好时，在将其推出生产之前，必须在生产前的环境中测试配置。因此，Operations练习更新环境，并且测试人员在实际发行版之前使用当前发行包检查配置。
您可能会认为为发布发布准备了2周的时间太多了，并且在sprint中几乎没有时间进行测试了。但是通常测试人员需要4到6天的时间来准备发布。它取决于：
- 他的团队要发布的功能的复杂性和范围，
- 测试人员参与当前版本的发布团队。
项目的所有测试人员（包括发布团队）都参与稳定性测试；测试配置和发布本身仅由发布团队完成。
一般的发布测试时间表如下：
由于关键区域和配置包含持续的测试，因此我们已部分自动化了这些测试用例。这大大减少了准备发布所需的测试时间，因此将来我们计划扩大自动测试的使用范围。
在组织测试方面，为每个版本选择一个QA协调员（来自QA负责人）。通常，对于质量检查协调员，计划的发布时间比对常规测试人员要多，因为质量检查协调员的责任更大。这些包括：
- 定义发布团队，并在发布时检查其所有成员的可用性；
- 准备发布的测试计划；
- 在稳定和配置测试阶段启动自动测试；
- 在发布测试期间协调测试人员的工作；
- 帮助测试人员解决与发布有关的各种问题；
- 控制测试的实施，并在必要时控制负载的重新分配，以帮助测试超负荷的团队（这些团队可以是已经完成发布测试的其他团队的测试人员，也可以是团队开发人员，也可以是QA协调员）。
当然，没有问题就不会完成发行。我们解决了这些问题，并制定了如何在将来避免它们的计划。以下是我们最近遇到的一些问题：
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
解决方案：在这种情况下，即使发布需要进行所有2周的工作或加班工作，我们仍要花时间测试发布所需的所有内容，因为发布是比冲刺任务更高的优先级任务。
但是无论出现什么问题，我们始终可以通过发布团队的力量或通过让特定领域的主管人员参与来解决这些问题-最主要的是，这始终是协调一致的团队合作，可以带来良好的结果。
隔离工作：如何确保测试人员的工作
在我们的项目中，办公室工作是前提。这样做是为了在工作时间内可以找到该过程中的任何参与者-如果突然他没有在聊天中回答，那么与他一起工作的人可以通知他某些同事需要他。这很重要，因为有些团队在挪威，有些在圣彼得堡。
在大流行期间，挪威和俄罗斯都将大多数人口隔离，我们不得不转向偏远地区。
我们继续照常工作：团队仍然以良好的冲刺效率完成冲刺，并按时发布了发行版。
沟通仍然保持良好水平-Teams应用程序满足了所有需求：在聊天中进行了活跃的对话，会议顺利进行；如果有任何需要紧急讨论的问题，他们会召集任何项目参与者。
从组织测试的角度来看，没有任何问题：在工作时间内，所有测试人员都在聊天中回答并迅速参与了测试发布。万一我们需要找到某人，但他没有在聊天中回答，我们已经准备了一个手机号码列表，但我们从来不必使用它。
我们在家中远程办公时面临的唯一问题-由于VPN的特殊性，不可能在团队环境中通过电话/平板电脑测试系统。但是这个问题得以解决-感谢项目经理和IT服务人员找到了解决方案。通过家庭网络连接时，我们开始使用代理，现在，我们可以在家中对移动设备进行测试。
现在，我们部分返回办公室，但是公司的一部分继续在家工作。甚至在城市的不同地方，我们仍然是一家紧密合作的公司，在如此艰难的时刻，不工作的条件下继续工作，当儿童和宠物需要注意时，互联网速度变慢，并定期消失，灯熄灭，并且分散了很多注意力。您根本不了解的因素，您又如何再次工作？
但是，我们在一起将生存下来，最后，回到成熟的办公室生活中，我们将比平时更加彼此微笑。
结论
总结以上几点，我想指出几点：
- , , . — .
- , , .
- , , , — . , .