一段时间内，我从上千个面试者中聘用大约100名测试员，从这段面试经历中我揭开了一种模式。在采访中，我和同行的测试人员进行了多次讨论，我非常高兴地看到了我们的测试员群体中的高素质人才。
但让我也分享故事的另一面，我所谈论的模式也让我很伤心。看着潜在的表演者被关进一个虚拟的责任笼里，我永远不会感到高兴。看到摇滚明星在受控制的舞台上表演，我感到不满。
如果你还不知道什么是问题，什么是基线，这是我们测试界相当大的一部分问题，在他们作为测试人员开始他们的职业生涯多年之后，在多个方面都没有足够的增长。忘记360度，甚至不到一半。
对不起，这是残酷的，但它是真实的。
这是谁的责任？也许在某种程度上是整个行业的意识。也有可能事公司政策和高级管理人员。但最重要的是测试人员自己。
再看一遍，是你。是我们。因为我们成了借口的牺牲品。
下面是我发现的几种模式/借口
注：我并不是说每一个测试人员和每一个组织都有这种情况。但我已经看到足够多的例子来说明我们大多数人都是受害者。
一．我们不能控制我们的测试环境，我们只有只读的访问权限
我经常听到这样的说法/借口--"我们只有只读的访问权限。"甚至最糟糕的情况是"我们只能访问日志，其他的什么都不行"。其他一切都是由开发团队或其他团队完成的。
这项工作将给我们提供许多关于测试和许多其他技术方面的美丽而富有成果的见解，而这些工作并不是由我们来完成的。也许我们很高兴，但我们不应该这样。告诉我你没有控制你的测试环境并最大程度地从中受益的原因是什么？
如果你对上面我说的感到好奇，可能会从中获得益处
1.您可以完全控制测试环境，以确保它是精确的或接近生产环境的副本。这将有助于你避免意想不到的惊喜，至少当你的项目交付物命中产品时。
2.您知道所有涉及的组件，以及用于产品功能的所有软件版本。随着时间的推移，相信我，你会对他们的工作，局限性和可能的失败点有很多的见解。
3.您有足够的访问权限进行至少一级调试，以防出现底层问题。例如：运行缓慢、检查CPU、内存利用率和每一级流量的日志都不是火箭科学。
4.您拥有对安装的控制权，因此您知道您正在更改什么，以及正在部署什么样的构建。在发布发布之前，您比以前更加自信了。
有道理吗？如果你至少同意有好处的话继续往下看
现在的问题是你能在你的团队/组织中做出什么样的改变来完成这项工作。你会怎么做呢？。
嗯，我不知道。我不知道你们的团队，你们的领导/经理，你们的组织，所以我不能帮你们解决这个问题。我当然可以分享一些可能有用的东西。你试着和你的开发人员或者任何一个拥有这个技能的团队紧密合作，看看他们做什么和怎么做。
他们的方式登录到环境（服务器），他们的方式注销和之间的一切。一旦你获得了一些知识，你就有信心说几句话，在类似的情况再次发生或类似的活动再次发生时给出一些建议。
很显然，你的开发人员/领导/经理迟早会看到你的自信。这是你可以要求控制的时候了。告诉我为什么他们不给你一个有力的理由？如果您已经显示了所需的功能，他们应该非常乐意这样做。
相信我，他们还有很多工作要做，所以他们不难把控制权释放给你。至少我希望如此。
二．我们没有已经部署的环境，其他团队会做这件事情
你星期一早上来办公室。您注意到生成拦截器有几个问题。您需要从构建存储库构建新版本。您提出请求或联系您的开发团队或部署团队。哦，他们都在忙些其他的事情。但他们在一段时间后就可以做到了。
现在告诉我，为什么会这样？它并不像看上去那么复杂。当采取新的构建时，开发人员肯定肯定可以修复好。但是，当您只需触发并部署它时，为什么要等待或依赖某个人呢？
有能力和权限随时部署，使您的工作更容易，没有任何等待。你看到了吗？它也会增加你每天测试的周转时间。尽管它正在使用添加的记录器调试某些缺陷，或者使用新的构建来验证已解决的错误。或者是进行新的构建并开始测试新特性。
让我告诉你一些我的亲身经历。这不仅仅是关于时间的问题。部署教给你很多你无法想象的东西。原因是，它经常失败。应用程序有时停止使用新代码。很多时候部署本身失败。每次失败时，它都会促使你调试它。它促使你在谷歌上搜索或者问某人一个问题或者最好问自己一个问题。
它让你思考。
当然，这不是一个真正的软件测试，但它肯定是测试你的能力。
我要说，除了纯软件测试之外，我学习的很大一部分来自于环境的部署和维护。
我不记得我为某事做了多少次尝试和错误尝试，计数必须是几百。
我不记得有多少次我去检查一些软件的发布手册。
我不记得我打了多少次谷歌搜索按钮，或者导航到那个堆栈溢出链接。
我所知道的是它给了我很多，教会了我很多。
补救办法与我们所说的第一个借口很相似。
学习它，展示它并向它索取。可能会起作用
我不会很努力地做这件事，因为在面试中，你每次都没有机会讨论候选人自己的经验和调查/调试所造成的特殊缺陷。
三．我们不需要调试问题，只需要找到步骤并进行日志记录就可以
然而，我可以肯定地说，不是所有的人在向开发者传递缺陷之前都要挑战自己的感官。
很多时候日志都说明了这一切。很多时候，一个问题的模式说明了一切。很多时候它失败了，因为一些必要的服务失败了。
简言之，很多时候我们确实有可能找到确切的根本原因，或者至少能接近它。
因此，请问自己几个问题，不是为了帮助开发人员，而是为了使测试周期快速，为了自己的成长。
你是这里的补救办法。没有其他人。
四．我不知道它为什么会发生，开发人员解决它，我只是验证它
哦，来吧。对不起，听到这个让我很烦。
每一次，当我问测试员一个问题时，我都会很恼火--为什么要面对特定的缺陷，什么是RCA（根本原因分析），而他/她会回答"我不知道"。
我们真的用黑盒这个词吗？我们怎么能不向开发者询问他到底修复了什么呢？为什么我们不能问权威是不是一个问题？
我敢肯定，99%次我们不知道根本原因分析（RCA）或修复，因为我们不要求它。
相信我，知道确切的修复，修复的模块，无论是在前端还是后端，无论是注入任何功能开发还是其他缺陷的修复，都会对你的测试有所帮助。
除此之外，这些信息有助于你了解许多技术性的东西，否则你将永远不会遇到。
补救？问它，需求它，如何工作
五．除了手工测试之外，我没有其他机会做其他工作
考虑到你可能的工作量或责任限制，也许这个借口在一定程度上是有效的，但并不完全有效。
这里的问题是，我们说我们没有机会执行非功能性的测试，或者我们不应该这样做，或者我们没有时间。
同意，学习总是需要时间。但是你没有什么可以改变的吗？
在测试该新特性或测试该API时，
你不可能一直盯着响应时间吗？
难道您不可能向您的业务分析师询问该特性/模块/ API在生产中需要处理的负载，以便您能够测试它吗？
有没有可能至少执行基本的安全检查像过期，URL篡改或XSS攻击，网站形式你应该测试处理？
是不是至少可以说，这个特定的"提交"或"帮助"按钮似乎不太合适或不容易察觉，并发挥你的小作用，使产品更容易使用？
你难道不能从一件事开始，然后不断地学习吗？
答案是肯定的，小的或大的取决于周围的各种因素，但肯定不是。如果你的职责不要求它（因为还有其他团队），没有人会阻止你为自己的学习投入额外的时间。我认为在课外或业余时间自学是可能的。所以找到那些可能的额外因素，现在然后开始做。
六．结论
我希望我在你心中引发了一些思考过程和学习的野心。
请原谅，如果你发现我的话刺耳，但相信我，我只想让大家100%清楚、意识到自己问题的严重性。
希望它对你们大家都有积极的作用。
版权声明：本文出自《51测试天地》原创测试文章系列（四十七）投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
相关推荐：
