管理分布式QA团队 - Litera中文网站

在当今的工作环境中，各地的组织不仅接受远程和混合团队-他们完全接受它们。这对您的QA团队意味着什么？尽管QA很适合分布式工作环境，但在管理分布式QA团队时仍需要考虑一些特殊注意事项。

希望学习:

各种类型的混合和远程工作模型
如何利用团队工作协议
实施定义 “完成”
如何更好地了解QA “技术债务”
四个具体的例子，如何增强流程的分布式团队
机制持续改进

定义 “分布式QA团队”

鉴于远程工作的不断发展的性质，组织正在采用不同的模型和方法。为了本文的目的和整体改进，我提供了四种不同的分布式工作模型的定义:

1.混合分布式工作模型

这种方法涉及团队组成，成员在本地和远程工作，跨越不同的时区和位置 (例如，在纽约有本地成员，在里斯本有远程成员)。

2.远程分布式工作模型

在此模型中，团队由分布在不同时区或不同位置的成员组成，所有成员都完全远程工作。

3.混合集中式工作模式

在此模型中，团队在同一时区或区域内混合本地和远程成员。

4.远程集中工作模式

在此模型中，团队由完全远程的成员组成，所有成员都位于同一时区或区域内。

定义和理解各种混合和远程工作模型在建立团队和Tuckman的团队发展阶段 (风暴，形成，规范和执行) 中至关重要。它还提供了对每个模型独特的挑战和改进机会的宝贵见解。

共同挑战

现在我们已经清楚地了解了远程和混合团队结构的类型，让我们找出这些模型共有的一些共同挑战:

处理优先项目时效率低下:难以有效地集中精力或能够 “蜂拥” 最优先的项目。
SDLC工件的复制:各种软件开发生命周期 (SDLC) 元素的重复，包括测试用例、缺陷和用户故事。
模糊问责制在SDLC: 缺乏明确的责任，导致歧义，如语句，“我的测试通过之前的代码合并，所以这不是我的错…”
团队速度不一致:团队速度或开发团队在特定迭代或冲刺 (sprint) 期间可以完成的工作量缺乏一致性或可预测性。

常见的挑战在受管制的行业

此外，当团队在受监管行业工作时，他们面临着额外的独特挑战。受监管的行业受到严格的政府法规的约束，这些法规适用于教学或金融服务等专业。以下是领导者和团队成员应该考虑的具体挑战的概述:

国际团队的各种合规标准:跨越国际边界的远程团队可能需要导航并遵守不同行业的不同合规标准。

用于灾难恢复的云配置:可能需要为灾难恢复和复制建立特定的云配置，并确保应用程序环境的多个可用区覆盖。

机密信息的数据访问限制:可能需要对不在特定国家/地区的团队成员实施严格的数据访问限制，尤其是涉及机密数据。

策略，以最大限度地沟通

参与混合和完全远程的团队提供了许多好处，但有效的沟通可能会带来挑战。为了通过沟通提高团队绩效，需要关注的关键领域包括建立 “工作协议” 和采用 “ 左移 ” 心态。

团队工作协议

团队工作协议是所有团队成员都同意并遵守的一套共同商定的 “规则”。这些协议被视为在sprint回顾会议 (针对敏捷团队) 和根本原因分析会议期间重新访问的动态 “活文档”。

工作协议项的注意事项可以包括管理和软件开发生命周期 (SDLC) 主题。这些可能包括诸如容量规划，团队成员角色和职责的描述以及发布批准的工作流等方面。

在此示例中，团队工作协议解决了跨管理 (容量规划) 和SDLC (发布工作流) 方面的考虑事项。

团队工作协议示例

在sprint回顾会议期间

协议1: 规划能力

当前状态:在某些情况下，由于工作负载分布不均，团队成员感到不知所措。
讨论:该团队讨论了平衡工作负载对提高效率的重要性。
调整:团队同意更新工作协议: “在sprint计划期间，团队将集体评估各个工作负载。如果发现不平衡，将进行调整以确保任务的公平分配。”

在根本原因分析会话期间

协议2: 工作流发布

