Chủ đề 3.7 — Kiểm thử và đảm bảo chất lượng

Tóm lại trong một câu: Trong y tế và chăm sóc, kiểm thử và đảm bảo chất lượng không phải là một giai đoạn bạn làm trước khi phát hành mà là một kỷ luật liên tục cung cấp phần lớn bằng chứng rằng một dịch vụ an toàn về lâm sàng, dễ tiếp cận, bảo mật và đủ điều kiện để chạm vào việc chăm sóc của bệnh nhân.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Mọi dịch vụ số đều mang lỗi; câu hỏi duy nhất là bao nhiêu, nghiêm trọng đến đâu, và bạn tìm ra chúng trước hay sau khi một bệnh nhân bị ảnh hưởng. Trong một ứng dụng tiêu dùng, một lỗi không bị phát hiện làm tốn buổi chiều của người dùng. Trong một hệ thống lâm sàng, nó có thể hiển thị dị ứng của sai bệnh nhân, làm tròn sai liều thuốc nhi khoa, hoặc lặng lẽ làm rơi một chuyển tuyến vào một hàng đợi không ai giám sát. Kiểm thử là nỗ lực có tổ chức để tìm những lỗi đó sớm, và đảm bảo chất lượng là hệ thống kiểm soát rộng hơn giữ cho chất lượng không phụ thuộc vào may rủi hay những nỗ lực phi thường.

Đó là lý do kiểm thử trong CNTT y tế không thể tách rời khỏi an toàn lâm sàng. Các mối nguy được ghi trong nhật ký mối nguy DCB0129/0160 (xem Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro) chỉ thực sự được giảm thiểu khi một bài kiểm thử chứng minh biện pháp giảm thiểu hoạt động và tiếp tục hoạt động sau mỗi thay đổi tiếp theo. Một hồ sơ an toàn tuyên bố "hệ thống ngăn kê đơn trùng lặp" mà không có bài kiểm thử lặp lại được phía sau là một lời khẳng định, không phải sự đảm bảo. Kiểm thử là cơ sở bằng chứng nằm dưới lập luận an toàn lâm sàng.

Rủi ro cũng liên quan đến công bằng và niềm tin công chúng. Một dịch vụ chưa bao giờ được kiểm thử theo các chuẩn khả năng tiếp cận sẽ loại trừ người dùng khuyết tật theo mặc định (xem Chủ đề 1.9 — Hòa nhập số và khả năng tiếp cận). Một dịch vụ chỉ được kiểm thử bằng bản sao hồ sơ bệnh nhân thật có nguy cơ rò rỉ dữ liệu làm xói mòn niềm tin mà NHS phụ thuộc vào. Và số tiền không nhỏ: làm lại một lỗi phát hiện trong vận hành thực tốn gấp nhiều lần so với bắt nó trong thiết kế, và một sự cố lâm sàng nghiêm trọng tốn nhiều hơn cả hai. Kiểm thử không đủ không phải là tiết kiệm; đó là một hóa đơn bị hoãn và phình to, đôi khi được trả bằng tác hại.

Các khái niệm cốt lõi#

Kiểm thử so với đảm bảo chất lượng. Kiểm thử là hành động vận hành một hệ thống để tìm lỗi và xác nhận hành vi. Đảm bảo chất lượng là tập hợp rộng hơn các quy trình — chuẩn, rà soát, định nghĩa hoàn thành, cổng — xây chất lượng vào thay vì kiểm tra vào ở cuối. Kiểm thử cho bạn biết bản dựng này có hoạt động không; QA là lý do các bản dựng của bạn nhìn chung hoạt động. Cả hai đều quan trọng, và các lãnh đạo thường tài trợ cái đầu trong khi bỏ bê cái sau.

Kim tự tháp kiểm thử và dịch sang trái (shift-left). Một chiến lược kiểm thử lành mạnh có nhiều kiểm thử đơn vị nhanh, rẻ (kiểm tra từng hàm), ít kiểm thử tích hợp hơn (kiểm tra các thành phần hoạt động cùng nhau), và một số ít kiểm thử đầu cuối chậm, đắt (kiểm tra toàn bộ hành trình người dùng). "Kim tự tháp kiểm thử" này giữ phản hồi nhanh và bảo trì trong tầm chi trả. Nó đi cùng kiểm thử dịch sang trái — chuyển kiểm thử sớm hơn trong vòng đời, để lỗi được thiết kế loại bỏ một cách rẻ thay vì bị tìm thấy trong cuộc chạy đua trước khi phát hành. Một kim tự tháp đảo ngược (chủ yếu là kiểm thử đầu cuối thủ công) chậm, dễ vỡ, và là dấu hiệu cảnh báo.

Kiểm thử chức năng và phi chức năng. Kiểm thử chức năng hỏi "hệ thống có làm điều nó nên làm không?" — tính toán đúng, quy trình đúng, dữ liệu đúng. Kiểm thử phi chức năng hỏi "nó hoạt động tốt đến đâu?" — hiệu năng và tải (nó có giữ được độ đáp ứng khi cả bệnh viện đăng nhập lúc 08:00?), bảo mật (nó có bị xâm phạm được không?), độ tin cậy và khả năng tiếp cận. Trong y tế và chăm sóc, các thất bại phi chức năng thường nguy hiểm nhất: một hệ thống hoàn hảo về chức năng nhưng hết thời gian chờ trong một cuộc gọi hồi sức đã thất bại về lâm sàng.

