概要：你有多少次开始解决一个特定的问题，并意识到，实际问题并不是你所想象的那样？Ajay Balamurugadas分享了他与同事进行一次谈话，关于软件测试中有关测试用例的问题，以及他从解决问题过程中学习到的经验。这也是你应该思考的。
我的朋友打电话给我讨论他的工作场所的情况。他曾经是一个项目的唯一测试员，并描述了当他得到一个测试想法的时候他将如何写测试用例。慢慢地，团队的规模越来越大，产品增加了更多的功能，测试用例的数量上升到了千量级。
随着测试用例的增加，每个测试用例的细节没有被重视。每人都明白每个测试用例的含义，所以这不是一个需要立即关注的大问题。
然而接下来计划自动化测试用例，出现了多个问题。自动化工程师不理解测试用例，因为它们不够详细。用于编写测试用例的工具不支持批量导出。测试用例集中含有许多冗余测试用例。最后一个问题是回答管理层，他想知道是什么在阻碍测试用例的自动化。我的朋友询问我是否知道任何可以解决他所有问题的工具。
我已经克制了在打电话时打断他的冲动，但在这一点上，我只问了一个问题：“你想解决什么问题？
他再次提到这个工具。这次我打断了他，问自动化工程师是否使用现有脚本的能力是一个需要解决的问题。他肯定地回答，也想讨论增加更多的细节到现有的测试用例。
从第一个问题开始，我们谈到自动化工程师的关注是合理的。我们可以从一组具有足够细节的测试用例开始，并提交给自动化工程师。而不是提供足够细致的完整测试用例，我们想可以从最低限度开始，看看是否有任何新的问题意外出现并作为演习的一部分。
下一个问题是完整的测试套件缺少细节。我告诉他检查清单和思维导图可以替代测试用例。我们认为，如果人们抱怨测试用例中缺乏细节，我的朋友可以告诉他们保持测试用例的精简可以节省多少时间，以及如何将时间花在与产品交互上。
如果他的团队中的任何人担心一些测试想法未被测试，我说他们将不得不花费精力来培训测试员，而不是使测试用例体积变得庞大。除非你所处环境需要具有测试数据的详细测试用例，否则检查列表和思维导图是笨重测试用例的健康替代方法，因为它们易于查看和更新??
在这一点上，我们已经确定了两个问题：一是自动化工程师需要详细的测试用例，二是千量级的测试用例需要一些维护。我们决定在自动化工程师拿出脚本时，我朋友的团队可以花时间将测试用例转换为思维导图或检查清单。试图找到一款工具来解决我朋友的所有问题的一次谈话结束了，我们意识到工具是没有必要的。
有多少次开始解决一个特定的问题，并意识到，实际问题并不是你所想象的那样？当我等待朋友尝试一些我们讨论的策略时，我开始思考我们的讨论。这里有一些外卖（附送品）。
单独解决问题
我喜欢《Are Your Lights On》一书，Jerry Weinberg和Donald C. Gause将一个问题定义为所期望的事物和所感知的事物之间的差异。许多人认为多个问题可以一次性解决，但是逐一检查问题更容易。在这种情况下，我的朋友和我试图解决自动化测试套件的问题，其次是详细的测试用例问题，然后没有更多的紧迫问题需要解决。
问题是相对的
当涉及软件测试时，bug并不是绝对的；而是产品和某些人之间的关系。同样，一个问题也是一种情况与一个人的关系。如果你修改了某人的期望或情况，最初的问题可能就消失了。
问题和解决方案不是永久的
当我的朋友的测试团队很小时，测试用例是相当动态的，这不是问题。一旦自动化工程师进入该环境，同样的测试用例也就成了问题。一个问题的解决可能会引起另一个问题。现在你可以决定哪些问题是可以管理的。
考虑成本、价值与风险
当思考一个可能的解决问题的方法时，问问你自己：
- 这个方法的成本是多少？
- 执行此方法的价值是什么？
- 不执行此方法的风险是什么？
在花费大量的时间、金钱或精力之前，用较小的样本来检验你的理论。
不是所有工具都能解决问题
一旦碰到问题，许多人认为工具是解决之道。但有时，工具在短期内解决了一些问题，并在未来带来了更多的问题。在选择工具之前考虑风险。
如果你在试图解决某个问题的时候被卡住了，与某个不属于所处环境的人交谈可以帮助你获得一个不同的视角。不同并不一定意味着更好，但它可以帮助你想起以前没有想到的东西。
你还有什么建议给我的朋友？可以在评论中分享你的想法。
由ruink翻译自 Ajay Balamurugadas 的《Problem-Solving in Software Testing: A Conversation》一文。