为什么QA没赶上?

自然,质量保证(QA)在整个发布周期中会产生很多缺陷。 质量检查不是应用程序的看门人吗? 如果客户发布后发现错误,那么许多人会首先寻求该团队的支持。 如果错误继续出现,则可以对测试(从手动测试用例到自动化测试)进行审查,并且会出现与团队经验水平有关的问题。

这些情况多久出现一次以及如何处理,可以揭示团队的很多过程。 如果错误始终通过测试,那么可能是时候退后一步,挖掘潜在的根本原因了。

那么为什么QA无法捕获所有错误呢? 这可能会发生一些事情:

首先要看的是测试过程本身。 也许工作流中有一个关键步骤丢失了,需要纳入。 例如,质量检查仅测试单个功能分支吗? 测试的一个关键方面涉及查看这些单个功能一旦发布便会如何相互交互。 这也是QA可以在客户访问系统之前刷新系统中的回归的地方。

那么工作流程中是否缺少集成环境或测试阶段? 如果是这样,那么可能是时候讨论扩展新环境以部署将成为发布候选版的功能集了。

故事有助于定义开发以及应测试的内容。 如果功能的接受标准集不完整,则测试中会遗漏任何东西。 如果没有定义权限级别,或者团队对应用程序不熟悉,则从权限级别到预期的通知消息的任何内容都可以忽略。

与整个团队一起确定什么是完整的故事,并在讨论中加入质量检查。 拥有明确定义的接受标准将帮助他们制定最佳的行动计划,以便在发布之前进行全面测试。

有时,由于团队不熟悉所使用的应用程序,所以一个错误使它无法通过测试。知识随着时间和经验的增长而增长,但是有一些方法可以帮助所有人(不仅是质量检查人员)与此同时。

对于新功能,演示或培训对整个团队都非常有用。 这使从项目经理到客户支持的每个人都有机会了解计划发布的内容。 知识共享使每个团队之间的沟通渠道保持开放,并有助于确保不创建孤岛。

如果由于缺乏知识而在发布后发现错误,请将其记录在易于访问的地方,并与团队分享。 将其转化为学习机会。

可以预见的是优先级会发生变化,尤其是在敏捷环境中。 优先顺序的变化并不一定表示进程不健康。 如果他们经常发生,那么他们实际上会更分散注意力,并且可能使整个团队的节奏失去动力,包括测试。

这些优先事项的不健康变化是什么样的? 对功能的最新更改,需要在下一发行版中合并的新功能(可能只有一天的时间)以及范围爬升是一些常见的功能。 QA无法彻底测试优先级是否在没有充分沟通的情况下不断变化,或者在发布前没有足够的时间。

重要的是要保护与开发新功能和候选产品有关的所有人,使其免受这些干扰和更改的影响。
在测试中遗漏某些东西是有原因的。 应用程序的运行状况和稳定性并不取决于任何团队,因此,如果发布后弹出许多错误,请查看当前流程,并努力发现并修复发现的任何差距。

您发现哪些导致漏洞丢失的漏洞?如何解决? 让我们在评论中知道!

*最初发布在 https://moduscreate.com/why-didnt-qa-catch-this-a-look-at-broken-processes/