Cách kiểm thử giải pháp công nghệ trước khi đưa vào sử dụng

ISO/IEC 25010:2023 xem chất lượng sản phẩm ICT và phần mềm dưới nhiều đặc tính thay vì một tiêu chí duy nhất, đồng thời cho phép sử dụng mô hình chất lượng để xác định mục tiêu kiểm thử, tiêu chí kiểm soát chất lượng và tiêu chí chấp nhận. Vì vậy, kiểm thử giải pháp công nghệ nên được tổ chức như một quá trình xác minh bằng bằng chứng: mỗi yêu cầu quan trọng phải có cách kiểm tra, chỉ số đo và điều kiện đạt/không đạt tương ứng.

Xác định tiêu chí đạt trước khi bắt đầu kiểm thử

Sai lầm phổ biến là triển khai kiểm thử trước rồi mới xem kết quả nào có thể chấp nhận. Cách này khiến quyết định go-live dễ bị chi phối bởi cảm nhận hoặc áp lực tiến độ.

Doanh nghiệp nên chuyển yêu cầu kinh doanh và yêu cầu kỹ thuật thành các tiêu chí có thể kiểm chứng. ISO/IEC/IEEE 29119-2:2021 quy định các quá trình dùng để quản trị, quản lý và thực hiện kiểm thử phần mềm, có thể áp dụng cho nhiều mô hình vòng đời phát triển.

Một bộ tiêu chí trước kiểm thử thường cần xác định:

·         Chức năng hoặc quy trình nghiệp vụ nào bắt buộc phải hoạt động

·         Hệ thống, API, cơ sở dữ liệu hoặc thiết bị nào phải tích hợp

·         Khối lượng người dùng, giao dịch và dữ liệu dự kiến

·         Chỉ số hiệu năng cần đo như thời gian phản hồi, throughput, tỷ lệ lỗi và mức sử dụng tài nguyên

·         Yêu cầu phân quyền, xác thực, bảo vệ dữ liệu và ghi log

·         Các lỗi nào buộc phải chặn triển khai

·         Mức lỗi nào có thể chấp nhận tạm thời kèm phương án xử lý

·         Điều kiện rollback nếu triển khai thất bại

Các chỉ số có thể đo phải có ngưỡng trước khi chạy test. Chẳng hạn, nếu doanh nghiệp yêu cầu một giao dịch đạt p95 dưới 2 giây thì 2 giây phải được xác lập như tiêu chí nghiệp vụ hoặc SLO trước kiểm thử; không nên chạy xong rồi chọn ngưỡng phù hợp với kết quả.

Ngưỡng cụ thể không thể dùng chung cho mọi hệ thống. Một ứng dụng nội bộ với vài chục người sử dụng, hệ thống thương mại điện tử và nền tảng xử lý giao dịch thời gian thực có workload và hậu quả khi chậm hoàn toàn khác nhau. Điều cần thống nhất là cách đo và điều kiện pass/fail, không phải một con số “chuẩn” áp dụng cho tất cả.

Kiểm thử chức năng theo toàn bộ luồng nghiệp vụ

Functional testing cần trả lời một câu hỏi cụ thể: giải pháp có thực hiện đúng yêu cầu khi người dùng và các hệ thống khác tương tác với nó hay không?

Không nên giới hạn việc kiểm thử ở từng màn hình hoặc từng nút bấm. Một chức năng có thể hoạt động riêng lẻ nhưng toàn bộ quy trình vẫn thất bại do dữ liệu, trạng thái hoặc tích hợp giữa các thành phần.

Kiểm tra cả trường hợp đúng và trường hợp sai

Với mỗi nghiệp vụ quan trọng, doanh nghiệp nên xây dựng tối thiểu ba nhóm tình huống:

·         Happy path khi dữ liệu và thao tác đều hợp lệ

·         Negative path khi dữ liệu thiếu, sai hoặc người dùng thực hiện thao tác không được phép

·         Boundary case tại các giới hạn như số lượng tối đa, thời gian hết hạn, kích thước dữ liệu hoặc trạng thái chuyển tiếp

Ví dụ, kiểm thử một chức năng phê duyệt không chỉ dừng ở việc người có quyền bấm “Phê duyệt” thành công. Cần kiểm tra người không có quyền, yêu cầu đã hết hiệu lực, thao tác lặp lại, dữ liệu bị thay đổi giữa hai bước và trường hợp dịch vụ liên quan không phản hồi.

