应该仅将软件测试人员归咎于严重的生产缺陷吗？

#1 楼

感到内并不能帮助您的公司发布更高质量的软件。不用感到内，而是将那些逃脱的缺陷用作您接下来可以学习的内容的信号。 。如果您在工作中找不到导师，则可以尝试在工作之外寻找，例如在聚会上。如果这两种选择都不可行，请考虑转到其他工作，在那里您有更好的机会向他人学习。

#2 楼

直接回答您的问题：不，发布后发现的（严重）缺陷并非仅是测试人员的错！任何认为这种方式的公司都是我会尽快离开的公司。

话虽如此：改善您的测试并共享已测试和未测试的内容是交流实际内容的第一步。在测试时完成。在我看来，确定应用程序是否准备好发布应该基于适当的信息，这不是测试人员的责任。

但是，仅检查快乐的路径通常并不是真正令人满意的方法。更改是开发人员已经尝试过的。因此，您的工作是尝试思考程序可能失败的方式。有什么地方会出错，使用起来会是一个真正的问题？这一切都取决于您的情况。理想情况下，并且我在敏捷的环境中工作，您作为测试人员属于开发应用程序的团队的一部分，因此，确保（并应该）共同努力确保一切正常！

继续阅读！像这样的博客Michael Bolton-“测试就是”。并查看James Bach的博客，还有更多资源。
尝试使用“测试”备忘单来指导您的思考。我经常使用启发式测试策略模型-HTSM创建可能需要关注的模型。

有活跃的测试社区，例如测试部，我认为自己是上下文驱动社区的一部分。存在在线课程，网站上有要测试的示例，例如帮助提高技能的测试难题。

去学习和改进。不要感到内。如果您对错误采取行动并从中汲取教训，那么错误可能是变相的祝福。祝你好运！

#3 楼

自80年代末以来，我从事该行业已经很长时间了，我还记得我很早就听说过的一件事：“您无法对必须内置的软件进行质量测试。”那时我还年轻，我的第一任老板是老派（大概和我现在一样大：-）当时虽然没有多大意义，但是随着岁月的流逝，这才变得有意义。他的意思是，这是一个完成软件项目的过程。每个人都与质量息息相关。这绝不能使您错过重大的事情，坦率地说，这在当今时代是不应该发生的。过去，我们没有通过诸如此类的板触手可及的答案，也没有尝试并尝试过真正的开源测试工具。幸福的道路甚至不是等式的1/10。平台，边缘，边界，压力，性能，我可以走了，但您明白了。请记住，您正在构建软件应用程序，我已经看到团队陷入了文档的泥潭，在一定程度上让该应用程序成为您的文档。即使只是登陆页面，也要在每次会议上都打开该应用程序，请记住这就是您正在开发的内容。对于您当前的情况，最好的办法是与团队（如果可能的话）对整个团队进行“同行审查”您的测试用例。我记得的另一个陈词滥调是“每个人都是卑鄙的人，总的来说我们是天才。”团队协作时产生的协同作用是一件很棒的事情，最终会带来更好的应用程序。那些为“团队建设”付出高昂金钱的人无法接近那种感觉。然后在门口检查你的自我<<<这可能是最重要的。每个人都与质量息息相关，每个人都应参与该过程。

#4 楼

您应该改进设计测试过程的方式。首先，您应该制定一种测试策略，在其中尽可能写下整个测试过程。然后，您应该使用整个工具箱，等效类，决策表，状态图准备测试用例，并确保测试任何关键输入。如果您不知道这些概念中的任何一个，我只能建议您阅读ISTQB基础级别的课程表。

当您拥有所有测试用例以及编写的一般工作流程时，您可以去让它由管理层签名，理想情况下是与开发人员开会，他们通常会知道开发人员最容易受到攻击的地方在哪里。他们的软件。之后，您只需要遵循测试文档，并且如果仍然存在一些缺陷，您就知道您已经测试了所有可行的方法，并且您，管理人员或开发人员都不再考虑任何情况。

您会为自己的应用程序开发一个直觉，许多正式步骤会变得更加自然，但尤其是在开始写下您的方法并获得意见时，这是非常宝贵的。

#5 楼

您是否已回头并回顾了所遗漏的缺陷？
以错误为契机，学习和改进前进的方向。

如果这是走错路的话，那么您会认识新的领域需要测试吗？还是UAT测试人员拥有了您没有的其他数据，这些数据显示了您无法利用测试数据捕获的问题？您是否已全面了解更改和更改的代码，以便了解所有查找的地方？您需要有关该应用程序的其他培训吗？

答案可能不同，需要多种解决方案。选择一个并开始，然后从那里继续改进。

#6 楼

好吧，在我看来，每当生产中发生一些不幸事故时，都不能责怪质量保证。当在生产环境中观察到任何问题但在质量保证或分期中未发现任何问题时，许多因素都会起作用。