Kiểm thử hồi quy. Kiểm thử hồi quy chạy lại các bài kiểm thử hiện có sau một thay đổi để xác nhận việc sửa hay thêm một thứ không làm hỏng thứ khác. Trong các hệ thống lâm sàng đang vận hành, đây là thói quen an toàn quan trọng nhất: phần lớn sự cố phần mềm lâm sàng không đến từ tính năng mới mà từ các thay đổi lặng lẽ làm hỏng hành vi đang hoạt động. Một bộ hồi quy đáng tin là điều cho phép bạn thay đổi một hệ thống đang vận hành mà không nín thở.

Tự động hóa kiểm thử và tích hợp liên tục. Tự động hóa kiểm thử dùng phần mềm để chạy kiểm thử lặp lại được, nên một bộ lớn thực thi trong vài phút trên mỗi thay đổi. Kết hợp với tích hợp liên tục — gộp và kiểm thử tự động các thay đổi thường xuyên — điều này biến kiểm thử từ một sự kiện thỉnh thoảng thành một tấm lưới an toàn liên tục (xem Chủ đề 3.5 — Vòng đời triển khai). Tự động hóa không thay thế phán đoán của con người; nó giải phóng con người để làm việc kiểm thử thăm dò và lâm sàng mà máy không làm được.

Kiểm thử chấp nhận. Kiểm thử chấp nhận, cụ thể là kiểm thử chấp nhận của người dùng (UAT), là nơi bác sĩ và người dùng thật xác nhận hệ thống hoạt động trong bối cảnh thực của họ trước khi vận hành. Kiểm thử chấp nhận vận hành (OAT) xác nhận dịch vụ có thể được vận hành, sao lưu và phục hồi. UAT với người dùng cuối thực sự bắt được các sai lệch quy trình mà không bài kiểm thử nào của lập trình viên bắt được.

Môi trường kiểm thử và dữ liệu kiểm thử an toàn. Một môi trường triển khai là hệ thống nơi phần mềm chạy — thường là các tầng phát triển, kiểm thử, dàn dựng và sản phẩm. Kiểm thử cần các môi trường giống sản phẩm nhưng không bao giờ được tùy tiện dùng dữ liệu bệnh nhân thật. Thực hành an toàn dùng dữ liệu tổng hợp (được tạo nhân tạo) hoặc dữ liệu đã ẩn danh đúng cách, để việc kiểm thử một biểu mẫu chuyển tuyến không thể làm rò rỉ chẩn đoán của một công dân thật.

Cổng chất lượng, định nghĩa hoàn thành và quản lý lỗi. Một định nghĩa hoàn thành nêu "xong" nghĩa là gì (đã kiểm thử, dễ tiếp cận, có tài liệu, đã rà soát an toàn) để chất lượng không thể thương lượng theo từng tính năng. Cổng chất lượng là các điểm kiểm tra mà một thay đổi phải qua để tiến lên. Phân loại lỗi là quy trình có kỷ luật đánh giá các lỗi tìm thấy về mức độ nghiêm trọng và tác động lâm sàng, và quyết định sửa cái gì, khi nào, và cái gì có thể giao như một vấn đề đã biết.

Thực hành tốt nhất#

1. Xây kim tự tháp và dịch kiểm thử sang trái. Đầu tư vào một nền rộng các kiểm thử đơn vị và tích hợp tự động nhanh, chạy trên mỗi thay đổi, để lỗi lộ ra trong vài phút sau khi được viết thay vì nhiều tuần sau trong UAT. Dành các kiểm thử đầu cuối chậm cho một nhúm hành trình then chốt — đơn thuốc, chuyển tuyến, khớp danh tính. Điều này làm kiểm thử rẻ hơn và nhanh hơn, chính là điều thực sự khiến các nhóm làm nhiều hơn.

2. Xem kiểm thử hồi quy là một biện pháp kiểm soát an toàn lâm sàng. Trước khi bất kỳ thay đổi nào đến một hệ thống lâm sàng đang vận hành, một bộ hồi quy tự động phải xác nhận hành vi hiện có, liên quan đến an toàn vẫn hoạt động. Ánh xạ các mối nguy cao nhất từ nhật ký mối nguy DCB0129/0160 trực tiếp vào các kiểm thử hồi quy có tên, để một thay đổi sẽ tái đưa vào một mối nguy đã biết làm hỏng bản dựng tự động. Đây là cơ chế cho phép bạn lặp lại trên các hệ thống đang vận hành mà không tích lũy rủi ro lâm sàng thầm lặng.