Kiểm tra tích hợp và tính toàn vẹn dữ liệu

Một giải pháp doanh nghiệp thường phụ thuộc vào API, hệ thống nhận dạng, ERP, CRM, cổng thanh toán, kho dữ liệu hoặc các dịch vụ bên thứ ba. Vì vậy, test cần kiểm tra cả:

·         Dữ liệu gửi và nhận có đúng cấu trúc

·         Mapping giữa các hệ thống có chính xác

·         Trạng thái có đồng bộ sau lỗi

·         Retry có tạo giao dịch trùng

·         Timeout được xử lý thế nào

·         Dữ liệu có bị mất hoặc ghi hai lần

·         Hệ thống có phục hồi đúng khi một dependency tạm thời ngừng hoạt động

Giá trị của kiểm thử chức năng nằm ở việc chứng minh kết quả nghiệp vụ cuối cùng đúng, không phải chỉ chứng minh từng thành phần kỹ thuật phản hồi thành công.

Kiểm thử hiệu năng bằng tải đại diện cho thực tế

Một hệ thống phản hồi nhanh với một tester chưa chứng minh được khả năng phục vụ hàng trăm hoặc hàng nghìn request đồng thời.

Performance testing cần xây dựng workload gần với cách hệ thống thực sự được sử dụng. Điều đó bao gồm tỷ lệ giữa các loại giao dịch, số người dùng đồng thời, kích thước dữ liệu, thời gian duy trì tải và các thời điểm tăng đột biến.

Các chỉ số nên được theo dõi đồng thời gồm:

·         Latency theo percentile như p50, p95 hoặc p99 thay vì chỉ dùng giá trị trung bình

·         Throughput theo giao dịch hoặc request trên một đơn vị thời gian

·         Error rate

·         Số phiên hoặc người dùng đồng thời

·         CPU, bộ nhớ, I/O, connection pool và các tài nguyên có khả năng bão hòa

·         Độ trễ của database và các dependency quan trọng

Giá trị trung bình có thể che mất trải nghiệm xấu của một nhóm người dùng. Chẳng hạn, average latency vẫn thấp nhưng p99 tăng mạnh khi tải cao cho thấy một phần request đang bị chậm đáng kể.

Phân biệt các loại kiểm thử tải

Load test xác minh hệ thống ở mức tải dự kiến. Stress test đẩy tải vượt mức bình thường để tìm giới hạn và quan sát cách hệ thống suy giảm. Spike test tạo sự gia tăng tải đột ngột. Soak hoặc endurance test duy trì hoạt động đủ lâu để phát hiện memory leak, resource leak hoặc hiện tượng giảm hiệu năng theo thời gian.

Doanh nghiệp không nhất thiết phải thực hiện tất cả các loại test với mọi giải pháp. Loại kiểm thử phải xuất phát từ rủi ro. Hệ thống chỉ chạy theo giờ hành chính có thể không cần cùng mức endurance test với dịch vụ hoạt động 24/7; trong khi nền tảng có traffic biến động mạnh cần đặc biệt quan tâm đến spike và khả năng autoscaling.

Quan trọng hơn, kết quả performance test phải được đọc theo quan hệ giữa tải – thời gian phản hồi – lỗi – tài nguyên. Nếu latency tăng vì CPU đã gần bão hòa, việc chỉ ghi nhận “p95 chưa đạt” không đủ; doanh nghiệp cần xác định bottleneck để biết hệ thống có thể mở rộng hay phải thay đổi kiến trúc.

Kiểm thử bảo mật và khả năng xử lý sự cố

Một giải pháp đáp ứng đúng chức năng vẫn có thể không đủ điều kiện sử dụng nếu người dùng truy cập được dữ liệu ngoài quyền hạn, dữ liệu nhạy cảm bị lộ hoặc hệ thống không kiểm soát được đầu vào nguy hiểm.

Đối với ứng dụng web, OWASP Application Security Verification Standard 5.0.0 cung cấp một cơ sở để kiểm tra các kiểm soát bảo mật kỹ thuật và xác định yêu cầu xác minh bảo mật. OWASP cho biết ASVS có thể được dùng như thước đo mức độ tin cậy, hướng dẫn phát triển kiểm soát và cơ sở xác định yêu cầu bảo mật trong mua sắm công nghệ.

