软件测试是要在潜在问题到达客户之前就发现它们，以便客户可以更好地体验产品。 这是关于我的团队如何改变方法并开始发现更多错误的简短故事。
我在一个由9个人组成的软件测试团队中工作。 我们执行建筑物管理系统的端到端测试。 我们像客户一样使用该系统，而其他团队则专注于开发和测试其功能和特性，从而构建了系统。
我们来自哪里？
过去，系统测试是由一个非常小的核心团队进行协调的。 他们处理了特定版本的系统测试。 他们计划了测试，创建了测试用例并更新了测试系统。
随着发行版的临近，在发行版的最后几周内，其他完成了功能测试的测试工程师也被带入系统级测试小组。
进行功能测试的测试人员是其功能的专家。 另一方面，他们几乎没有系统经验，并且很难进入不属于其专业知识的领域。
为了完成此设置，必须使用详尽的逐步测试用例。 测试用例将测试人员引导到新的领域。 经验丰富的测试人员可能会偏离规定的路径，而经验不足的测试人员可能会坚持执行步骤。 这是此类组织的理想设置。
敏捷转型
几年后，我们公司像许多其他公司一样，转而采用一种更为敏捷的软件开发方式。 创建了一个常设团队来管理系统级测试。 现在，该团队负责在整个开发周期中连续执行系统测试。
由于不再可能从其他团队那里借用测试人员，因此系统级测试团队在测试工程师的职位上一直处于成长状态。 招募了一些经验丰富，具有良好系统知识的测试工程师，包括我在内。
一开始，我们以与以往相同的方式进行测试。 很快，我们的测试系统就发展了，并通过增加的功能和硬件变得越来越大。 但是，团队并没有以相同的速度增长。 现在，我们应该在同等数量的人员上做更多的事情。
更新我们精心编写的逐步测试用例总是在优先级列表上排在最后。 我们从来没有去更新它们以匹配我们不断发展的测试系统。 我们仍然继续以相同的样式执行它们，很快发现我们从未发现它们有任何问题或错误。 感觉就像浪费时间运行它们。
我们实际发现的错误通常与运行测试用例有关。 通过仅维护测试系统本身，并使用新的硬件和配置对其进行扩展，我们发现了新的错误。 这并不是严格的测试活动，但至少对产品开发产生了一些价值。
作为具有探索性思维方式的经验丰富的测试工程师，我开始考虑是否可以用其他方式做到这一点。 之前，我已经对基于会话的测试进行了一些阅读，但从未尝试将其应用于现实中。
什么是基于会话的测试？
基于会话的测试是管理软件测试的更开放的方式。 代替了传统的逐步方法，使用了带时间限制的会话。
每个环节都有一个主题，一个使命。 测试人员将在给定的时间内探索任务和系统，并记下他的发现以及进行了哪些测试。
他将利用自己的经验在任务框架内测试事物。 他记录的笔记将产生新的任务，错误报告，向利益相关者询问的问题等。
起初，我的同事们不太愿意使用这种运行测试的方式。 我猜他们认为这种方法缺乏结构，如果执行得当，那是不正确的。
决定还是尝试一下。 我们开始将这种方法应用于与系统中服务器的重启和电源故障有关的非常有限的一组测试。
由于我们的系统在重启或电源故障之前，期间和之后的行为方式有很多方面，因此逐步进行测试用例毫无意义。
执行这种测试的旧方法是设置特定的配置，重新启动服务器，然后再次检查配置。 无聊
使用新方法，我们创建了具有特定重点领域的任务，并将这些任务与我们不同的服务器类型随机组合。
现在一个测试可以说：
在服务器xx上执行重新启动时，花一小时调查系统警报（我们系统中的功能）。
易于维护，但在测试变化方面功能强大。 我们还为测试人员提供了一些灵感，供他们从缺乏想法的情况中选择。
得到教训
与每项更改一样，它可能会有积极和消极的事情。
对我们而言，积极的事情是我们发现了更多的错误。 使用新方法，人们开始进行不同的测试。 即使两个人的任务相同，他们的探索方式也会如此不同，以至于我们涵盖了比以前更多的功能。
另一个方面是，团队认为以这种方式运行测试更加有趣，更具挑战性和创造力。 作为经验丰富的测试工程师，您想进行测试，而不是一遍又一遍地遵循相同的逐步指南。
就可维护性而言，它也是一种非常低成本的解决方案。 无需更新测试用例，因为它们的内容非常笼统。
到目前为止，我们唯一看到的负面影响是，人们没有对可追溯性和透明度所需的笔记进行记录。 有些人选择写非常详细的笔记，而其他人则根本不写任何东西。
我们团队在这方面缺乏的是围绕我们的笔记和测试结果进行的讨论。 我知道不做笔记的人和做笔记的人做同样好的测试。 但是，如果我们分享我们的笔记和想法，我们可能会相互启发，从而产生新的任务。
我们决定保留此系统，并将此方法扩展到更多有意义的领域。 在全面覆盖方面，我们还有很长的路要走，但是与每一次变更一样，最好一点一点地开始并随我们进行评估。
我的建议是让您的测试工程师去探索，执行软件测试的技巧，并回到他们的发现基础中来分享。 有了创造的自由，他们将进行适当的测试，并在那里找到错误！