3. Đừng bao giờ kiểm thử bằng dữ liệu bệnh nhân thật theo mặc định. Cấp phát các môi trường kiểm thử và dàn dựng với dữ liệu tổng hợp hoặc dữ liệu đã ẩn danh vững chắc, được chi phối bởi cùng kỷ luật quản trị thông tin và DPIA như sản phẩm (xem Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng). Nếu một bài kiểm thử cụ thể thực sự cần dữ liệu giống sản phẩm, hãy xem nó là một ngoại lệ được kiểm soát với cơ sở pháp lý được ghi chép, tối thiểu hóa và kiểm toán — không phải sự tiện lợi thường lệ. Một cơ sở dữ liệu kiểm thử vẫn là một cơ sở dữ liệu bệnh nhân.

4. Kiểm thử các yêu cầu phi chức năng nghiêm túc như các yêu cầu chức năng. Chạy kiểm thử hiệu năng và tải theo nhu cầu đỉnh thực tế — bàn giao ca, đăng nhập sáng thứ Hai, một sự cố khu vực chuyển hướng lưu lượng — vì một hệ thống lâm sàng chậm như rùa dưới tải đã thất bại đúng lúc quan trọng nhất. Đưa kiểm thử bảo mật và kiểm thử khả năng tiếp cận theo Hướng dẫn Khả năng Tiếp cận Nội dung Web (WCAG) thành các loại kiểm thử thường trực, không tùy chọn. Lỗi phi chức năng dễ bị hoãn và đắt khi phát hiện trong sản phẩm.

5. Tự động hóa kiểm thử khả năng tiếp cận, rồi xác minh bằng con người. Các kiểm tra WCAG tự động bắt được một phần có ý nghĩa các vấn đề (thiếu nhãn, độ tương phản kém, cấu trúc) một cách rẻ trên mỗi bản dựng, nhưng chúng bỏ sót những vấn đề quan trọng nhất với người dùng thật của công nghệ hỗ trợ. Ghép quét tự động với kiểm thử thủ công bởi những người dùng trình đọc màn hình, điều hướng chỉ bằng bàn phím và phóng đại. Khả năng tiếp cận là nghĩa vụ pháp lý của các cơ quan công và là vấn đề an toàn lâm sàng khi người dùng bị loại trừ là một bác sĩ hay một bệnh nhân tự quản lý chăm sóc.

6. Chạy kiểm thử chấp nhận của người dùng với bác sĩ thật trong điều kiện thực tế. Lên lịch UAT với chính những người sẽ dùng hệ thống — điều dưỡng, bác sĩ gia đình, nhân viên hành chính, dược sĩ — thực hiện các quy trình thực, lý tưởng trong một môi trường phản chiếu khoa hay phòng khám, không phải một phòng họp yên tĩnh. Phản hồi của họ bắt được các sai lệch quy trình nguy hiểm (một cảnh báo hiện sai lúc, một mặc định mời gọi sai sót) mà kiểm thử đơn vị không thể. Dành ngân sách thời gian lâm sàng thay thế để UAT được làm đúng đắn, không bị ép vào thiện chí.

7. Làm cho định nghĩa hoàn thành và cổng chất lượng rõ ràng và được thực thi. Thống nhất "xong" nghĩa là gì trong bối cảnh của bạn — kiểm thử đạt, tuân thủ khả năng tiếp cận, quét bảo mật sạch, rà soát an toàn lâm sàng hoàn tất, tài liệu cập nhật — và thực thi nó như một cổng, không phải mong ước. Một định nghĩa hoàn thành được viết ra nhưng thường xuyên bị miễn dưới áp lực hạn chót còn tệ hơn không có, vì nó "rửa" công việc không an toàn thành đã hoàn thành. Các cổng nên được tự động hóa nơi có thể để chúng không thể bị lặng lẽ bỏ qua.

8. Phân loại và quản lý lỗi với mức nghiêm trọng lâm sàng đặt lên hàng đầu. Đánh giá mỗi lỗi không chỉ về mức nghiêm trọng kỹ thuật mà còn về tác động và khả năng xảy ra lâm sàng, dùng cùng lăng kính rủi ro như nhật ký mối nguy của bạn. Một lỗi thẩm mỹ có thể chờ; một lỗi có thể góp phần vào một liều sai chặn phát hành bất kể ngày vận hành. Duy trì một sổ đăng ký lỗi hữu hình, và trung thực về các vấn đề đã biết được giao như các rủi ro được chấp nhận, được giảm thiểu thay vì bị che giấu.

9. Tích hợp kiểm thử vào đường ống triển khai, không phải sau nó. Nối các kiểm thử tự động, quét bảo mật và kiểm tra khả năng tiếp cận vào đường ống tích hợp và giao hàng liên tục để mọi thay đổi được kiểm thử trước khi có thể tiến lên (xem Chủ đề 3.5 — Vòng đời triển khai). Điều này làm chất lượng liên tục và rẻ, và có nghĩa là khả năng triển khai nhanh một bản sửa đã kiểm thử — tự nó là một biện pháp kiểm soát an toàn — luôn sẵn có. Các giai đoạn kiểm thử thủ công cuối dự án chậm, muộn, và là thứ đầu tiên bị hy sinh khi thời gian cạn.

Câu hỏi để thảo luận với nhóm của bạn#