当前状态:释放过程容易出现延误和沟通不善。
讨论:团队进行根本原因分析，以确定发布工作流中的瓶颈。
调整:团队同意加入新的工作协议: “将为每个sprint分配指定的发布协调员。将建立并遵守发布批准和沟通渠道的文件化工作流程。

解决跨管理和SDLC方面的考虑确保团队不仅在软件开发实践上保持一致，而且在影响其有效性的更广泛的组织和管理过程上保持一致。

定义 “完成”

随着绝大多数软件开发团队现在采用各种形式的敏捷方法，实现 “完成标准” 概念的一致性对于分布式团队来说变得更加关键。

“完成标准” 的概念可能因团队而异。领先的Agile将done (DoD) 定义为 “当软件产品必须满足的所有条件或验收标准时，并准备好被用户，客户，团队或消费系统接受。

示例 “完成标准”

以下是软件开发环境中各种任务的 “完成标准” 的一些示例:

用户情景实施:

所有验收标准均满足
代码编写、审查和批准
单元测试和集成测试已编写并通过
用户文档已更新
代码被合并到主分支

错误修复:

已确定的错误已修复并验证
相关的单元测试和回归测试被创建并通过
文档更新以反映错误修复
代码更改被合并和部署

功能开发:

所有功能要求均已实现
代码遵循编码标准和最佳实践
全面的单元测试和集成测试编写并通过
用户文档和API文档已更新
代码合并到主分支

对 “完成” 的定义有一个共同的理解将确保您的分布式团队成员与为完成工作项而设置的标准保持一致。当出现需要澄清的情况时，团队成员可以利用团队工作协议，并确保团队继续不受阻碍地执行。

增强分布式团队

的流程<img src="data:image/svg xml,”class =” aligncenter “>

在软件开发团队中定义和实施特定过程可以显着影响质量和输出。当在分布式团队中操作时，这些因素可以被正面或负面地放大。以下是一些可以显著影响分布式团队的有效性和效率的关键流程:

1.测试用例评审流程

确保生产被视为 “资产” 而不是负债的高质量测试应该是一个集体的重点，不仅涉及QA团队成员，而且涉及每个人，包括测试人员，QA工程师和利益相关者。无论测试类型 (单元、集成、功能、手册等) 如何，团队都应遵循结构化的审核流程。

要考虑的关键项目包括:

与团队工作协议保持一致:对测试用例的同行评审应遵守团队工作协议中规定的准则。
代码合并前的质量门:审查过程应作为质量门，确保在针对要合并的代码运行测试用例之前进行彻底检查。
使用通用平台:使用统一的平台来跟踪、查看和解决各种QA测试类型的注释，从而促进高效协作。

图像:与TestRail企业测试用例审核和批准流程，用户可以设置协作审核和批准流程，以确保测试用例准确定义您的应用程序并满足组织的标准。

2.界定 “环境索赔”

许多团队采用被测产品或系统的多个环境来促进快速开发、测试和接受正在开发的功能。问题可能出现在分散的团队或流程不完善的地方，导致在确定 “如何、什么以及何时” 部署和更新环境时出现混乱和生产力下降。

利用 “环境索赔”

使用 “声明” 或跟踪团队环境的版本和目的的概念将使团队成员能够在整个开发和里程碑推广过程中利用它们。以下是一些有助于更好地支持团队环境管理的流程示例:

确定团队所有者和目的:清楚地确定团队所有者和每个部署环境的目的。考虑将此信息添加到团队工作协议中。
维护 “环境声明” 页面:手动或通过自动化创建和维护 “环境声明” 页面作为动态工作文档。
对齐CI/CD管道:根据有关环境部署和促销的团队工作协议，调整持续集成/持续部署 (CI/CD) 管道以自动或手动进行部署。
实施CI/CD和测试管理集成:实施持续集成/持续部署 (CI/CD) 和测试管理集成这使得能够在发布之前针对相应的环境促销跟踪测试执行。这确保了简化的流程和对与环境变化一致的测试进度的全面可见性。

