随着上映日期的临近，团队肩上的压力越来越大。专注于下一次迭代，开发人员开始忘记周末是休息时间。管理者的压力可能更大。唯一阻碍我们的是测试……测试速度不够快。在开发周期结束时，很容易看到事情明显变慢，至少从某个角度来看是这样。三件主要事情测试人员平均每天要花很多时间在三项不同的活动上——测试、bug和设置，即TBS。T，测试时间——是我们所做的，也是引入很多混乱的地方。当我们谈论我们正在做的事情时，大多数测试人员报告状态时说“我正在测试一个新的报告功能”或“我正在为批量加载功能构建上一个冲刺的自动化”。这些陈述当然是准确的，但它们也可以隐藏您必须做的所有其他工作。如果我们想要更具体，那么我们可以将测试时间减少到只花在评估软件上的时间。当我查看文档并谈论产品的新更改时，它是为了帮助设计测试，这就是测试时间。当我做软件的时候，我的探索和测试也是测试时间。B、Bug——当我们发现一个bug时，我们从主要工作（需要测试的）切换到由该问题引起的一些意想不到的情况。如果问题不存在，那么我们就不需要花时间重现它，探索了解问题是局部的还是更大问题的症状，也不需要记录和支持修复。发现错误会破坏测试流程：停止工作，停止测试速度，如果你这样想的话。当我测试并发现一些有趣的东西时，通常我做的第一件事就是尝试重现这种情况。这是我正在放慢速度的时刻，因为我需要折回我的步骤。有时bug很简单，所以我可以立即重建它，而当bug很棘手时，就需要时间来解决。在研究了这个错误之后，也报告了此事。无论您是幸运地拥有演示还是必须在跟踪系统中进行完整报告，都需要时间。Bug阻碍了测试活动的进行，我们往往不知道它们什么时候会弹出。S，设置——与在解决错误时创建测试的启停体验不同，设置活动从一开始就限制了工作流程，就像高速公路上的入口匝道一样。设置是我在运行测试之前必须做的一切。在最简单的情况下，我使用诸如Excel之类的工具来创建数据，使用脚本或自己将其加载到软件中。此设置非常快速，只需几分钟。在图表的另一端，需要数小时或数天的设置活动。在一个案例中，我与开发人员合作了一两天来创建数据，将其打包到SQL脚本中，并在我们可以进行任何有意义的测试之前用数据填充系统。当您第一次测试新事物时，很难避免设置成本。如果您计划在将来重新测试，有时测试管理工具可以通过运行设置脚本或为该领域的下一个工作人员存储特殊信息来帮助降低成本。我们常常不注意自己的时间都花在了哪里，而且几乎从不平均分配。测试错误设置更像是一个三边跷跷板。当我花费大量时间设置数据时，可用于测试的时间和用于报告我发现的问题的时间就会减少。如何正确安排这些时间是一个平衡。如果您想知道为什么测试需要这么长时间，只需看看您的员工从事的所有其他未经测试的活动即可。这项工作可能对项目至关重要，可以添加信息、促进测试，但您可能会惊讶地发现它只是隐藏在表面之下。翻译链接：http://www.codeceo.com/article/why-your-project-take-so-long.html英文原文：WhyIsYourProjectTakingSoLong?