1. Nếu chúng ta thay đổi một thứ trong hệ thống lâm sàng đang vận hành vào ngày mai, chúng ta tự tin đến đâu rằng mình sẽ phát hiện — trước khi bệnh nhân phát hiện — nếu nó làm hỏng thứ khác? Câu hỏi này thăm dò độ trưởng thành của kiểm thử hồi quy và sự trung thực của các tuyên bố an toàn của bạn. Hầu hết các sự cố phần mềm lâm sàng nghiêm trọng không phải là những thất bại mới lạ mà là hồi quy: một thay đổi lặng lẽ làm hỏng hành vi mà mọi người giả định ổn định, chỉ bị phát hiện khi một bác sĩ hay bệnh nhân gặp nó. Một cuộc thảo luận tốt lần theo một thay đổi thực gần đây đến các kiểm thử sẽ bắt được hồi quy, và hỏi liệu các mối nguy cao nhất trong nhật ký mối nguy DCB0129/0160 có mỗi cái được một kiểm thử tự động hậu thuẫn mà thất bại khi mối nguy tái xuất hiện hay không. Căng thẳng cần nêu ra là giữa áp lực giao nhanh các bản sửa và kỷ luật chứng minh không có gì khác hỏng — và liệu đường ống của bạn làm bằng chứng đó tự động hay để lại cho ai đó nhớ kiểm tra. Hãy cân nhắc bộ kiểm thử mất bao lâu để chạy, có chạy trên mọi thay đổi không, và có ai lặng lẽ tắt các kiểm thử thất bại để kịp hạn chót không. Một câu trả lời trung thực phân biệt "chúng tôi có bộ hồi quy gắn với các mối nguy lâm sàng và tin nó" với "chúng tôi kiểm thử thay đổi mình làm và hy vọng điều tốt nhất". Nếu là cái sau, bạn đang mang rủi ro lâm sàng mà bạn không thấy.

2. Dữ liệu kiểm thử của chúng ta đến từ đâu, và liệu một bài kiểm thử có bao giờ tiết lộ thông tin của một bệnh nhân thật không? Môi trường kiểm thử là một con đường phổ biến và ít được xem xét dẫn đến rò rỉ dữ liệu, vì các nhóm dưới áp lực với tay lấy dữ liệu thực tế dễ nhất — một bản sao của sản phẩm — và các hồ sơ bệnh nhân kết quả nằm trong các hệ thống kiểm thử ít được bảo vệ, laptop hay môi trường nhà cung cấp. Câu hỏi này yêu cầu nhóm lần theo mọi môi trường kiểm thử và dàn dựng về nguồn dữ liệu của chúng, và đối diện một cách trung thực liệu các bản sao dữ liệu thật "chỉ lần này" đã trở thành thường lệ chưa. Sự đánh đổi cần tranh luận là tính thực tế so với an toàn: dữ liệu tổng hợp và ẩn danh an toàn hơn nhưng có thể bỏ sót các ca biên lộn xộn mà dữ liệu thật chứa, trong khi dữ liệu thật thực tế nhưng là một trách nhiệm quản trị và vi phạm, và ẩn danh thực sự khó hơn vẻ ngoài vì hồ sơ có thể bị nhận dạng lại khi kết hợp. Các góc cụ thể gồm ai có thể truy cập môi trường kiểm thử, cơ sở dữ liệu kiểm thử có được mã hóa và kiểm toán như sản phẩm không, và môi trường kiểm thử của nhà cung cấp có đạt cùng ngưỡng không. Một câu trả lời mạnh mô tả một chiến lược có chủ đích — dữ liệu tổng hợp theo mặc định, ẩn danh làm đúng cách, dữ liệu thật chỉ như một ngoại lệ được ghi chép, tối thiểu hóa, có giới hạn thời gian — thay vì một tai nạn đang chờ một cuộc điều tra quản trị thông tin.

3. Khi ngày vận hành và ngưỡng chất lượng va chạm, thực sự điều gì nhượng bộ — và ai quyết định? Mọi lần triển khai cuối cùng đều đối mặt khoảnh khắc khi kiểm thử chưa xong, một lỗi chưa được giải quyết, hoặc mức tuân thủ khả năng tiếp cận chưa hoàn chỉnh, và ngày ra mắt đang đến gần; cách tổ chức của bạn hành xử vào khoảnh khắc đó cho thấy chất lượng là một biện pháp kiểm soát thực sự hay chỉ là khát vọng. Câu hỏi này yêu cầu nhóm nhớ lại lần gần nhất điều đó xảy ra và mô tả một cách trung thực cái gì đã bị cắt: là tồn đọng thẩm mỹ, hay là kiểm thử hồi quy, UAT, hoặc cuộc kiểm toán khả năng tiếp cận? Căng thẳng là có thật và không nên gạt đi — ngày tháng quan trọng, các chu kỳ kinh phí không khoan nhượng, và kiểm thử vô tận tự nó cũng có thể là một kiểu thất bại — nhưng cách giải quyết phải được chi phối bởi rủi ro lâm sàng và công bằng, không phải bởi ai hét to nhất. Hãy thảo luận ai có thẩm quyền giữ lại một lần ra mắt vì lý do chất lượng mà không rủi ro sự nghiệp, định nghĩa hoàn thành của bạn có bao giờ bị miễn chính thức và bởi ai, và các lỗi đã biết được giao lúc vận hành được ghi lại như các rủi ro được chấp nhận hay bị lặng lẽ chôn. Một câu trả lời tốt cho thấy một đường quyết định rõ ràng, có tên, một ranh giới sáng dưới đó một lỗi chặn phát hành bất kể ngày (bất cứ thứ gì có thể góp phần gây hại cho bệnh nhân), và một văn hóa nơi nói "chưa được, nó chưa an toàn" được thưởng thay vì bị phạt.

