我们目前在保险理赔处理领域中工作,尽管说实话,即使从质量上讲,从我们管理层的高层位置来看,总体而言,测试和质量保证始终都是支持的非关键机制。

但是,我一直想知道,对于危急关头的关键问题,如航空,航天工程,医疗保健,核电站软件,进行测试和质量保证会是什么样子。

错误的代价非常高-我们都可以记住由软件引起的著名案例:Therac 25事件或最近的Schiaparelli Mars着陆器坠毁-造成人员伤亡和生命损失对许多人的工作,金钱损失和更多负面影响。

如何知道您的被测产品可能会导致严重的后果,从而影响测试人员及其工作?参加高风险测试感觉如何?

评论

感谢您链接到Therac。在80年代,RAM非常昂贵,但即便如此,这样的结果性应用也不应该在汇编中开发。这样有限的计算机可以实现高质量的开发:考虑Voyager于1977年推出并仍然保持强劲发展-知道如何操作它的人不到十,而且他们都已经退休了。但是当然它并不便宜。我们有高级语言是有原因的。 Ada是用于要求高质量的系统的此类语言之一。

@PeterMasiar哦,是的,旅行者号取得了巨大的成功,就贡献的科学和知识而言,可能是最成功的任务。已经过去40年了,而且还在继续,简直太神奇了。令人惊奇的是,我们如何在地球上发展我们的技术,以便能够捕捉旅行者的信号。我毫不犹豫地说,在40年前,在这样的规模上这是真实的和可能的。谢谢。

#1 楼


知道被测产品可能会导致严重后果的方法如何影响测试人员及其工作?参与高风险测试的感觉如何?


我的测试软件可以处理外科器械的无菌处理。尽管我们的软件不直接负责灭菌,但它负责在灭菌过程中跟踪仪器。因此,虫子有可能间接影响患者。经理)。

但是,当我接近可以直接干扰人们生活的软件时,就像我测试HL7订购功能时一样...

...什么都没有真的有很大不同。

神经质是测试的一部分。我并不是说坐在那里咬指甲,然后在晚上失去睡眠,因为您的测试可能会或可能不会带来悲剧性后果。我的意思是说,我试图在较小的范围内紧张,我正在测试的内容不起作用。少量的紧张足以使我保持警惕,而不会误导“一切都很好!”幻想。

如果我陷入即将来临的厄运阴影中,我会退后一步,向自己保证,如果我使自己(大部分),保持镇定(大部分),就可以做得很好。测试任务的思维框架。

让软件具有关键性对您进行元测试决策很有帮助(此bug至关重要吗?哪个功能是优先级?我的测试是完成吗?),但是我发现即时测试活动对此没有影响。

实际上,对某事进行良好测试的感觉有时是应对责任带来的压力的最佳补救措施!以前,我无情地追求一个躲避错误的bug时,我对释放的影响感到不安和担忧。与我一起工作的其他人的看法可能有所不同。我看到人们在紧张的时刻变得非常紧张,但是我想提醒他们,紧张不会解决bug。

良好的测试会。

评论


很好的答案,特别感谢您谈论测试人员在压力和压力下的感受!

– alecxe♦
17年5月5日在15:12

#2 楼

此类领域通常受到监管。

在某些此类行业中,存在外部法规,这些法规要求一定的流程到位,不仅用于测试,还用于其余的开发周期。我在美国受FDA监管的医疗设备行业工作。 FDA根据风险级别将医疗设备分为三个“类别”:I类,II类和III类,其中III类设备是具有最高风险的植入物之类的东西。

FDA要求的东西类型(如果经过审核,则必须提供书面证据)是:


除代码外,还审查设计工件(例如要求和测试)
测试需求的可追溯性(对于更高级别的产品,可追溯性还必须扩展到设计和代码中)
进行的测试的客观证据
所使用的任何第三方软件的验证
对于涉及硬件的产品,请确保对可用于生产的硬件进行最终测试,而不是对早期的原型进行测试。