图像:中创建和管理唯一的自定义测试用例字段TestRail企业标记和跟踪在发布之前升级代码时跨测试环境执行了哪些测试用例。

3.增强QA技术债务的可见性

开发团队中的协作超出了软件工程师和QA/测试角色。分布式团队通常会从提高与基础架构和测试相关的技术债务的可见性中获益。以下是不同团队应该考虑的实践，以增加产品所有者、利益相关者和QA之间技术债务的可见性:

维护产品积压工作 (backlog):在您的团队的敏捷工作管理/跟踪工具 (例如，Jira,拉力赛)。这确保了可见性和优先级。

自动跟踪测试候选人:跟踪可能成为自动化候选对象的手动测试，以及那些已经集成到团队自动化套件中的手动测试。这有助于对自动化优先级进行有效的决策。

像对待应用程序代码一样对待测试:考虑与应用程序代码相同的测试。为片状或损坏的测试创建缺陷或任务，在常规 “分诊” 会议期间根据优先级和影响启动审查并解决它们。

图像:中的自定义字段TestRail企业为跟踪自动化测试候选人提供有价值的功能。通过在自定义字段和团队的敏捷工作管理或跟踪工具之间建立链接，您可以增强对测试流程的可见性。

4.注重持续改进

在工作和管理分布式团队时，营造一个每个人都有机会评估其绩效并进行改进的环境变得更加重要。

举行 “一加一” 会议

对于管理分布式团队的领导者来说，与集中式团队相比，获得个人奋斗或成功的洞察力可能具有挑战性。使用 “一加一” 格式实施预定的团队会议可能非常有效。这涉及:

反思一个你觉得你个人可以改进的项目。您可以使用客观反映、报告和度量，如团队速度、缺陷等。
反思一个通过客观地反映团队速度、缺陷和发布质量等指标，团队表现出色的方面。
什么行动你觉得有必要根据你的反思采取行动吗？

图像:与TestRail,用户可以自动生成全面的项目报告，跟踪测试覆盖率，并在需求，测试和缺陷之间建立可追溯性。他们还可以报告数十种DevOps工具的测试结果，以进行高效分析。

团队 “提升技能”

随着QA团队成员在他们的角色中面临越来越多的要求，保持持续学习的奉献精神 (通常被称为 “提高技能”) 变得至关重要。监督分布式团队的领导者应该优先考虑并分配时间来学习新技能，测试工具和测试流程，以确保持续的专业发展。

两个关键方面应考虑:

sprint计划中的优先级:在团队冲刺计划中为自我指导的学习和培训分配时间，使其成为整体冲刺能力的组成部分。

可衡量的目标:建立可衡量的培训目标，纳入认证、课程完成和基于技能的评估等目标，例如LeetCode挑战和TestRail学院。这确保了持续学习的有形和面向目标的方法。

图像:的TestRail学院提供免费且定期更新的多媒体课程，您可以在其中学习最佳实践，掌握产品功能并大规模培训您的团队!

如果您不采取适当的步骤来最大限度地发挥团队的潜力，那么在分布式QA团队中管理和工作可能会很有挑战性。实现本文中的提示和策略将大大增加分布式团队中的沟通和协作。

主要外卖

定义和执行团队工作协议
利用商定的 “完成” 定义来确定工作项的完整性
组织和跟踪质量保证技术债务在产品积压中的可见性
维护环境 “声明” 和使用整个SDLC
实施测试用例审查和批准根据工作协议
进行 “一对一” 会议，以反思绩效并推动改进

有兴趣了解有关如何管理分布式团队的更多信息吗？观看此网络研讨会 “管理分布式QA团队的策略”，了解如何增强适用于所有行业 (包括高度监管的行业) 的混合和远程QA模型。

Chris Faraglia目前是TestRail的解决方案架构师和测试倡导者。Chris拥有15年的企业软件开发，集成和测试经验，涉及核能发电和医疗保健IT领域。他曾管理过美国、中欧和西南亚的分布式测试团队，并与之进行了沟通。

在本文中:

本文档中没有标题。

注册我们的时事通讯

注册我

分享这篇文章

</span