4. Các kiểm thử của chúng ta có thực sự bao phủ những thứ có thể gây hại cho bệnh nhân, hay chỉ những thứ dễ kiểm thử? Một bản dựng xanh chỉ trấn an nếu các kiểm thử đằng sau nó thực hiện các mối nguy lâm sàng thực, và thật đáng khó chịu khi một con số độ bao phủ trông lành mạnh nằm trên đỉnh một bộ kiểm tra các getter và setter tầm thường trong khi điểm cảnh báo xấu đi, khớp danh tính và hiển thị dị ứng không được kiểm thử. Câu hỏi này yêu cầu nhóm đặt bộ kiểm thử cạnh nhật ký mối nguy DCB0129/0160 và các hành trình người dùng rủi ro cao nhất và hỏi, từng mối nguy một, "kiểm thử có tên nào sẽ thất bại nếu điều này đi sai?" Căng thẳng là các chỉ số độ bao phủ thưởng cho khối lượng, không phải mức liên quan đến rủi ro, và các nhóm bị cám dỗ đuổi theo một tỷ lệ phần trăm thay vì đối diện với các ca vụng về, khó tự động hóa — giá trị biên, đầu vào thiếu, các tổ hợp lâm sàng bất thường — chính xác là nơi bệnh nhân bị hại. Các góc cụ thể gồm rà soát xem các ca biên và ranh giới có được kiểm thử không, liệu kiểm thử thăm dò và lâm sàng (phán đoán mà máy không thay thế được) có chỗ cạnh tự động hóa không, và có ai từng lần theo một sự cố thực đến một khoảng trống mà các kiểm thử lẽ ra phải bắt được không. Một câu trả lời trung thực nói về độ bao phủ có trọng số rủi ro và có thể gọi tên các kiểm thử bảo vệ các mối nguy hàng đầu, thay vì trích dẫn một tỷ lệ phần trăm duy nhất như thể nó là sự đảm bảo.

5. Khi chúng ta kiểm thử khả năng tiếp cận, người dùng khuyết tật thật và bác sĩ thật có ở trong phòng không, hay chỉ có một công cụ quét tự động? Các kiểm tra WCAG tự động rẻ và thuộc về mọi bản dựng, nhưng chúng chỉ phát hiện một phần các rào cản thực sự loại trừ người ta, và một dịch vụ có thể vượt qua mọi quy tắc tự động mà vẫn không dùng được với trình đọc màn hình hoặc chỉ bằng bàn phím. Câu hỏi này hỏi liệu kiểm thử khả năng tiếp cận và chấp nhận của người dùng của bạn có đến được những người thật dùng công nghệ hỗ trợ và bác sĩ thật làm việc qua các quy trình thực không, hay "chúng tôi đã kiểm thử khả năng tiếp cận" lặng lẽ có nghĩa là "công cụ quét xanh". Sự đánh đổi cần nêu ra là chi phí và hậu cần so với sự trung thực: tuyển người dùng công nghệ hỗ trợ và thay thế thời gian lâm sàng cho UAT thực tế đắt và dễ bỏ qua, nhưng bỏ qua nó là cách một nghĩa vụ pháp lý bị vi phạm và cách một sai lệch quy trình nguy hiểm — một cảnh báo ở sai lúc, một mặc định mời gọi sai sót — đến một khoa đang vận hành. Hãy thảo luận bạn mời ai, họ mang tính đại diện đến đâu, kiểm thử có diễn ra trong một môi trường phản chiếu phòng khám thay vì một phòng họp yên tĩnh không, và bạn làm gì với điều họ tìm thấy. Một câu trả lời mạnh mô tả các kiểm tra tự động được ghép với kiểm thử thủ công bởi người dùng khuyết tật và UAT do bác sĩ dẫn dắt như thực hành thường trực, có ngân sách, không phải một ô được đánh dấu một lần trước khi vận hành.