还有更多,但我绝不是专家,作为开发人员,我们开展业务基于我们的监管和法律团队根据FDA指南得出的内部程序,因此我不会太详细请花费大量时间阅读FDA的实际法律用语。

如果您想了解更多详细信息,可以参考一些资源,尽管还有很多事情要经过:


医疗器械分类和重新分类概述
CFR-联邦法规标题21


我不确定法规要求什么,但是对于现场产品中发现的缺陷,无论是客户还是产品出厂后的内部团队,我们也有严格的要求。如果任何员工发现或听到客户的缺陷,则要求他们在短时间内将其输入系统。如果是导致或可能造成伤害的缺陷,则很可能会导致“停船”,召回或现场更新。


我在这种环境下的工作经验

我刚从学校毕业,就读过Therac事件,而我不想从事的领域是医疗器械。好吧,我在这里。虽然我没有使用过任何III类设备,但老实说,它并没有我想象的那么恐怖。法规虽然有时需要比看起来必要的更多的文书工作和流程,但大多数情况下还是需要有好主意和常识的事物。我有幸与一支非常优秀的团队合作,他们甚至在开始制造临床设备之前就致力于质量。我相信,团队的承诺是真正实现质量的最大因素。我们庆祝发现错误(因为我们发现并修复的每个错误都不会对客户或患者造成伤害),但是诸如代码审查,设计审查,结对编程等实践可帮助防止许多缺陷,而我们甚至不必在测试中找到它们。

当我在这家公司实习时,我曾经在硬件上进行了一个通宵的实验,我的经理在早上走过,发现了一次相当壮观的车祸的遗迹。当我进来时,我收到他的即时消息,说:“所以我想我现在可以称呼您为认证的<产品名称>工程师:)”。事实证明,我的简单实验发现了导致崩溃的固件错误,然后几个经验丰富的开发人员帮助我进行了调查。从本质上来说,我为自己的第一次撞车感到祝贺,而不是受到指责或责骂,这无疑给人留下了深刻的印象。无责备的环境减轻了很多压力,尤其是在风险和风险很高的情况下。但是,这样的规定将增加滥用权力的机会。我们所谓的“质量”小组实际上更多地是关于法规遵从性:他们正在查看我们是否已准备好所有文档,并确保我们的测试符合法规,而不是进行实际测试。由于没有适当的文档我们无法交付产品,因此该组实际上是网守。但是,由于许多实际法规规定的是“什么”而不是“如何”,因此对于分配给您的特定项目的质量人员来说,通常还有很多事情要做。虽然我亲自与之合作的每个优质人员都非常合理并且可以与他人合作,但我听到了有关公司其他部门的恐怖故事,例如文档因使用错误的字体而被拒绝,声称文档缺少必需的信息而没有提供详细信息关于该信息应该是什么,等等。

在这种情况下,工程师必须经常深入实际的法规中,以了解实际要求是什么,而不是您要处理的特定质量人员的一时兴致。否则,“合规”或“政策”卡每次都会胜过“常识”卡。

此外,如果您未通过FDA等监管机构的审核,则公司可能必须修复”工作需要额外的过程,而实际的开发人员和测试人员对于有效的修复与繁忙的工作可能没有什么发言权,忙碌的工作会使您的过程看起来更好,而实际上并未提高质量。

评论


这很好地反映了我在航空业的经验。

– Ruther Rendommeleigh
18年4月20日在12:18

#3 楼

我从来没有参加过这样的测试,但是我认为对生命至关重要的系统是按照高模块化,自我诊断,组件功能重复以及组件接口形式化的高水平设计的。 >
我怀疑当测试人员测试某些特定组件时,他们甚至可能不知道该组件将参与什么E2E案例以及该组件将被整合到什么“整体”中(或至少只是一个猜测)。因此,我认为测试人员不会像在登录表单测试中那样付出更多或更少的精力。此外,我相信测试的大部分是在没有人工参与的情况下进行的,而在部分测试中,并不是由不同的团队和人员对组件进行多次测试,以最大程度地减少人为因素,并使人们在可能丢失的方面感到自在缺陷(因为他们知道此功能将被其他人重新测试)。.

