主题 3.7 — 测试与质量保证

一句话概括: 在医疗与照护领域,测试与质量保证不是你在发布之前所做的一个阶段,而是一门持续的学科,它提供了证明一项服务在临床上安全、具无障碍性、安全、且适合触及患者照护的大部分证据。

为什么这在医疗与照护领域很重要#

每一项数字服务都携带着缺陷;唯一的问题是有多少、有多严重,以及你是在一位患者受到影响之前还是之后发现它们。在一款消费应用中,一个未被发现的错误会浪费用户一个下午的时间。在一个临床系统中,它可能显示错误患者的过敏史、把一个儿科用药剂量四舍五入错误,或悄悄地把一份转诊丢进一个没有人监控的队列。测试是有组织地及早发现这些缺陷的努力,质量保证则是更广泛的管控体系,防止质量依赖于运气或英雄主义。

这就是为什么医疗 IT 中的测试与临床安全密不可分。DCB0129/0160 危害日志(见主题 1.6——临床安全与风险管理)中记录的危害,只有在一次测试证明这项缓解措施有效、并在此后的每一次变更之后依然有效时,才算是真正被缓解了。一份声称"系统能防止重复处方"、却没有一次可重复测试支撑的安全论证,只是一种断言,而不是一种保证。测试是临床安全论证之下的证据基础。

利害关系也关乎公平与公众信任。一项从未被对照无障碍标准测试过的服务,会默认排斥残障用户(见主题 1.9——数字包容与无障碍)。一项只用线上患者记录副本测试过的服务,可能造成一次侵蚀 NHS 所依赖信任的数据泄露。而且这笔钱不是小数目:返工一个在线上运营中发现的缺陷,其成本是在设计阶段发现它的许多倍,而一起严重的临床事故,代价远高于两者中的任何一个。测试不足不是一种节省;它是一张被推迟、被放大的账单,有时是以伤害来支付的。

核心概念#

测试 vs 质量保证。 测试是运行一个系统以发现缺陷、确认行为的行动。质量保证是更广泛的一套流程——标准、审查、完成定义、关口——把质量构建进去,而不是在最后才检查出来。测试告诉你这个构建版本是否有效;QA 是你的构建版本为什么通常有效的原因。两者都很重要,而领导者常常资助前者、却忽视后者。

测试金字塔与左移。 一个健康的测试策略,有许多快速、廉价的单元测试(检查单个函数)、较少的集成测试(检查组件能否协同工作),以及少量缓慢、昂贵的端到端测试(检查整个用户旅程)。这座"测试金字塔"让反馈保持快速,维护成本保持可负担。它与左移测试配对——把测试推到生命周期更早的位置,这样缺陷是被廉价地设计消除的,而不是在发布前的一场慌乱中被发现。一座倒置的金字塔(主要是手动端到端测试)速度慢、脆弱,是一个警示信号。

功能性与非功能性测试。 功能测试追问"这个系统做了它应该做的事吗?"——正确的计算、正确的工作流程、正确的数据。非功能测试追问"它表现得有多好?"——性能与负载(当整个信托机构在早上 8 点登录时它是否依然响应迅速?)、安全性(它能被攻破吗?)、可靠性与无障碍性。在医疗与照护领域,非功能性失败往往是最危险的:一个功能上完美无缺、却在一次复苏抢救呼叫中超时的系统,在临床上已经失败了。

回归测试。 回归测试在一次变更之后重新运行既有测试,以确认修复或添加一样东西没有破坏另一样东西。在运行中的临床系统里,这是单一最重要的安全习惯:大多数临床软件事故,并非源于新功能,而是源于悄悄破坏了原本正常行为的变更。一套值得信赖的回归测试套件,正是让你能够在不屏住呼吸的情况下变更一个线上系统的关键。

测试自动化与持续集成。 测试自动化使用软件来可重复地运行测试,这样一整套大型测试套件就能在每一次变更时于几分钟内执行完毕。与持续集成——频繁地合并并自动测试变更——相结合,这把测试从一个偶发事件变成了一张持续的安全网(见主题 3.5——交付生命周期)。自动化不能取代人类的判断;它把人类解放出来,去做机器无法做的探索性测试与临床测试。

验收测试。 验收测试,特别是用户验收测试(UAT),是真实的临床医生与用户在系统上线之前,在他们实际的情境中确认它有效的地方。运营验收测试(OAT)确认这项服务能够被运行、备份与恢复。与真实终端用户一起进行的 UAT,能发现任何开发人员测试都发现不了的工作流程不匹配问题。