Phạm vi nên ưu tiên các rủi ro trực tiếp của giải pháp:

·         Authentication

·         Authorization và kiểm soát truy cập theo vai trò

·         Quản lý session

·         Validation và xử lý input

·         Bảo vệ dữ liệu lưu trữ và truyền tải

·         Quản lý secret và credential

·         Logging và audit trail

·         Cấu hình bảo mật

·         API security

·         Các business logic có khả năng bị lợi dụng

Vulnerability scanning và penetration testing không phải hai khái niệm đồng nhất. Công cụ tự động giúp phát hiện một tập vấn đề kỹ thuật với tốc độ cao, nhưng các lỗi logic nghiệp vụ hoặc chuỗi khai thác phức tạp có thể cần kiểm tra thủ công. NIST SP 800-115 cũng xem kiểm thử bảo mật là quá trình gồm lập kế hoạch, thực hiện kiểm tra, phân tích phát hiện và xây dựng biện pháp giảm thiểu, đồng thời nhấn mạnh lợi ích lẫn giới hạn của từng kỹ thuật.

Doanh nghiệp cũng cần kiểm tra phản ứng khi sự cố xảy ra: dependency mất kết nối, database không sẵn sàng, credential hết hạn, tiến trình bị dừng hoặc một thành phần phải restart. Một hệ thống không bao giờ lỗi là giả định không thực tế; điều cần chứng minh là lỗi được giới hạn, ghi nhận và phục hồi theo cách có thể kiểm soát.

Chạy UAT và pilot trong điều kiện gần môi trường thật

Test kỹ thuật xác minh hệ thống hoạt động theo đặc tả. User Acceptance Testing xác minh một lớp khác: người dùng nghiệp vụ có thể sử dụng giải pháp để hoàn thành công việc thực tế hay không.

UAT nên được thực hiện bởi người đại diện cho nhóm sử dụng thật với dữ liệu, vai trò và quy trình đủ gần production. Các tình huống cần ưu tiên là những luồng tạo ra kết quả kinh doanh quan trọng, không phải cố gắng lặp lại toàn bộ test case của đội QA.

Ở bước này, doanh nghiệp cần quan sát những vấn đề khó phát hiện bằng automated test:

·         Người dùng có hiểu đúng trạng thái và thông báo

·         Luồng thao tác có phù hợp với quy trình thực tế

·         Dữ liệu đầu ra có đủ để tiếp tục công việc

·         Phân quyền có khớp với trách nhiệm thực tế

·         Các trường hợp ngoại lệ có đường xử lý rõ ràng

·         Bộ phận vận hành có đủ log và thông tin để điều tra lỗi

Nếu hậu quả triển khai cao, có thể thêm pilot hoặc rollout giới hạn: triển khai cho một nhóm người dùng, một đơn vị hoặc một tỷ lệ traffic trước khi mở rộng. Mục tiêu không phải kéo dài giai đoạn thử nghiệm mà là kiểm chứng các giả định chỉ xuất hiện khi hệ thống tiếp xúc với workload, dữ liệu và hành vi thật.

Pilot cũng cần tiêu chí dừng. Nếu lỗi nghiêm trọng, tỷ lệ lỗi vượt ngưỡng đã đặt hoặc quy trình nghiệp vụ bị gián đoạn, doanh nghiệp phải có khả năng thu hẹp hoặc rollback thay vì tiếp tục triển khai vì hệ thống đã “đi vào production”.

Chỉ go-live khi bằng chứng kiểm thử đáp ứng mức rủi ro chấp nhận

Quyết định đưa giải pháp vào sử dụng không nên dựa trên một tỷ lệ test case pass đơn lẻ. Hai hệ thống đều đạt 95% test case có thể mang mức rủi ro hoàn toàn khác nhau nếu 5% còn lại của một hệ thống chỉ là lỗi giao diện, còn hệ thống kia vẫn có lỗi phân quyền hoặc mất dữ liệu.

Go-live gate nên tổng hợp ít nhất các yếu tố sau:

·         Các yêu cầu nghiệp vụ bắt buộc đã đạt

·         Không còn defect thuộc nhóm chặn triển khai theo tiêu chí đã thống nhất

·         Các defect được chấp nhận có owner, biện pháp giảm thiểu và thời hạn xử lý