在这样的系统中进行功能测试应该与我们都知道并喜欢(讨厌)的功能相差无几。但我认为,大多数测试和开发资源都用于系统设计和架构(例如设计汽车)以及最终的e2e测试(例如在碰撞测试中摧毁多辆汽车,或在展位上行驶100000公里) )或组件集成测试级别(例如测试方向盘是否与车轮牢固连接)。

基本上,所有内容都应与常规测试中的类似,但更正式,标准化且昂贵。

#4 楼

最终,这就是您一天结束时的感觉,以及您是否可以在晚上睡觉。我曾与许多测试过医疗(1级至III级)和武器系统的人一起工作过。这取决于您管理责任感的程度。请记住,质量检查只是TEAM的一部分,并且合法地遗漏了一些未被认为不是您的责任的事情,至少是一个人。一路都有博士和医生也应该做他们的工作。您应该无缺陷地运行测试,保持完整性并提出问题。

#5 楼

老实说,这是一个管理问题。

我测试了企业操作系统;我承认,它不是在起搏器控制软件的水平上,如果发生问题,个人可能会丧命,而在公司倒闭/人们失去毕生积蓄的水平上,等等。而且由于它支持地球上几乎所有的财务交易,许多航空公司的运营以及其他类似的交易,因此总的来说,还有一些表现不佳的事情导致许多人花了很多时间等待,而不必等待。

正如Alexey所说,在很多方面,它与任何其他软件的开发/测试都没有什么不同,但是我们确实付出了更多的努力。 “足够好”实际上不是一个选择。我们要么必须做对,要么根本不提供产品/功能。因此,设计必须定期重新启动的产品不是我们要做的。我们花费大量时间设计和测试错误检测和恢复处理;在许多组件中,用于错误恢复路径的代码比基本功能更多,并且我们的很多测试都是在测试错误条件,而不是快乐的路径。

我们还必须花费更多的时间/资源测试在系统级别;我们最近注意到的一件事是,由于硬件和软件的弹性如此之大,因此引发问题的风暴非常完美。实际上这是一个问题。该系统非常可靠,以至于当出现问题时,最终用户都不知道该怎么做,因为他们可能多年都没有遇到过故障。因此,我们还引入了更多的主动式系统监视/响应功能,因为我们不能相信很多最终用户会做正确的事情。

但是从某种程度上说,这是企业愿意花多少钱的问题。就像我说的,我们现在注意到,要导致实际的系统故障需要花费很多事情才能出错,并且经过一定程度的复杂性之后,您无法测试所有可能出错的组合。逐步获得更可靠的系统会成倍增加成本。

,正如其他人所说,也有法规要处理。我们必须确保可以证明我们在必要时已经对某些事物进行了测试。

在日常工作中,我认为与其他任何测试人员都没有什么不同;当我无法重现问题时,我会感到沮丧,追踪难以发现的错误会给我带来极大的快乐,并且我担心会发生转义。但是,当我认为某些事情需要更多测试时,我也会比其他领域更努力地退缩,而且我总是担心如果听说ATM网络中断或类似情况是否要负责。

评论


真的很喜欢这个答案,这是一个很好的课题-尤其是像这样的问题:更关注测试失败条件而不是幸福的道路。非常感谢。

– alecxe♦
17年9月12日在22:41

#6 楼

它需要对细节有更多的关注,尊重流程,并且不怕说话。我已经完成了飞机维护并仔细检查了一切,同时又收获又恐怖,因为我知道这将使内部人员受阻,而您的工作也有所作为。