测试环境与安全的测试数据。 部署环境是软件运行的系统——通常有开发、测试、预发布与生产几个层级。测试需要类似生产环境的环境,但绝不能随意使用真实的患者数据。安全的做法是使用合成数据(人工生成的)或经过妥善匿名化处理的数据,这样测试一份转诊表格就不会泄露一位真实市民的诊断信息。

质量关口、完成定义与缺陷管理。 完成定义说明"完成"意味着什么(经过测试、具无障碍性、有文档记录、经过安全审查),这样质量就不会逐项功能地被协商。质量关口是一次变更要向前推进必须通过的检查点。缺陷分诊是对已发现缺陷的严重程度与临床影响进行评估、并决定修复什么、何时修复,以及什么可以作为已知问题发布的有纪律的流程。

最佳实践#

1. 构建金字塔,并把测试左移。 投资于一个广泛的、快速的自动化单元与集成测试基础,在每一次变更时运行,这样缺陷能在写出后几分钟内浮现,而不是几周后在 UAT 中才浮现。把缓慢的端到端测试留给少数几个关键旅程——处方、转诊、身份匹配。这让测试变得更便宜、更快,而这正是真正让团队更多地进行测试的原因。

2. 把回归测试当作一项临床安全管控来对待。 在任何变更抵达一个运行中的临床系统之前,一套自动化的回归测试套件必须确认既有的、与安全相关的行为依然有效。把你 DCB0129/0160 危害日志中最高的危害直接映射到具名的回归测试,这样一次会重新引入已知危害的变更会自动导致构建失败。这正是让你能够在不累积无声临床风险的情况下迭代线上系统的机制。

3. 绝不默认使用真实患者数据进行测试。 为测试与预发布环境配置合成数据或经过稳健匿名化处理的数据,并受到与生产环境同样的信息治理与 DPIA 纪律的约束(见主题 1.7——信息治理、数据保护与网络安全)。如果一次具体的测试确实需要类生产数据,把它当作一次受控的例外来对待,有文档记录的合法依据、最小化与审计——而不是当作常规的便利。一个测试数据库依然是一个患者数据库。

4. 像对待功能性要求一样认真地测试非功能性要求。 对照现实的高峰需求——换班交接、周一早晨的登录高峰、一次区域性中断导致流量重新路由——进行性能与负载测试,因为一个在功能上完美无缺、却在负载下变得极其缓慢的临床系统,在最关键的时刻失败了。把安全测试与对照网页内容无障碍指南(WCAG)的无障碍测试,当作常设的、不可选的测试类型。非功能性缺陷很容易被推迟,却在生产环境中被发现时代价高昂。

5. 自动化无障碍测试,然后用真人来验证它。 自动化的 WCAG 检查能在每一次构建时廉价地发现相当一部分问题(缺失的标签、糟糕的对比度、结构),但它们会错过那些对辅助技术真实用户而言最重要的问题。把自动化扫描与使用屏幕阅读器、仅键盘导航与放大功能的人的人工测试配对。无障碍性对公共机构而言是一项法律义务,当被排斥的用户是一位临床医生、或一位正在管理自己照护的患者时,它也是一个临床安全问题。

6. 在现实条件下与真实临床医生一起开展用户验收测试。 安排 UAT 让实际将使用这个系统的人——护士、全科医生、行政人员、药剂师——去执行真实的工作流程,理想情况下是在一个反映病房或诊所的环境中,而不是一间安静的会议室。他们的反馈能捕捉到单元测试无法捕捉的、危险的工作流程不匹配问题(一个在错误时刻显示的警告、一个诱发错误的默认值)。为临床替补时间做预算,这样 UAT 才能被恰当地完成,而不是靠善意挤出来。

7. 让完成定义与质量关口明确并被强制执行。 商定"完成"对你的情境意味着什么——通过测试、无障碍性合规、安全扫描通过、临床安全审查完成、文档已更新——并把它当作一道关口、而不是一种愿望来强制执行。一份被写下、却在截止日期压力下常规被放弃的完成定义,比没有更糟,因为它把不安全的工作洗白成已完成的工作。关口应当尽可能自动化,这样它们就无法被悄悄跳过。

