这有效地将我们的开发缩减为每次迭代大约8天。对于在此环境中工作过的那些人，您可以提供有关如何处理此问题的任何建议吗？您是否将额外的时间增加到迭代结束？您是否没有分配额外的时间进行测试，而只是在迭代之前进行开发？我们的目标是始终拥有可部署的软件（尤其是在迭代结束时），因此拥有这些测试天似乎是必须的。
#1 楼
我曾经是一个团队中的第一个测试人员，并且看过他们之前如何测试他们的软件（通常也做得很好）。对于您如此小的人，我认为您在大多数情况下都处于正确的轨道。随行创建自动测试很棒。您可能会发现某些TDD方法有一些好处，这些方法要求您在编写代码之前先创建测试。绝对可以使测试更容易编写。
而不是每个人在迭代结束时花一两天的时间，让一个（轮换）开发人员在整个迭代过程中定期花时间并测试软件怎么样？ 。这肯定会减少您的反馈循环。在这种情况下，您可能只需要在迭代测试结束时花费1天。
我知道很多人反对这个想法，但是我看到一些小型团队会花很多时间反复进行一遍，然后进行一次集成/运行状况检查迭代，只需检查一下它的全局情况即可。
您每周一次/迭代一次就可以在现场找客户吗？最后，我同意Phil的回答，这应该是您最终的目标，但我也明白，很多时候，在财务上/现实上不可行短期内全职专用测试仪。
评论
TDD很有帮助，并且在大多数情况下，我们确实尝试将所有内容自动化。我们在可视化方面做了很多工作，很难实现自动化的测试，因此需要进行一些手动测试。我们在整个迭代过程中一直在进行测试。我最大的担心是，迭代结束时的最后一组更改确实没有获得与第一组所做的相同的测试（如果我们希望在每次迭代结束时进行部署）。
–杰夫·斯托里（Jeff Storey）
2012年6月27日在2:13
自从我同意他所说的话以来，我只是想稍微提一下林登的答案。您可能会确定自己要承担测试工作以及开发人员的工作，以确保将其完全归入每个故事的一部分。在完成这些任务并接受整个故事之前，不应进行迭代。
–丹·斯内尔（Dan Snell）
2012年6月27日，下午3:11
丹，我们在处理单个故事时正在测试它们，但是在发布给客户之前，我喜欢做一些附加的验收测试和一些常规测试，以确保系统的各个部分可以很好地协同工作。在这种情况下，您有什么建议？
–杰夫·斯托里（Jeff Storey）
2012年6月27日在3:50
#2 楼
听起来像迷你瀑布，而不是敏捷。您如何知道故事是完成的，而不仅仅是完成的？让自己成为一个好的测试人员并适应他们，这就是我正在做的:)评论
当然，我们也在迭代中进行测试，而不仅仅是将其保存到最后。但是我觉得直到迭代结束才检查代码有点冒险。我想花点时间测试一下，然后再将其发送给客户。
–杰夫·斯托里（Jeff Storey）
2012年6月27日在2:11
为“完成” +1，而不仅仅是“完成”。与其他开发人员一起工作时，这一直是我一直的棘手问题，因为他们更加专注于“完成”部分而不是“完成”部分。
–corsiKa♦
2012年6月27日14:14
@Phil，您能否详细说明如何在敏捷中进行测试？与开发人员配对编写单元测试？将故事分成较小的可测试部分？在开发人员实施故事之前编写故事的测试？
– dzieciou
2012年10月7日20:08
我最近与之合作的一位开发人员写了一篇博客文章，概述了他的方法，可能比我写出大量评论要容易阅读。将他在文章中概述的方法与我围绕他的代码和故事进行探索性测试结合起来，您便可以采用我们尝试的方法-spin.atomicobject.com/2012/10/03/…
– Phil Kirkham
2012年10月8日13:23
#3 楼
听起来您正在花时间进行回归测试。连续的自动化测试方法将减少您的测试周期。我将围绕这个想法设计您的自动化套件，并在所有版本上运行单元测试时，每晚运行它以进行GUI和服务测试（如果您雄心勃勃，则可以进行更多测试）。夜间自动回归套件可能会将您的需求减少到只有一到两天的测试时间（就像您说的那样，很难自动完成所有测试）。此外，您还将获得有关质量的夜间反馈。当然，这是一个微妙的平衡。您需要寻找时间来创建，管理和维护该时间。您会看到如何轻松地向您推荐团队中添加测试人员以帮助您进行管理。
管理人员推销：
添加测试仪可以将测试周期减少1天。如果您要运行2周的冲刺，那么每年将额外增加26天的开发时间（增加2 1/2个冲刺）。我不确定您的团队有多大，但很可能应该轻松支付测试人员的薪水。当然，测试人员最好是摇滚明星。
#4 楼
为了增加Lyndon的答案，也许您可以以更正式的方式分配给开发人员与测试相关的活动。如前所述，自动化测试很棒，因此请考虑将其与生产代码一起作为开发的优先级。指派的开发人员可以全职或兼职编写和维护测试，并使其保持最新状态并与当前的编码标准保持一致。将测试代码像生产代码一样对待可能会大大帮助您的测试过程。除此之外，如果开发人员维护自动化测试，他们可能会至少对软件进行一些“手动”测试，这是一个好处。再次，将这些过程视为头等公民；允许开发人员或任何其他形式化的时间来探索和手动检查您的软件，以实现自动化或其他目的。不要在任何时间都挤在测试中。拥抱它以了解您的软件。
最后，如果您发现自己在想“我真的认为我们需要质量检查/测试小组”，请优先考虑。找出最适合您的团队的方法，然后继续进行下去。预算用于各种事务，包括新员工和新资源。
#5 楼
我在一个敏捷团队中工作，在每个故事中我们都使用了记录卡。一旦我们讲完一个故事，我们就会在卡的背面写出用户接受标准。使用的语言很重要，因为您不想在故事中提供解决方案，因此您的标准必须解决要解决的问题，而不是解决问题的方法。这样一来，团队中的任何人都可以对其进行测试，以确定是否满意。您可以指定一个没有故事工作的开发人员在完成最终测试以将其移至“完成”列时执行该最终测试吗？如果它对您有用，那么我不会更改您的迭代长度。而是根据需要调整每次迭代要提交的点数。
在组建团队时，我们添加了自动回归测试，并使用我们的BA进行了手动回归测试。最终，我们确实获得了质量检查资源，我同意其他所有人，他们告诉您它们有什么好处！
#6 楼
我处于相同的情况下在测试期间我们发现了太多的错误
，所以我建议您不要给开发人员太多的时间
请他们尽可能快地开发应用程序
，然后您就可以开始使用您拥有的最新版本进行测试了
对您和您的团队也都很好。
TY
评论
那有什么帮助？
– Phil Kirkham
2012年10月6日14:41
如果尽快开发会产生更多错误，该怎么办？这将增加在测试+记录错误+修复+（又是全部3个）上花费的时间。如果开发人员创建的bug过多，那么加快开发速度只会使事情变得更糟。
– Suchit Parikh
2012年10月8日在22:35
看看我们是否不对开发人员施加压力，然后可能会发生，他们不专心于工作，如果他们在一定压力下可以正常工作，然后给他们一些压力，然后如果他们不能离开，那么给他们更多的时间，这可能是另一件事如他们所愿，否则可能会发生太多错误。
–塔伦
2012年10月23日在6:17
评论
您是否考虑过建立正式的质量检查/测试小组？一个与开发团队并行/并行工作的人吗？理想情况下，我想这样做，但是预算不允许这个项目使用。当前的项目正在结束，但只是好奇人们对新项目的总体处理方式。
我回答了类似的问题：sqa.stackexchange.com/questions/3224/…