·         Performance test đạt workload và ngưỡng dịch vụ đã xác định

·         Các phát hiện bảo mật vượt mức rủi ro chấp nhận đã được xử lý

·         UAT đã được bên nghiệp vụ chịu trách nhiệm chấp thuận

·         Monitoring, logging và alerting đã sẵn sàng

·         Backup, recovery hoặc rollback đã được kiểm tra khi chúng là yêu cầu của hệ thống

·         Người chịu trách nhiệm có đủ bằng chứng để chấp nhận rủi ro còn lại

ISO/IEC 25010:2023 cho phép mô hình chất lượng được sử dụng để xác định mục tiêu kiểm thử, tiêu chí kiểm soát chất lượng và tiêu chí chấp nhận sản phẩm hoặc hệ thống thông tin. Điều này phù hợp với nguyên tắc thực tế: tiêu chí triển khai phải được xác lập từ yêu cầu chất lượng, sau đó kiểm thử tạo bằng chứng cho từng tiêu chí.

Không phải mọi defect đều buộc dự án dừng lại. Câu hỏi cần đặt ra là defect còn lại ảnh hưởng chức năng nào, xảy ra trong điều kiện nào, hậu quả ra sao, có biện pháp giảm thiểu hay không và ai có thẩm quyền chấp nhận rủi ro đó.

Kiểm thử trước khi đưa giải pháp công nghệ vào sử dụng là quá trình giảm bất định bằng bằng chứng. Doanh nghiệp cần bắt đầu từ tiêu chí đạt rõ ràng, sau đó kiểm tra chức năng và tích hợp, đo hiệu năng dưới workload thực tế, xác minh bảo mật, thực hiện UAT hoặc pilot và cuối cùng đánh giá rủi ro còn lại tại go-live gate.

Một giải pháp đủ điều kiện triển khai không phải là giải pháp “không có lỗi”, mà là giải pháp đã chứng minh được rằng các chức năng quan trọng hoạt động đúng, các chỉ số vận hành nằm trong ngưỡng được chấp nhận, rủi ro nghiêm trọng đã được xử lý và tổ chức có phương án quan sát, khôi phục hoặc rollback khi thực tế khác với giả định kiểm thử.

Doanh nghiệp nên bắt đầu kiểm thử giải pháp công nghệ từ đâu?

Bắt đầu bằng việc chuyển yêu cầu kinh doanh và kỹ thuật thành tiêu chí pass/fail có thể đo được. Sau đó mới thiết kế test case, dữ liệu, workload và môi trường kiểm thử. Nếu không có tiêu chí chấp nhận từ trước, kết quả test rất khó dùng làm căn cứ khách quan cho quyết định go-live.

Chỉ kiểm thử chức năng có đủ trước khi triển khai không?

Không. Functional test chứng minh hệ thống thực hiện đúng hành vi được yêu cầu nhưng không chứng minh hệ thống chịu được tải thực tế, đủ an toàn hoặc phù hợp với quy trình vận hành. Phạm vi cụ thể phụ thuộc rủi ro của từng giải pháp.

Performance test nên dùng chỉ số nào?

Nên kết hợp latency theo percentile như p95 hoặc p99, throughput, error rate, concurrency và mức sử dụng tài nguyên. Ngưỡng đạt cần lấy từ yêu cầu dịch vụ hoặc SLO của chính hệ thống thay vì áp dụng một con số chung cho mọi sản phẩm.

UAT khác gì với kiểm thử của đội QA?

QA chủ yếu xác minh hệ thống đáp ứng yêu cầu kỹ thuật và chức năng đã định nghĩa. UAT kiểm tra liệu người dùng nghiệp vụ có thể sử dụng hệ thống để hoàn thành quy trình và tạo ra kết quả mong muốn trong bối cảnh làm việc thực tế hay không.

Có phải phải sửa hết defect mới được go-live?

Không nhất thiết. Defect còn lại cần được đánh giá theo mức độ nghiêm trọng, khả năng xảy ra, tác động và biện pháp giảm thiểu. Những lỗi vượt mức rủi ro doanh nghiệp đã chấp nhận phải được xử lý trước khi triển khai; các lỗi khác chỉ nên được chấp nhận khi có người chịu trách nhiệm và kế hoạch xử lý rõ ràng.