8. 以临床严重程度为先来分诊与管理缺陷。 用你危害日志同样的风险透镜,不仅按技术严重程度,也按临床影响与可能性来评估每一个缺陷。一个外观上的错误可以等待;一个可能导致错误剂量的缺陷,无论上线日期如何,都会阻挡发布。维护一份可见的缺陷登记册,并对作为已被接受、已被缓解的风险(而不是被隐藏的风险)发布的已知问题保持诚实。

9. 把测试整合进交付流水线,而不是放在它之后。 把自动化测试、安全扫描与无障碍检查接入持续集成与交付流水线,这样每一次变更在能够推进之前都会被测试(见主题 3.5——交付生命周期)。这让质量变得持续且廉价,并意味着快速部署一个经过测试的修复的能力——本身就是一项安全管控——始终可用。手动的、项目末端的测试阶段既缓慢又滞后,是时间紧张时第一个被牺牲的东西。

与团队讨论的问题#

1. 如果我们明天在运行中的临床系统里改变一件事,我们有多大信心能在患者之前发现它是否破坏了别的东西? 这个问题检验的是你回归测试的成熟度,以及你安全主张的诚实程度。大多数严重的临床软件事故,不是异乎寻常的新失败,而是回归:一次悄悄破坏了每个人都以为稳定的行为的变更,只有在一位临床医生或患者遇到它时才被发现。一场好的讨论会追溯一次近期的真实变更,直到那些本会捕获一次回归的测试,并追问 DCB0129/0160 危害日志中最高的危害,是否每一个都由一个在危害再次出现时会失败的自动化测试来支撑。值得揭示的张力,是快速发布修复的压力,与证明没有别的东西被破坏这一纪律之间的矛盾——以及你的流水线是让这种证明自动化,还是留给某人凭记忆去检查。考虑你的测试套件运行需要多久,它是否在每一次变更时都运行,以及是否有人为了赶上一个截止日期而悄悄禁用了失败的测试。一个诚实的答案会区分"我们有一套与临床危害挂钩的回归测试套件,并信任它",与"我们测试了我们做的变更,并期望最好的结果"。如果答案是后者,你正在承载着你看不到的临床风险。

2. 我们的测试数据来自哪里?一次测试是否可能暴露一位真实患者的信息? 测试环境是一条常见且常被忽视的数据泄露路径,因为承压的团队会伸手去拿最容易获得的现实数据——一份生产环境的副本——由此产生的患者记录随后就存放在保护较弱的测试系统、笔记本电脑,或供应商环境中。这个问题要求团队把每一个测试与预发布环境追溯到它的数据来源,并诚实地面对"就这一次"复制线上数据是否已经变成了常规做法。值得讨论的取舍是真实性与安全性:合成与匿名化数据更安全,但可能错过真实数据所包含的、混乱的边缘情形,而线上数据虽然真实,却是一项治理与泄露责任,而真正的匿名化比看起来更难,因为记录在被组合时可能被重新识别。具体的切入点包括谁能访问测试环境,测试数据库是否像生产环境一样被加密与审计,以及你的供应商的测试环境是否达到同样的标准。一个有力的答案会描述一种刻意的策略——默认使用合成数据、妥善完成的匿名化、线上数据仅作为一次有文档记录的、最小化的、限时的例外——而不是一场等待信息治理调查的意外。

3. 当上线日期与质量门槛发生冲突时,实际让步的是什么?谁来决定? 每一次交付最终都会面对测试尚未完成、一个缺陷尚未解决,或无障碍合规不完整、而发布日期迫在眉睫的时刻;你的机构在那一刻的行为方式,揭示出质量是一项真正的管控,还是仅仅停留在愿景层面。这个问题要求团队回忆上一次这种情况发生的时刻,并诚实地描述被削减的是什么:是外观上的积压清单,还是回归测试、UAT,或无障碍性审计?这种张力是真实的,不应被轻易挥开——日期确实重要,资金周期毫不留情,无休止的测试本身也可能是一种失败模式——但这个解决方案必须由临床与公平风险来治理,而不是由谁最大声来治理。讨论谁有权在不承担职业风险的情况下,以质量为由叫停一次发布,你的完成定义是否曾被正式放弃、由谁放弃,以及在上线时发布的已知缺陷是被记录为已被接受的风险,还是被悄悄掩盖。一个好的答案会展示一条清晰的、具名的决策路径,一条明确的界线——任何可能导致患者伤害的缺陷,无论日期如何,都会阻挡发布——以及一种说出"还不行,它还不安全"会被奖励、而不是被惩罚的文化。