像



这样的因素是环境设置
基础设施有所不同，例如QA或Staging在内部，生产在云中。
某些存储过程DBA忘记作为Release的一部分执行。
部署不正确。
/>其他集成系统的行为不正常或无法提供适当的响应。

如前所述，您只关注快乐的道路，然后就应该归咎于质量检查，因为质量检查有责任覆盖所有可能的道路，因此下次您最好涵盖所有可能的方案/路径，这将帮助您减少生产问题。

#7 楼

顶级软件测试公司遵循系统的方法来提供高质量的产品。
以下是对您交付无错误产品有益的一些要点。


应该分析Dev / PM团队提供的用户案例，并创建现实的估计结果
应该为sprint中涵盖的所有案例创建测试用例（假设遵循敏捷）。
或在执行回归测试时应彻底测试可能受影响的区域
一旦对所有案例进行了测试，则应进行集成测试以验证所有功能均已同步
如果可能，应运行所有测试用例交叉检查所有已实现的功能，如果没有，则至少应运行健全性测试用例

#8 楼

我能理解在生产中遇到的一些内a感。但是，我个人觉得产品的整体质量不应该由单个质量检查人员来负责，而应该由整个团队来负责。许多“左移”方法解决了这一问题。

我们已经完成的一些事情：


使所有工作小而安全（因为可能）。
使用功能标记
BA，QA和SE都同意基本的接受标准，然后再开始工作开发工作
切换到基于主干的开发

来自所有利益相关者。
祝你好运。

#9 楼

我认为绰号“质量保证”的核心是误导性的。我不能真正保证只有质量代码能比其他任何人都可以确保没有任何缺陷。对此的极端看法是，我根本没有编写任何缺陷，因为我一般不会编写代码-但这对组织环境都没有帮助。

我喜欢认为我是质量协助人员（我从Atlassian偷偷地偷走了这个角色），因为我在那里确定风险并减轻任何重大故障，但是质量确实是所有团队成员的责任。 ，提出一些棘手的问题，并寻求我认为值得提倡的最终用户应得的答案。

不要让重大缺陷使您失望-这是我们最好的，并且任何人都无法保证完美。

#10 楼

我是质量检查工程师，主要负责测试薪水表所描述的功能。



质量检查所描述的质量工程师（在Google搜索中排在首位？ ??）
质量保证（QA）工程师的职位描述。质量保证工程师创建测试，以在产品发布之前发现软件中的任何问题。


我错过了过去构建中的一些关键缺陷，并让这些缺陷在生产中溜走了环境。客户报告了许多严重的问题，而所有的责任都间接地归咎于我。

我认为我的方法不好，我只是在测试幸福的道路。我
不要用开箱即用的思维。


因此，按照定义，创建测试以发现任何问题。正如您提到的（突出显示）那样，这些问题是关键问题，是的，您的团队将责怪您为什么错过了该关键错误。我认为这些是我在测试时要考虑的一些事情


您需要完全了解该软件才能知道哪一部分是关键的而哪一部分不是关键的。您应该比开发人员更了解您的软件。
该软件的哪个部分最有可能被使用，而不是
您的测试用例应包括否定测试。幸福的道路并不总是导致幸福的部署。我认为这是您应该改进的部分。如果有漏洞，您自己呢？然后改善您的测试用例。扩展您的测试用例。
总是想到Edge Cases。为什么？如果您习惯于考虑边界/边缘情况，那么您很可能会发现开发人员和其他人认为不会发生的错误以及您提到的所有关键错误。这也将有助于开发人员在知道您进行了此类测试的情况下正确地测试其工作。
总是向您的团队（PO，PM，设计和开发人员）询问您不了解的功能。
这个按钮有什么作用？为什么会这样呢？关于上述内容，请始终向您提出以下要求！这将帮助您获得更多知识，并了解为什么某些功能会失败。当然，从长远来看，您将知道如何使其失败。
您的测试环境是您的。在Test envi中需求您所需的东西。
不要相信开发人员。 “我会说这行不通”。
最后，我认为大多数失败的事情。不要以开发人员的身份考虑。认为是用户。如果您要测试软件一段时间，则会像正在测试的开发人员一样制定规范。没有！始终以用户身份进行测试。

#11 楼

仅阅读您的问题，任何缺陷都不应归咎于任何人。
必须有一个持续改进的过程，并且必须予以强制遵守。
一旦将其严格地放在适当的位置，就不会有任何自责。

#12 楼

答案取决于。

诚然，如果客户发现问题，因为测试员是公司级别的最终用户，就会责怪测试员。但是，团队应该明白单元测试在测试中起着不可或缺的作用。如果开发人员根据场景执行适当的单元测试并向测试人员说明流程，测试团队将基于此设计测试用例，这将有助于测试人员理解产品并认为是开箱即用。

这是团队负责人或项目经理的工作，以检查测试是否完成