-在可能的情况下-开发人员的工作
万一无事可做的情况下，团队的“公开问题清单”
知道如何进行转移测试人员
但是，到目前为止，我们还没有控制住这个问题。
问题：有人有类似的经历吗？您能怎么办？
我感谢所有建议！
#1 楼
“没有什么可测试的”
这是一个很有说服力的声明。 >
测试是通过探索和实验了解产品来评估产品的过程，其中在一定程度上包括：提问，研究，建模，观察，推断，等。
因此，除非没有什么新知识可了解该产品，否则，您没有任何要测试的东西。成为您可以学习的新事物。也许，如果您执行以下某些操作，则可能会发现它们：
配对编程（是，与开发人员合作）；
调查监视和记录仪表的结果；
扩展您的监视和日志记录工具；
在您的环境中造成混乱；
精炼积压以消除重复并提高简单性；
观察用户（对照组或真实组）使用您的产品；
调查竞争对手的系统；
重构任何代码（生产代码，自动检查代码，部署代码等）。
这些活动可能会使测试人员陷入困境新的地方，扩大了他/她对产品的理解。
评论
在过去的几周中，大多数观点已经完全实现。我们目前正在为项目设置基于CI的渗透测试。小组中的进一步教育也在议程中。
–莫农
19 Mar 25 '19在18:48
#2 楼
除了其他一些建议之外，您还可以考虑其他一些选择：为新的/最近的工作构建/运行负载测试（考虑到测试自动化的成熟度，您可能已经对此进行控制）
查看现有的测试自动化以进行过时或无效的测试（您不知道我希望达到这一点的数量）
查看并重构现有的测试自动化代码。在任何快速开发环境中，自动化测试代码的发布日期都可以很快。
查看和更新较早的客户文档。以我的经验，如果开发速度很快，这可能会很快过时。
查看其他文档以确保它是最新的。这可以包括（但不限于）用例，业务需求，数据库词典，功能需求，测试文档...
与产品负责人一起完善待办事项中的任何故事-或只是去那里查看他们，反正问问题。测试人员通常将其广度和深度与他们所熟悉的产品进行独特的组合，并且通常可以在进行编码之前进行潜在的问题更改。测试它们。如果需要配置，在编写故事/缺陷之前，可以节省大量时间来设置尽可能多的配置。我发现自己处于待命状态。
#3 楼
如果您有一组回归测试，那么测试人员可以从最容易实现的自动化开始进行自动化。从长远来看，这将为您节省大量时间进行回归测试。当然，这需要一些编程技能，如果测试人员目前还没有这些技能，那么这是他们学习并应用于自动化测试的绝佳时机。对于测试人员和团队而言，这都是双赢的。因此，测试人员正在为其个人工具集中增加一项新技能，这最终也将使企业/公司受益。评论
测试自动化是最新的，CI每天都在运行。但是，这不会为测试团队带来足够的任务。我们还提供了培训课程，因此测试人员仅在Selenium中接受了培训。
–莫农
19 Mar 25 '19在17:09
我们已经在实施渗透测试CI，并且正在对测试人员进行安全方面的培训。
–莫农
19 Mar 25 '19在17:11
@Mornon太好了！不知道还能做什么。我个人倾向于在一些低优先级的开发任务上提供帮助。
– Baljeet Singh
19 Mar 25 '19在17:32
#4 楼
尝试在此处添加更多建议...在冲刺结束时如何利用测试团队？
然后它们成为限制因素吗，即开发人员是否在等待测试人员的反馈？
有一点备用容量是很好的（大约15-20％），尽管很少能像您所看到的那样可见。简而言之，没有可用容量，您会排队，从而造成延迟。
对于您而言，我认为您可以在冲刺结束时充分利用其中的一些容量……如果您只能移动它，在那儿吧？
第一个建议：做一个星期的冲刺。
因此，您应该获得一些用户案例，这些案例的实现将跨越两个为期1周的冲刺。
其他用户的故事也可能从每周发布的版本中被“取消”（或者您称其为冲刺产生的工作软件），
只是因为它们仍然存在无法修复的错误时间
（使用功能标志来决定发布什么的最新决定。）
这些也将在下一个sprint的开始时变为“准备测试”。
第二个建议：使用看板而不是Scrum（也有看板和Scrum的混合体）。
使用看板系统，用户故事会不断进入“准备测试”列。
然后您仍然可以在“准备发布”中收集大量用户故事（即完成开发，测试完成），并
每周或每两周发布一次。
最后，决定了人员组成（5个开发人员，3个测试人员），
您可能比现在有更大的测试能力需求。
通过所有出色的自动化和其他改进，您也许可以一个测试人员进入另一个团队。
无论您做什么，都准备好接受一些“空闲时间”-将其视为提供测试仪可用性以获得更快的反馈。 。
#5 楼
就像您提到的那样，它是一个Scrum。实际上，它是Scrum的主要角色，它可以创建一个可交付的级别模块，以根据微小的用户故事进行准备，以便测试人员可以根据可交付的级别开始准备其测试用例。 >例如，如果无法测试一个微服务，则不应将其单独包含在sprint中，而应包括连接模块（前端或api）。与您的Scrum管理员交谈，询问他这种级别的产品所有者需要以这种方式制作用户故事。#6 楼
如何处理或防止测试团队中的闲置？首先关注质量保证的总体价值-从产品质量，测试质量，最近出现的缺陷数量为组织增加的价值发现，受影响的用户数量等。
如果您的关注点变成短期的，例如“人们看起来很闲置”，您可能会陷入很多不良的做法，将产出与工时等同起来（从更大的角度来看）它不会），微观管理，生活在恐惧中的人们等等。这不会激发高质量的工作。 />质量专家在等待新版本进行测试时应该怎么做？
并删除对空闲状态的提及。我知道从一个角度看（现在正在测试发行版）似乎是“闲置”时间，但是当您遵循此处许多答案的建议时，您会发现它根本不需要是“闲置”，实际上可以对于质量专业人员而言，这是最富有生产力和增值的时间，他们终于有时间去做“其他所有事情”，例如：我们都需要。
技术教育。在这个领域应该是一生不变的。不测试发行版，编写自动化程序，休假等时，应将所有可用的时间都花在上面。
社交活动。如果做得好（通常是低调的话），则可以加强联系。
领域教育。与用户和/或其代表共度时光，以更好地了解他们在现实世界中的使用方式。
重构。对于许多自动化工程师来说，今天的亮点。
减少技术债务。谁没有那个？
评论
所有开发人员都全职参与该项目吗？所有测试人员都在项目上全职吗？是的，所有开发人员和所有测试人员都完全参与了该项目
我建议您根据以下答案中提到的最佳实践以及您采用的实践来编写博客。您有一些空闲时间，此文档可供将来的团队使用，也可以提高其他测试人员的工作效率。