4. 我们的测试是否真正覆盖了可能伤害患者的事情,还是仅仅覆盖了容易测试的事情? 一个绿色的构建结果只有在其背后的测试真正演练了真实的临床危害时才令人安心,而一个看起来健康的覆盖率数字,建立在一套检查琐碎的 getter 与 setter、却对恶化评分、身份匹配与过敏显示都未经测试的套件之上,这种情况令人不安地常见。这个问题要求团队把测试套件与 DCB0129/0160 危害日志以及风险最高的用户旅程对照起来,逐一危害地追问:"哪一个具名的测试会在这里出错时失败?"张力在于,覆盖率指标奖励的是数量,而不是风险相关性,团队会被诱惑去追逐一个百分比,而不是直面那些尴尬的、难以自动化的情形——边界值、缺失的输入、不寻常的临床组合——恰恰是患者受到伤害的地方。具体的切入点包括审查边界与边缘情形是否被测试,探索性与临床测试(机器无法替代的判断)是否与自动化并存,以及是否有人曾把一次真实事故追溯到一个测试本应捕获的缺口。一个诚实的答案会谈论按风险加权的覆盖率,并能说出守护顶级危害的具体测试,而不是引用一个单一的百分比,仿佛它就是保证。

5. 当我们测试无障碍性时,房间里是有真实的残障用户与真实的临床医生,还是只有一个自动化扫描器? 自动化的 WCAG 检查廉价,应当出现在每一次构建中,但它们只能侦测到真正排斥人的那些障碍中的一小部分,一项服务可能通过每一条自动化规则,却依然无法用屏幕阅读器或仅用键盘使用。这个问题追问你的无障碍性与用户验收测试是否触及了使用辅助技术的真实用户与执行真实工作流程的真实临床医生,还是"我们测试了无障碍性"悄悄地意味着"扫描器显示绿色"。值得揭示的取舍是成本与后勤,与诚实之间的对比:招募辅助技术用户,并为现实的 UAT 补充临床时间,既昂贵又容易被跳过,然而跳过它,正是一项法律义务被违反、以及一个危险的工作流程不匹配——一个在错误时刻出现的警告、一个诱发错误的默认值——抵达一个运行中病房的方式。讨论你邀请了谁、他们的代表性如何、测试是否发生在一个反映诊所的环境中、而不是一间安静的会议室,以及你如何处理他们的发现。一个有力的答案会把自动化检查与残障用户的人工测试及临床医生主导的 UAT 配对,当作常设的、有预算的实践,而不是上线前打个勾的一次性任务。

6. 当一次变更跨越我们系统与别人系统之间的边界时,谁测试这个接合处——我们会知道它是否损坏吗? 现代医疗与照护服务是集成系统的组合体——一个电子病历、一项国家级脊柱服务、一条病理学数据流、一个第三方供应商的模块——而最危险的缺陷,往往不存在于任何单一组件内部,而存在于它们之间的缝隙中,一个接口一侧的变更会悄悄破坏另一侧。这个问题要求团队绘制自己关键的集成,并针对每一个追问:谁拥有端到端的测试,什么样的合成数据流经这个边界,以及一个供应商发布中的破坏性变更会如何在触及患者之前被侦测到。张力在于,没有哪个单一团队感觉自己完全对一个共享接口负责,合同与变更咨询委员会以不同的速度运作,跨机构边界的测试既缓慢又充满政治性,容易被听天由命。具体的切入点包括契约与接口测试、共享测试环境、供应商变更通知是如何被处理的,以及你的回归测试套件是否演练了集成后的旅程(转诊发送、接收、确认),而不仅仅是你自己的那一半。一个诚实的答案会说出谁对每一个接合处负责,并展示一种机制——尽可能自动化——来捕获一次跨边界的回归,而不是假设对方已经处理好了。

实践中:一个医疗与照护案例#

一家急症 NHS 信托机构正在其电子病历中推出一个新的电子观察与早期预警评分(EWS)模块,替代护士记录生命体征、系统计算恶化评分所依据的纸质图表。临床危害是显而易见的:一个错误的评分可能意味着一位病情恶化的患者没有被上报升级。

团队从一开始就构建这座金字塔。单元测试对照国家评分规则检验 EWS 计算,包括边界情形(评分越过上报升级阈值的确切临界点)与棘手的输入(缺失的呼吸频率、正在使用辅助供氧的患者)。集成测试确认评分正确地流向上报升级警报与护理任务清单。一小组端到端测试演练了从床边录入到触发警报的完整旅程。危害日志(DCB0160)中的每一个危害都被映射到具名的测试,整套套件在持续集成流水线中的每一次变更时自动运行。