6. Khi một thay đổi vượt qua ranh giới giữa hệ thống của chúng ta và của người khác, ai kiểm thử chỗ nối — và chúng ta có biết nếu nó hỏng không? Các dịch vụ y tế và chăm sóc hiện đại là tập hợp các hệ thống tích hợp — một EPR, một dịch vụ cột sống quốc gia, một nguồn bệnh học, một mô-đun của nhà cung cấp bên thứ ba — và các lỗi nguy hiểm nhất thường không nằm trong bất kỳ thành phần đơn lẻ nào mà ở các đường nối giữa chúng, nơi một thay đổi ở một bên của giao diện lặng lẽ làm hỏng bên kia. Câu hỏi này yêu cầu nhóm vẽ các tích hợp then chốt của mình và hỏi, với mỗi cái, ai sở hữu kiểm thử đầu cuối, dữ liệu tổng hợp nào chảy qua ranh giới, và một thay đổi phá vỡ trong bản phát hành của nhà cung cấp sẽ được phát hiện thế nào trước khi đến bệnh nhân. Căng thẳng là không nhóm đơn lẻ nào cảm thấy hoàn toàn chịu trách nhiệm về một giao diện dùng chung, hợp đồng và hội đồng tư vấn thay đổi di chuyển ở các tốc độ khác nhau, và kiểm thử xuyên ranh giới tổ chức chậm, mang tính chính trị và dễ bị bỏ mặc cho may rủi. Các góc cụ thể gồm kiểm thử hợp đồng và giao diện, môi trường kiểm thử dùng chung, cách xử lý thông báo thay đổi của nhà cung cấp, và liệu bộ hồi quy của bạn có thực hiện hành trình tích hợp (chuyển tuyến được gửi, nhận, xác nhận) chứ không chỉ nửa của riêng bạn. Một câu trả lời trung thực gọi tên ai chịu trách nhiệm cho mỗi chỗ nối và cho thấy một cơ chế — tự động hóa nơi có thể — bắt được một hồi quy xuyên ranh giới, thay vì giả định bên kia đã lo.

Trong thực tế: một ví dụ về y tế và chăm sóc#

Một bệnh viện cấp cứu NHS đang triển khai một mô-đun quan sát điện tử và điểm cảnh báo sớm (EWS) mới trong hồ sơ bệnh nhân điện tử của mình, thay thế biểu đồ giấy mà điều dưỡng ghi các dấu hiệu sinh tồn và hệ thống tính điểm xấu đi. Mối nguy lâm sàng hiển nhiên: một điểm sai có thể có nghĩa là một bệnh nhân đang xấu đi không được leo thang.

Nhóm xây kim tự tháp ngay từ đầu. Kiểm thử đơn vị bao phủ phép tính EWS theo các quy tắc chấm điểm quốc gia, gồm các ca biên (các ngưỡng chính xác nơi một điểm chuyển sang leo thang) và các đầu vào vụng về (thiếu nhịp thở, một bệnh nhân đang thở oxy bổ sung). Kiểm thử tích hợp xác nhận điểm chảy đúng đến cảnh báo leo thang và danh sách nhiệm vụ điều dưỡng. Một tập nhỏ kiểm thử đầu cuối thực hiện toàn bộ hành trình từ nhập liệu tại giường đến một cảnh báo được kích hoạt. Mỗi mối nguy trong nhật ký mối nguy DCB0160 được ánh xạ tới các kiểm thử có tên, và toàn bộ bộ chạy tự động trên mọi thay đổi trong đường ống tích hợp liên tục.

Các môi trường kiểm thử được cấp phát với bệnh nhân tổng hợp — các mô thức dấu hiệu sinh tồn thực tế gồm các quỹ đạo xấu đi — nên không hồ sơ thật nào rời khỏi sản phẩm. Kiểm thử hiệu năng mô phỏng một vòng thăm khám toàn khoa lúc bàn giao ca, xác nhận các cảnh báo kích hoạt trong vài giây dưới tải đỉnh. Kiểm thử khả năng tiếp cận, tự động trên mọi bản dựng và được xác minh thủ công với một điều dưỡng dùng phóng đại màn hình, bắt được một biểu ngữ cảnh báo có độ tương phản thấp.

UAT trên một khoa thí điểm, với điều dưỡng thật làm việc qua các kịch bản mô phỏng, làm lộ một lỗi quy trình mà không lập trình viên nào thấy: hộp thoại xác nhận xuất hiện sau điểm số, cám dỗ nhân viên bác bỏ nó theo phản xạ. Nhóm thiết kế lại luồng và thêm một kiểm thử hồi quy. Lúc vận hành, ba lỗi thẩm mỹ được giao như các vấn đề được chấp nhận, có ghi chép; hai lỗi chạm vào phép tính được sửa và chặn phát hành cho đến khi chúng qua, và hồ sơ an toàn trích dẫn trực tiếp bằng chứng kiểm thử. Sáu tháng vào vận hành, một thay đổi thường lệ với danh sách nhiệm vụ làm vấp một kiểm thử hồi quy mà nếu không bị phát hiện sẽ chặn một cảnh báo leo thang — được bắt trong đường ống, sửa trước khi triển khai, không bao giờ đến một khoa.

Góc nhìn theo khu vực#

Công ty khởi nghiệp#

