一． 我们没有已经部署的环境，其他团队会做这件事情

你星期一早上来办公室。您注意到生成拦截器有几个问题。您需要从构建存储库构建新版本。您提出请求或联系您的开发团队或部署团队。哦，他们都在忙些其他的事情。但他们在一段时间后就可以做到了。

现在告诉我，为什么会这样？它并不像看上去那么复杂。当采取新的构建时，开发人员肯定肯定可以修复好。但是，当您只需触发并部署它时，为什么要等待或依赖某个人呢？

有能力和权限随时部署，使您的工作更容易，没有任何等待。你看到了吗？它也会增加你每天测试的周转时间。尽管它正在使用添加的记录器调试某些缺陷，或者使用新的构建来验证已解决的错误。或者是进行新的构建并开始测试新特性。

让我告诉你一些我的亲身经历。这不仅仅是关于时间的问题。部署教给你很多你无法想象的东西。原因是，它经常失败。应用程序有时停止使用新代码。很多时候部署本身失败。每次失败时，它都会促使你调试它。它促使你在谷歌上搜索或者问某人一个问题或者最好问自己一个问题。

它让你思考。

当然，这不是一个真正的软件测试，但它肯定是测试你的能力。

我要说，除了纯软件测试之外，我学习的很大一部分来自于环境的部署和维护。

我不记得我为某事做了多少次尝试和错误尝试，计数必须是几百。

我不记得有多少次我去检查一些软件的发布手册。

我不记得我打了多少次谷歌搜索按钮，或者导航到那个堆栈溢出链接。

我所知道的是它给了我很多，教会了我很多。

补救办法与我们所说的第一个借口很相似。

学习它，展示它并向它索取。可能会起作用

我不会很努力地做这件事，因为在面试中，你每次都没有机会讨论候选人自己的经验和调查/调试所造成的特殊缺陷。

二． 我们不需要调试问题，只需要找到步骤并进行日志记录就可以

然而，我可以肯定地说，不是所有的人在向开发者传递缺陷之前都要挑战自己的感官。

很多时候日志都说明了这一切。很多时候，一个问题的模式说明了一切。很多时候它失败了，因为一些必要的服务失败了。

简言之，很多时候我们确实有可能找到确切的根本原因，或者至少能接近它。

因此，请问自己几个问题，不是为了帮助开发人员，而是为了使测试周期快速，为了自己的成长。

你是这里的补救办法。没有其他人。