测试环境用合成患者配置——包括恶化轨迹在内的现实生命体征模式——因此没有任何真实记录会离开生产环境。性能测试模拟了换班交接时的整个病房查房,确认警报在高峰负载下几秒钟内触发。在每一次构建时自动运行、并由一位使用屏幕放大功能的护士手动验证的无障碍性测试,发现了一个低对比度的警报横幅。

在一个试点病房进行的 UAT,由真实护士执行模拟场景,揭示出一个没有任何开发人员发现过的工作流程缺陷:确认对话框出现在评分之后,诱使工作人员反射性地把它关掉。团队重新设计了这个流程,并添加了一个回归测试。在上线时,三个外观上的缺陷作为有文档记录的、已接受的问题发布;两个触及计算的缺陷被修复,并在通过之前阻挡了发布,安全论证直接引用了测试证据。线上运营六个月后,一次对任务清单的常规变更触发了一个回归测试,该测试原本会——如果未被发现——压制一次上报升级警报——在流水线中被捕获,在部署之前被修复,从未抵达一个病房。

行业视角#

初创企业#

一家小型数字医疗公司有从第一天起就把自动化测试与持续集成构建进自己基因的优势,没有遗留的手动测试流程需要解开,能够实现一家大型信托机构会羡慕的快速、安全的迭代。危险在于把测试当作在追逐产品市场契合度时可以推迟的奢侈品,并在没有早期客户尚未要求的非功能性与临床安全测试上省钱。创始人必须记住,DCB0129 义务无论公司规模如何都依附于制造商,因此支撑一项安全主张的回归证据,即使在预收入阶段也不是可选的。合成测试数据也是初创企业的朋友:它避免了在公司尚未具备安全处理真实患者数据的管控措施之前处理真实患者数据的治理负担。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——通常是采购其临床系统、而不是自己构建它们,因此它的测试工作是验收、而不是构建:在员工依赖它之前,确认一位供应商的更新或一次新的集成在真实工作流程中依然安全运作。在几乎没有专门 IT 能力的情况下,现实的纪律是在每一次供应商变更之后,针对风险最高的旅程(预约、处方、记录观察)运行一份简短的、可重复的核对清单,理想情况下是在一个使用合成患者、而不是真实记录的测试或培训环境中进行。同样的 DCB0160 部署安全与无障碍职责适用,与大型信托机构一样,但没有测试团队,因此现实的举措是依靠供应商的保证,同时保留只有你才能做的少数本地验收检查——这适合这家诊所实际运作的方式吗?一家甚至跳过这一步、直接在真实患者身上测试变更的小型提供者,离一次它无法察觉的安全事故只有一次糟糕的更新之遥。

大型企业#

一家 NHS 信托机构或大型供应商,在规模上、在完全保证之下运行测试:专门的测试环境、有临床替补支持的正式 UAT、运营验收测试、安全渗透测试,以及为线上临床系统的发布把关的变更咨询委员会。典型的挑战是遗留问题:庞大、老旧的系统,自动化测试覆盖率薄弱,每一次变更都令人生畏,因为没有人有信心知道它可能破坏什么,产生缓慢、昂贵的手动回归周期。战略举措是在风险最高的领域稳步投资自动化测试覆盖率,把恐惧转化为信心,把缓慢的发布转化为快速、安全的发布。大型企业还承担着跨集成系统进行测试的协调负担,其中一个供应商产品中的变更可能破坏另一个。

政府机构#

一个国家机构在服务标准、已发布的服务评估,以及最高标准的公众问责之下交付测试,在这个标准下,一个全国性系统中的测试失败可能影响数百万人,并抵达议会。对照 WCAG 的无障碍测试是对公共部门机构强制执行的一项法律义务,而在国家规模上的非功能性测试——负载、韧性、安全性——是生死攸关的,而不是可选的。挑战是跨众多供应商与集成服务协调质量保证,并在一个庞大的项目中保持一致的完成定义。国家级服务还塑造着整个生态系统:一个政府机构强制要求或发布的测试数据、工具与标准,会成为供应商据以构建的规范。

常见失败模式#