Một công ty y tế số nhỏ có lợi thế xây kiểm thử tự động và tích hợp liên tục vào DNA từ ngày đầu, không có quy trình kiểm thử thủ công cũ cần gỡ, và có thể đạt được sự lặp lại nhanh, an toàn mà một bệnh viện lớn sẽ ghen tị. Nguy cơ là xem kiểm thử như xa xỉ để hoãn trong khi đuổi theo sự phù hợp sản phẩm-thị trường, và tiết kiệm kiểm thử phi chức năng và an toàn lâm sàng mà chưa khách hàng sớm nào đòi hỏi. Nhà sáng lập phải nhớ rằng các nghĩa vụ DCB0129 gắn với nhà sản xuất bất kể quy mô công ty, nên bằng chứng hồi quy đằng sau một tuyên bố an toàn không tùy chọn ngay cả trước khi có doanh thu. Dữ liệu kiểm thử tổng hợp cũng là bạn của công ty khởi nghiệp: nó tránh gánh nặng quản trị của việc xử lý dữ liệu bệnh nhân thật trước khi công ty có các biện pháp kiểm soát để làm vậy một cách an toàn.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão, hoặc một phòng khám đơn lẻ — thường mua các hệ thống lâm sàng thay vì xây chúng, nên công việc kiểm thử của nó là chấp nhận, không phải xây dựng: xác nhận một bản cập nhật hay tích hợp mới của nhà cung cấp vẫn hoạt động an toàn trong quy trình thực trước khi nhân viên phụ thuộc vào nó. Với ít hoặc không có năng lực CNTT chuyên trách, kỷ luật thực tế là một danh sách kiểm tra ngắn, lặp lại được chạy trên các hành trình rủi ro cao nhất (đặt lịch, kê đơn, ghi quan sát) sau mỗi thay đổi của nhà cung cấp, lý tưởng trong một môi trường kiểm thử hoặc đào tạo với bệnh nhân tổng hợp thay vì hồ sơ thật. Áp dụng cùng các nghĩa vụ an toàn triển khai DCB0160 và khả năng tiếp cận như một bệnh viện lớn, nhưng không có nhóm kiểm thử, nên nước đi thực tế là dựa vào sự đảm bảo của nhà cung cấp trong khi giữ lại vài kiểm tra chấp nhận tại chỗ mà chỉ bạn làm được — nó có khớp với cách phòng khám này thực sự làm việc không? Một nhà cung cấp nhỏ bỏ qua ngay cả điều này và kiểm thử các thay đổi trực tiếp trên bệnh nhân thật chỉ cách một bản cập nhật xấu một sự cố an toàn mà nó không có cách nào bắt được.

Doanh nghiệp lớn#

Một bệnh viện NHS hoặc nhà cung ứng lớn chạy kiểm thử ở quy mô lớn và dưới sự đảm bảo đầy đủ: các môi trường kiểm thử chuyên dụng, UAT chính thức với thay thế lâm sàng, kiểm thử chấp nhận vận hành, kiểm thử xâm nhập bảo mật, và hội đồng tư vấn thay đổi đóng cổng các bản phát hành lên hệ thống lâm sàng đang vận hành. Thách thức đặc trưng là hệ thống cũ — các hệ thống lớn, cũ với độ bao phủ kiểm thử tự động mỏng, nơi mọi thay đổi đều đáng sợ vì không ai tự tin nó có thể làm hỏng gì, tạo ra các chu kỳ hồi quy thủ công chậm, đắt. Nước đi chiến lược là đầu tư đều đặn vào độ bao phủ kiểm thử tự động quanh các khu vực rủi ro cao nhất, biến nỗi sợ thành sự tự tin và các bản phát hành chậm thành nhanh và an toàn. Các doanh nghiệp lớn cũng mang gánh nặng phối hợp kiểm thử xuyên các hệ thống tích hợp, nơi một thay đổi trong sản phẩm của một nhà cung cấp có thể làm hỏng sản phẩm của nhà khác.

Chính phủ#

Một cơ quan quốc gia thực hiện kiểm thử dưới Tiêu chuẩn Dịch vụ, các đánh giá dịch vụ được công bố và ngưỡng trách nhiệm giải trình công khai cao nhất, nơi một thất bại kiểm thử trong một hệ thống toàn quốc có thể ảnh hưởng hàng triệu người và đến Nghị viện. Kiểm thử khả năng tiếp cận theo WCAG là nghĩa vụ pháp lý được thực thi với các cơ quan công, và kiểm thử phi chức năng ở quy mô quốc gia — tải, khả năng phục hồi, bảo mật — mang tính sống còn chứ không tùy chọn. Thách thức là phối hợp đảm bảo chất lượng qua nhiều nhà cung cấp và dịch vụ tích hợp, và giữ một định nghĩa hoàn thành nhất quán qua một chương trình trải dài. Các dịch vụ quốc gia cũng định hình hệ sinh thái: dữ liệu kiểm thử, công cụ và chuẩn mà một cơ quan chính phủ bắt buộc hoặc công bố trở thành chuẩn mực mà các nhà cung cấp xây theo.

Các kiểu thất bại thường gặp#

