以我的经验，最好的开发人员/测试人员将我称之为无聊的博学带入软件测试。换句话说，他们经常将死记硬背的任务自动化，这样他们就可以专注于软件的测试和分析。

我经常使用的一个例子是即时消息或电子邮件客户端中的“添加联系人”功能。要测试该功能，我需要尝试长名称、本地化名称、空白名称等。我还需要测试添加和删除联系人。测试想法的矩阵可以很快扩展......我会厌倦尝试所有这些事情 - 更糟糕的是，我永远不会尝试添加和删除联系人 500 次的性能/压力场景（我也不会自动在操作过程中检查磁盘和内存状态）。

简而言之，优秀的测试开发人员会查看测试问题，然后弄清楚他们如何使用程序或自动化来帮助他们有效地解决测试问题。

就我个人而言，我发现除了出色的测试技能之外还编写代码的测试人员比非技术人员更有效。

与没有这些技能的情况相比，技术测试人员基本上可以为测试问题带来更多的“武器”。一些例子：

• 需要生成一些测试数据？写一个工具来做。

• 以特定用户身份登录时需要检查安全访问权限吗？写一些自动化来做到这一点。

• 需要自动部署您的应用程序？为此编写一些脚本。

• 需要影响开发人员执行单元测试的方式吗？向他们展示如何或为他们构建单元测试框架。

• 需要执行白盒测试吗？你有能力检查代码并开始阅读。

但是，请注意。可以编码的测试人员很容易只想编码。作为 QA 开发人员的真正技能是知道何时适合开发以及何时放下工具并手动对其进行测试。

我已经成功使用测试人员/开发人员对生产代码进行代码审查。我发现开发人员审查代码时会思考“这行得通吗”，而测试人员审查代码时会思考“这在哪些方面行不通”。我还发现大多数测试人员在审查生产代码时会发现新的测试想法。

我写了一篇关于我们团队在这方面的经验的论文。

甚至在编码开始之前，测试人员就可以通过做出/影响关键软件设计选择来为产品和开发团队增加价值。

具有编程背景的测试人员可以理解和探索可能的软件设计选择，以获得更好的代码可测试性，并且他们可以确定“代码是否适合使用？” 像“依赖注入”和“解耦”这样的设计选择可以使代码足够健壮和灵活，以吸收未来客户需求的变化。

具有大量依赖项的代码违反了“得墨忒耳法则”或好莱坞原则。使用依赖注入，代码变得松散耦合，这里有一篇文章解释了测试自动化如何与此相关联。