• 倒置的金字塔。 测试主要是缓慢的、手动的端到端检查;反馈缓慢,覆盖率稀薄,回归测试在时间压力下被跳过。解药:投资于一个广泛的、快速的自动化单元与集成测试基础。
• 作为末端阶段的测试。 测试是在上线前硬塞进去的一个阶段,是日程滑坡时第一个被砍掉的东西。解药:左移,把测试接入持续集成流水线,使其持续且廉价。
• 测试环境中的真实数据。 为了真实性,真实患者记录被复制到保护较弱的测试系统中,埋下了一次即将发生的数据泄露。解药:默认使用合成与匿名化数据;线上数据仅作为受治理的例外。
• 绿色构建,却没有信心。 测试通过,却覆盖的是琐事,而真正的临床危害未经测试。解药:把测试明确地映射到危害日志与风险最高的旅程。
• 无障碍性作为一个自动化的打勾项。 一次通过的自动化扫描被当作合规,而真实的辅助技术用户从未参与。解药:把自动化检查与残障用户的人工测试配对。
• 被放弃的完成定义。 "完成"被定义,却在截止日期压力下常规被推翻,把不安全的工作发布成已完成的。解药:让关口自动化,并给予某人以质量为由叫停发布的权力。

成熟度模型#

检查清单#

• 存在一座测试金字塔:广泛的自动化单元/集成覆盖,少量端到端测试,全部在持续集成中运行。
• DCB0129/0160 危害日志中最高的危害,每一个都被映射到具名的自动化回归测试。
• 一套回归测试套件运行,并且必须在任何变更抵达运行中的临床系统之前通过。
• 测试与预发布环境使用合成或匿名化数据;真实患者数据从不被随意使用。
• 针对关键临床旅程的现实高峰需求,运行了性能与负载测试。
• 安全测试与 WCAG 无障碍测试(自动化加上与辅助技术用户的人工测试)是常设的测试类型。
• 用户验收测试与真实临床医生在现实条件下运行,并预算了替补时间。
• 存在一份完成定义与被强制执行的质量关口,不会在截止日期压力下被悄悄放弃。
• 缺陷按临床影响被分诊,在上线时发布的已知问题被记录为已被接受、已被缓解的风险。
• 测试证据在临床安全论证报告中被直接引用。

关键来源#

• NHS England Digital ——DCB0129 与 DCB0160 临床风险管理标准;危害日志与临床安全论证报告。
• NHS England ——NHS 服务标准与 NHS 数字服务手册(无障碍性、测试与运营一项可靠的服务)。
• GOV.UK 服务手册(政府数字服务)——测试、测试数据与环境、无障碍性,以及持续交付指导。
• W3C 网页无障碍倡议 ——网页内容无障碍指南(WCAG)2.2 与测试技术。
• NHS England ——数字技术评估标准(DTAC),包括临床安全、技术保证,以及可用性/无障碍性。
• ISTQB(国际软件测试资质认证委员会)——基础测试术语与测试级别。
• 《2018 年公共部门机构(网站与移动应用)无障碍法规》。
• Mike Cohn ——测试金字塔概念;Martin Fowler / 持续交付(Humble & Farley)——测试自动化与 CI/CD 实践。

参考文献#

1. Software testing — Wikipedia — https://en.wikipedia.org/wiki/Software_testing
2. Quality assurance — Wikipedia — https://en.wikipedia.org/wiki/Quality_assurance
3. Unit testing — Wikipedia — https://en.wikipedia.org/wiki/Unit_testing
4. Integration testing — Wikipedia — https://en.wikipedia.org/wiki/Integration_testing
5. Shift-left testing — Wikipedia — https://en.wikipedia.org/wiki/Shift-left_testing
6. Non-functional testing — Wikipedia — https://en.wikipedia.org/wiki/Non-functional_testing
7. Regression testing — Wikipedia — https://en.wikipedia.org/wiki/Regression_testing
8. Test automation — Wikipedia — https://en.wikipedia.org/wiki/Test_automation
9. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
10. Acceptance testing — Wikipedia — https://en.wikipedia.org/wiki/Acceptance_testing
11. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
12. Deployment environment — Wikipedia — https://en.wikipedia.org/wiki/Deployment_environment
13. Synthetic data — Wikipedia — https://en.wikipedia.org/wiki/Synthetic_data
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
16. Testing your service, and test data and environments — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology
17. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/WAI/standards-guidelines/wcag/
18. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-tools/digital-technology-assessment-criteria-dtac/
19. Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK Government / GOV.UK — https://www.legislation.gov.uk/uksi/2018/952/contents/made
20. Continuous Delivery — Jez Humble and David Farley — https://continuousdelivery.com/