• Kim tự tháp đảo ngược. Kiểm thử chủ yếu là các kiểm tra đầu cuối thủ công, chậm; phản hồi chậm, độ bao phủ mỏng và kiểm thử hồi quy bị bỏ qua dưới áp lực thời gian. Giải pháp: đầu tư vào một nền rộng các kiểm thử đơn vị và tích hợp tự động nhanh.
• Kiểm thử như một giai đoạn cuối. Kiểm thử là một giai đoạn nhồi nhét trước khi vận hành và là thứ đầu tiên bị cắt khi lịch trượt. Giải pháp: dịch sang trái và nối kiểm thử vào đường ống tích hợp liên tục để nó liên tục và rẻ.
• Dữ liệu thật trong môi trường kiểm thử. Hồ sơ bệnh nhân thật được sao chép vào các hệ thống kiểm thử ít được bảo vệ để có tính thực tế, tạo ra một vụ vi phạm đang chờ xảy ra. Giải pháp: dữ liệu tổng hợp và ẩn danh theo mặc định; dữ liệu thật chỉ như ngoại lệ được quản trị.
• Bản dựng xanh, không có sự tự tin. Kiểm thử đạt nhưng bao phủ những thứ tầm thường trong khi các mối nguy lâm sàng thực không được kiểm thử. Giải pháp: ánh xạ rõ ràng các kiểm thử vào nhật ký mối nguy và các hành trình rủi ro cao nhất.
• Khả năng tiếp cận như một ô đánh dấu tự động. Một lần quét tự động đạt được xem là sự tuân thủ trong khi người dùng công nghệ hỗ trợ thật không bao giờ được mời. Giải pháp: ghép các kiểm tra tự động với kiểm thử thủ công bởi người dùng khuyết tật.
• Định nghĩa hoàn thành bị miễn. "Xong" được định nghĩa nhưng thường xuyên bị ghi đè dưới áp lực hạn chót, đưa công việc không an toàn ra như đã hoàn thành. Giải pháp: tự động hóa các cổng và trao cho ai đó thẩm quyền giữ lại một lần ra mắt vì lý do chất lượng.

Mô hình trưởng thành#

Danh sách kiểm tra#

• Một kim tự tháp kiểm thử tồn tại: độ bao phủ đơn vị/tích hợp tự động rộng, ít kiểm thử đầu cuối, tất cả chạy trong tích hợp liên tục.
• Các mối nguy cao nhất trong nhật ký mối nguy DCB0129/0160 mỗi cái được ánh xạ vào các kiểm thử hồi quy tự động có tên.
• Một bộ hồi quy chạy và phải đạt trước khi bất kỳ thay đổi nào đến một hệ thống lâm sàng đang vận hành.
• Môi trường kiểm thử và dàn dựng dùng dữ liệu tổng hợp hoặc ẩn danh; dữ liệu bệnh nhân thật không bao giờ được dùng tùy tiện.
• Kiểm thử hiệu năng và tải được chạy theo nhu cầu đỉnh thực tế cho các hành trình lâm sàng then chốt.
• Kiểm thử bảo mật và kiểm thử khả năng tiếp cận WCAG (tự động cộng thủ công với người dùng công nghệ hỗ trợ) là các loại kiểm thử thường trực.
• Kiểm thử chấp nhận của người dùng được chạy với bác sĩ thật trong điều kiện thực tế, với thời gian thay thế được dự trù.
• Một định nghĩa hoàn thành và các cổng chất lượng được thực thi tồn tại và không bị lặng lẽ miễn dưới áp lực hạn chót.
• Lỗi được phân loại theo tác động lâm sàng, và các vấn đề đã biết giao lúc vận hành được ghi lại như các rủi ro được chấp nhận, được giảm thiểu.
• Bằng chứng kiểm thử được trích dẫn trực tiếp trong báo cáo hồ sơ an toàn lâm sàng.

Nguồn chính#

• NHS England Digital — các tiêu chuẩn quản lý rủi ro lâm sàng DCB0129 và DCB0160; nhật ký mối nguy và báo cáo hồ sơ an toàn lâm sàng.
• NHS England — Tiêu chuẩn Dịch vụ NHS và Sổ tay Dịch vụ Số của NHS (khả năng tiếp cận, kiểm thử và vận hành một dịch vụ đáng tin).
• Sổ tay Dịch vụ GOV.UK (Dịch vụ Số của Chính phủ) — hướng dẫn về kiểm thử, dữ liệu và môi trường kiểm thử, khả năng tiếp cận và giao hàng liên tục.
• Sáng kiến Khả năng Tiếp cận Web của W3C — Hướng dẫn Khả năng Tiếp cận Nội dung Web (WCAG) 2.2 và các kỹ thuật kiểm thử.
• NHS England — Tiêu chí Đánh giá Công nghệ Số (DTAC), gồm an toàn lâm sàng, đảm bảo kỹ thuật và khả năng sử dụng/tiếp cận.
• ISTQB (Hội đồng Chứng chỉ Kiểm thử Phần mềm Quốc tế) — thuật ngữ kiểm thử nền tảng và các cấp kiểm thử.
• Quy định về Khả năng Tiếp cận của Các Cơ quan Khu vực Công (Trang web và Ứng dụng Di động) 2018.
• Mike Cohn — khái niệm kim tự tháp kiểm thử; Martin Fowler / Continuous Delivery (Humble & Farley) — thực hành tự động hóa kiểm thử và CI/CD.

Tài liệu tham khảo#

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/