Lợi nhuận:
- Có thể phân biệt nơi nào trí tuệ nhân tạo tiết kiệm thời gian thực trong quy trình QA và nơi nào các quyết định về chất lượng như 'sẵn sàng xuất bản' được giao cho con người, tùy thuộc vào mức độ rủi ro của nhiệm vụ
- Khả năng nhận biết nguy cơ vượt qua sai và thực hiện kỷ luật xác minh để kiểm tra mọi bài kiểm tra AI bằng cách cố tình phá mã
- Khả năng bảo vệ dữ liệu kiểm tra, dữ liệu cá nhân và khóa, đồng thời hình thành thói quen chỉ thực hiện kiểm tra bảo mật trong phạm vi được ủy quyền và cho mục đích phòng thủ.
Hãy xem xét một đêm phát hành. Hàng trăm cuộc thử nghiệm đã được thực hiện, tất cả đều được bật đèn xanh, nhóm cảm thấy nhẹ nhõm và phần mềm đã đi vào hoạt động. Sáng hôm sau, khách hàng báo màn hình thanh toán bị lỗi. Các bài kiểm tra đều có màu xanh nhưng anh ấy không thấy lỗi. Đây là cơn ác mộng ngấm ngầm nhất của nghề đảm bảo chất lượng (QA), tức là kỷ luật đảm bảo một cách có hệ thống rằng phần mềm có chất lượng mong muốn: bài kiểm tra phát sáng màu xanh lục nhưng thực tế không xác nhận bất cứ điều gì. Khi trí tuệ nhân tạo (AI - phần mềm trích xuất các mẫu từ dữ liệu lịch sử và tạo ra văn bản và mã) bước vào nghề này, sẽ có cả sự tăng tốc rất lớn và mức độ phóng đại chính xác của cơn ác mộng này. Lời hứa ban đầu của mô-đun này rất rõ ràng: AI là trợ lý thử nghiệm, người tạo kế hoạch chi tiết và nhân rộng ý tưởng; Bạn là người thử nghiệm, người đưa ra quyết định "phần mềm này đã sẵn sàng để phát hành chưa".
Trong bài học đầu tiên này, chúng ta sẽ tập trung vào kỷ luật chứ không phải công cụ. Bạn sẽ tìm hiểu xem AI tiết kiệm thời gian thực ở đâu trong quy trình QA, ở đâu nguy hiểm, tại sao cái gọi là "false-pass" màu xanh lá cây lừa đảo lại là rủi ro lớn nhất, cách xác minh từng đầu ra và dữ liệu nào bạn có thể cung cấp cho công cụ nào. Nếu không đặt nền móng này, các đơn vị tiếp theo sẽ vẫn ở trên không.
AI có ích ở đâu trong quá trình thử nghiệm?
Hãy chia công việc kiểm thử thành hai cụm lớn. Cụm đầu tiên: các công việc lặp đi lặp lại, có thể sản xuất được, phác thảo. Soạn thảo trường hợp kiểm thử từ một yêu cầu, liệt kê các điểm dừng, viết khung mã tự động hóa cho màn hình, chuyển trường hợp lỗi phức tạp thành báo cáo lỗi gọn gàng, tóm tắt hàng trăm dòng tệp nhật ký, trích xuất lược đồ từ phản hồi API. Trong những nhiệm vụ này, AI giảm thiểu phút xuống giây và không bị mệt mỏi.
Cụm thứ hai: các quyết định mà kết quả của nó là chất lượng, sự tin cậy và trách nhiệm. Các quyết định như “phiên bản này có thể hoạt động được không”, “lỗi này có nghiêm trọng hay có thể bị hoãn lại không”, “phạm vi thử nghiệm này có đủ không”, “tình huống này có nắm bắt được rủi ro thực sự của người dùng không”, v.v. yêu cầu bối cảnh, kiến thức về sản phẩm và trách nhiệm. Tại đây, AI tạo ra các tùy chọn, bản nháp — nhưng bạn quyết định “đạt/không đạt” và “đi/không đi”.
Hãy làm rõ sự khác biệt trong một câu: AI mạnh ở "những tình huống nào có thể được kiểm tra và cách viết mã để kiểm tra nó"; Quyết định là của bạn khi đặt ra câu hỏi "Phần mềm này có thực sự hoạt động không và ai đảm bảo cho nó?"
Mẹo: Trước khi giao công việc cho AI, hãy hỏi: “Điều gì xảy ra nếu kết quả đầu ra này sai và tôi không nhận thấy?” Nếu câu trả lời là “Tôi sẽ mất vài phút”, hãy ủy thác một cách dễ dàng. Nếu câu trả lời là "phần mềm bị lỗi hoạt động", hãy để AI tạo bản nháp và bạn đưa ra quyết định cũng như xác minh.
Vượt qua sai: rủi ro số một của AI trong QA
Khi bài kiểm tra sáng lên màu xanh lục, điều đó có thể có nghĩa là hai điều: phần mềm thực sự hoạt động chính xác hoặc nó không thấy lỗi vì bài kiểm tra được viết không chính xác. Trường hợp thứ hai được gọi là vượt qua sai - bài kiểm tra cho biết "đạt" nhưng thực tế không xác nhận bất cứ điều gì. Rủi ro này tăng lên đáng kể trong các bài kiểm tra được thực hiện bằng AI, vì AI rất thành công trong việc viết các bài kiểm tra trôi chảy, mượt mà nhưng trống rỗng.
Ba dạng giả phổ biến nhất là: (1) Kiểm tra mà không có xác nhận - mã chạy, không chứa xác nhận, luôn vượt qua. (2) Kiểm tra tự xác minh - giá trị mong đợi của kiểm tra được tính từ đầu ra của mã được kiểm tra; Nghĩa là, bất kể mã nào tạo ra, quá trình kiểm tra đều chấp nhận là "chính xác". (3) Kiểm tra để xác minh điều sai - khẳng định tồn tại, nhưng nó kiểm tra điều gì đó tầm thường (ví dụ: "phản hồi không phải là rỗng"), không phải quy tắc kinh doanh thực tế.
Thận trọng: Bảng thử nghiệm màu xanh lá cây không phải là bằng chứng về chất lượng; Tốt nhất là nó báo "các điều khiển mà chúng tôi đã viết hiện không bị hỏng". Đừng an ủi khi thấy bài kiểm tra mà AI đưa ra "vượt qua" - câu hỏi thực sự là: liệu bài kiểm tra này có chuyển sang màu đỏ nếu tôi cố tình phá mã không? Nếu nó không quay thì bài kiểm tra đó là một vật trang trí.
Quy tắc vàng được lặp lại trong suốt mô-đun này: kiểm tra mọi bài kiểm tra AI bằng cách cố tình phá mã. Nếu bài kiểm tra vẫn xanh thì bài kiểm tra đó không hoạt động. (Chúng ta sẽ đào sâu ý tưởng này dưới dạng thử nghiệm đột biến trong bài 10.)
Kỷ luật xác minh: ba bước
AI nói một cách tự tin; Điều đó không có nghĩa là nó đúng. Phát triển phản xạ ba bước để áp dụng cho mọi kết quả:
- Hãy buộc nó vào yêu cầu. Mọi trường hợp thử nghiệm và khẳng định rằng AI tạo ra phải dựa trên yêu cầu thực tế hoặc tiêu chí chấp nhận (các điều kiện mà một công việc phải đáp ứng để được coi là "hoàn thành"). “Kịch bản này xác nhận quy tắc nào?” hỏi.
- Xem màu đỏ. Chạy thử nghiệm được tạo một lần, phá mã. Nếu nó không chuyển sang màu đỏ, bài kiểm tra không hợp lệ. Đây là bước không thể thương lượng trong thử nghiệm AI.
- Chuyển nó qua bộ lọc ngữ cảnh. Kết quả đầu ra có khớp với những gì bạn biết về hành vi sản phẩm, kiến trúc, luồng người dùng thực tế không? Kiến thức về miền của bạn là bộ lọc cuối cùng.
Quyền riêng tư và bảo mật dữ liệu: cái gì sẽ đi đâu?
Dữ liệu bạn làm việc trong môi trường thử nghiệm thường nhạy cảm: hồ sơ khách hàng thực, bản sao cơ sở dữ liệu sản xuất, khóa API, địa chỉ hệ thống nội bộ, các tính năng chưa được công bố. Thực hiện phân loại đơn giản: Dữ liệu mở (được ghi lại, có sẵn công khai) có thể xâm nhập vào bất kỳ phương tiện nào. Dữ liệu nội bộ (đoạn mã nguồn, tài liệu nội bộ) chỉ dành cho các công cụ được cơ quan phê duyệt. Dữ liệu bí mật (dữ liệu khách hàng thực, thông tin nhận dạng, chi tiết về lỗ hổng, khóa) chỉ được đưa vào các công cụ đã hợp đồng của tổ chức, những công cụ này không được đưa vào đào tạo mô hình, tốt nhất là được che giấu.
Có một giới hạn bổ sung trong bối cảnh kiểm tra bảo mật: mọi thứ học được trong mô-đun này đều nhằm mục đích phòng thủ — để kiểm tra chính thức tính bảo mật của sản phẩm của chính bạn. Sử dụng AI để xâm nhập vào hệ thống của người khác mà không được phép, vũ khí hóa các lỗ hổng thực sự hoặc kiểm tra một hệ thống mà bạn không có thẩm quyền là hành vi phi đạo đức và tội phạm. Sẽ không có thử nghiệm mang tính xúc phạm nào được thực hiện mà không được phép (phạm vi và sự cho phép).
Mẹo: Sử dụng dữ liệu thử nghiệm tổng hợp (được sản xuất nhân tạo) thay vì dữ liệu khách hàng thực. Yêu cầu AI “tạo dữ liệu thử nghiệm thực tế nhưng hoàn toàn hư cấu” vừa bảo vệ quyền riêng tư vừa đa dạng hóa các trường hợp khó khăn.
ba trường hợp nhỏ
Trường hợp 1 - Tiết kiệm thời gian đúng chỗ. Người thử nghiệm của nhóm Ekomerce đã dành 6 giờ để tạo kịch bản thử nghiệm theo cách thủ công từ tài liệu yêu cầu dài 30 trang cho mỗi bản phát hành. Anh ta đưa tài liệu (phần không chứa bí mật thương mại) cho YZ và yêu cầu soạn thảo kịch bản có cấu trúc; Thời gian giảm xuống còn 90 phút. Anh ấy đã dành thời gian tiết kiệm được để tự mình xác minh và bổ sung các trường hợp cạnh của quy tắc kinh doanh mà AI đã bỏ sót. AI loại bỏ công việc lặp đi lặp lại, để lại sự phán xét cho con người.
Trường hợp 2 - Bắt đường chuyền giả. Một nhà phát triển đã yêu cầu AI viết 12 bài kiểm tra đơn vị cho một chức năng tính toán; tất cả chúng đều có màu xanh lá cây. Người thử nghiệm đã thực hiện bước "nhìn thấy màu đỏ": cố tình thay đổi dấu cộng bên trong hàm thành phép nhân. Chỉ có 3 trong số 12 bài kiểm tra trả về màu đỏ. 9 bài kiểm tra còn lại không đưa ra xác nhận thực sự nào; Nó chỉ báo "nó không báo lỗi". 9 bài kiểm tra trang trí đã bị xóa và thay vào đó là 5 bài kiểm tra thực tế.
Trường hợp 3 - Trở về từ vi phạm quyền riêng tư. Một thực tập sinh đã dán nhật ký lỗi chứa email thực của khách hàng và bốn chữ số cuối của thẻ từ cơ sở dữ liệu sản xuất vào một công cụ công cộng và nói "giải thích lỗi này". Lãnh đạo QA đã can thiệp: đây là dữ liệu cá nhân nằm ngoài tầm kiểm soát và vi phạm KVKK (Luật bảo vệ dữ liệu cá nhân). Công việc tương tự được thực hiện trên một phương tiện đã được tổ chức phê duyệt, che giấu các khu vực cá nhân và chỉ để lại dấu vết ngăn xếp.
Bốn mẫu có thể sao chép
1) Đánh giá mức độ phù hợp công việc:
Vai trò của bạn: lãnh đạo QA cấp cao. Tôi sẽ mô tả công việc kiểm thử cho bạn. Hãy cho tôi biết (1) liệu công việc này là công việc soạn thảo/phân tích có thể được ủy quyền một cách an toàn cho AI hay là quyết định chất lượng mà con người phải đưa ra, (2) chi phí tiềm ẩn của kết quả đầu ra không chính xác, (3) việc xác minh tôi nên thực hiện trước khi ủy quyền. Công việc: [chèn công việc vào đây]
2) Điều khiển giả thông qua:
Hãy xem bài kiểm tra dưới đây. Hãy cho tôi biết: - Thử nghiệm này xác nhận hành vi nào? (một câu)- Làm cách nào để phá mã đang được kiểm tra để bài kiểm tra chuyển sang màu ĐỎ? - Có điểm yếu nào có thể khiến bài kiểm tra này luôn vượt qua (thiếu xác nhận, tự xác thực, kiểm tra tầm thường)?Kiểm tra: [dán kiểm tra tại đây]
3) Kiểm tra kiểm soát che giấu dữ liệu:
Nhật ký/dữ liệu tôi sẽ cung cấp cho bạn có thể chứa các trường cá nhân hoặc bí mật (e-mail, tên, thẻ, chìa khóa, địa chỉ nội bộ). Đầu tiên, liệt kê các trường cần được che dấu; Tôi sẽ che nó và gửi lại. Đừng phân tích nó như nó vốn có.
4) Tạo dữ liệu thử nghiệm tổng hợp:
Tạo 20 hàng dữ liệu thử nghiệm thực tế, hoàn toàn hư cấu cho [cấu trúc trường sau]. Không sử dụng dữ liệu cá nhân/tổ chức thực. Cũng bao gồm các trường hợp cạnh: khoảng trống, văn bản quá dài, giá trị giới hạn, định dạng không hợp lệ.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Viết bài kiểm tra trên mã này."
Mạnh: "Tính toán điều này Viết bài kiểm tra đơn vị cho chức năng giảm giá. Tiêu chí chấp nhận cho chức năng: giảm giá 10% trên 1000 TL, giảm giá 20% trên 5000 TL; số tiền âm sẽ gây ra lỗi. Chỉ định bằng dòng nhận xét quy tắc bạn đang xác thực cho mỗi thử nghiệm. Kiểm tra các giá trị giới hạn (999, 1000, 1001, 5000, 0, -1) riêng biệt. Sử dụng các xác nhận thực sẽ chuyển sang màu đỏ nếu Tôi phá mã; trống hoặc không viết khẳng định tầm thường."
Lời nhắc mạnh mẽ; Nó cung cấp các tiêu chí chấp nhận, giá trị giới hạn, kỳ vọng xác thực và hướng dẫn chống giả mạo rõ ràng. Dấu nhắc yếu mời AI viết bài kiểm tra trang trí.
Những lỗi thường gặp
- Niềm tin xanh. Nghĩ rằng vượt qua bài kiểm tra là bằng chứng. Câu hỏi thực sự là: nó có chuyển sang màu đỏ khi bạn phá mã không?
- Yêu cầu kiểm tra mà không đưa ra bất kỳ lý do gì. AI tạo ra các bài kiểm tra chung chung, thường vô dụng mà không biết cần phải xác minh điều gì.
- Bỏ qua xác minh. Nói "AI viết ra thì chắc là đúng". Trách nhiệm thuộc về người sử dụng đầu ra.
- Dán dữ liệu thực/nhạy cảm vào công cụ. Làm việc với dữ liệu sản xuất, chìa khóa hoặc dữ liệu cá nhân.
- Kiểm tra bảo mật trái phép. Cố gắng thử nghiệm tấn công mà không có phạm vi và sự cho phép.
- Sử dụng AI để ủy quyền ra quyết định. Đặt câu hỏi "Phiên bản này có thể được phát hành không?" tới AI và ghi câu trả lời vào chữ ký.
Tóm lại
AI là trợ thủ đắc lực trong quy trình QA giúp tăng tốc công việc lặp đi lặp lại và hiệu quả; Nhưng trách nhiệm quyết định chất lượng thuộc về con người. Rủi ro số một của AI trong nghề này là giả đậu: các bài kiểm tra màu xanh lá cây trông gọn gàng nhưng không xác nhận được gì. Kiểm tra mọi bài kiểm tra AI bằng cách cố tình phá mã; Nếu nó không chuyển sang màu đỏ thì bài kiểm tra đó là một vật trang trí. Buộc nó theo yêu cầu, xem màu đỏ, chuyển nó qua bộ lọc ngữ cảnh. Che giấu dữ liệu bí mật, chỉ thực hiện kiểm tra bảo mật cho các mục đích được ủy quyền và phòng thủ.
Nhiệm vụ ứng dụng
Thực hiện 5 bài kiểm tra đơn vị do AI tạo (hoặc do AI tạo) từ dự án của riêng bạn. Đối với mỗi: (1) viết ra một câu hành vi mà nó xác minh, (2) cố tình phá vỡ và chạy mã đang được kiểm tra và lưu ý số lượng mã chuyển sang màu đỏ, (3) đánh dấu những mã không chuyển sang màu đỏ là "kiểm tra trang trí" và viết lại chúng với xác nhận thực sự. Đặt kết quả vào một bảng: tên kiểm tra/quy tắc được xác minh/có bị hỏng khi bị hỏng không/hành động.
danh sách kiểm tra
- [ ] Trước khi bàn giao công việc, tôi đặt ra câu hỏi “nếu sai sót tôi sẽ mất gì?”
- [ ] Tôi đã kiểm tra mọi bài kiểm tra AI bằng cách phá mã; Tôi đã thay cái không chuyển sang màu đỏ bằng cái thử thật.
- [ ] Tôi đã liên kết các trường hợp thử nghiệm với tiêu chí chấp nhận/yêu cầu thực tế.
- [ ] Tôi đã che giấu dữ liệu thực/nhạy cảm mà không đưa nó vào công cụ; Tôi đã sử dụng dữ liệu tổng hợp nếu có thể.
- [ ] Tôi chỉ xem xét việc kiểm tra bảo mật trong thẩm quyền và nhằm mục đích phòng thủ.
- [ ] Tôi để lại quyết định "liệu phiên bản có được phát hành hay không" cho chính tôi chứ không phải cho AI.