Prince Kohli, Chủ tịch và Giám đốc Điều hành của Sauce Labs – Loạt Phỏng vấn

Prince Kohli, Chủ tịch và Giám đốc Điều hành của Sauce Labs, là một nhà điều hành công nghệ dày dạn kinh nghiệm, bao quát trí tuệ nhân tạo, phần mềm doanh nghiệp, điện toán đám mây, tự động hoá, mạng và an ninh mạng. Trước khi gia nhập Sauce Labs vào tháng 2 năm 2025, ông đã hơn sáu năm giữ vị trí Giám đốc Công nghệ (CTO) tại Automation Anywhere, nơi ông góp phần thúc đẩy các công nghệ tự động hoá dựa trên AI cho các doanh nghiệp lớn. Trước đó, Kohli từng là Phó Chủ tịch Cấp cao phụ trách Kỹ thuật tại ThoughtSpot và giữ các vai trò lãnh đạo cấp cao tại Ericsson, bao gồm giám sát các tổ chức R&D toàn cầu với hơn 10.000 kỹ sư. Ông cũng đã gần một thập kỷ làm việc tại Citrix, dẫn dắt các sáng kiến về nền tảng, mạng đám mây, kỹ thuật và vận hành. Ở giai đoạn đầu sự nghiệp, ông đồng sáng lập công ty an ninh ứng dụng Teros và từng là trưởng nhóm kỹ thuật tại SGI. Bên cạnh các vai trò điều hành, Kohli còn đóng góp vào các sáng kiến quản trị công nghệ thông qua Nhóm Quản trị AI Đạo đức và từng tham gia nhóm làm việc “Hệ thống và Công nghệ An toàn” của Diễn đàn Kinh tế Thế giới.

Sauce Labs là công ty cung cấp giải pháp chất lượng phần mềm và kiểm thử liên tục, cung cấp cho doanh nghiệp hạ tầng và công cụ để kiểm thử các ứng dụng web và di động trên nhiều trình duyệt, hệ điều hành, môi trường ảo và thiết bị thực. Nền tảng của công ty hỗ trợ các khả năng bao gồm kiểm thử tự động và thủ công, kiểm thử trực quan, phân phối ứng dụng di động, báo cáo lỗi, và việc tạo và phân tích kiểm thử dựa trên AI, đồng thời tích hợp với các quy trình liên tục tích hợp và triển khai. Sauce Labs ngày càng định vị công nghệ của mình quanh AURA, nền tảng Đảm bảo Phát hành Thống nhất AI (AI‑Unified Release Assurance), sử dụng các tác nhân AI để hỗ trợ tạo, thực thi và phân tích các bài kiểm thử đồng thời duy trì sự giám sát của con người trong suốt quá trình phát hành phần mềm. Công ty cho biết hạ tầng của mình đã hỗ trợ hơn 8,7 tỷ lần thực thi kiểm thử và hơn 300.000 người dùng doanh nghiệp, dựa trên gần hai thập kỷ dữ liệu kiểm thử đa nền tảng.

Trước khi gia nhập Sauce Labs, bạn đã dẫn dắt tự động hoá dựa trên AI tại Automation Anywhere và quản lý các tổ chức đám mây và kỹ thuật lớn tại các công ty như Ericsson và Citrix. Những trải nghiệm đó đã hình thành quan điểm của bạn về vấn đề chất lượng phần mềm như thế nào, và điều gì đã thuyết phục bạn đưa việc đảm bảo phát hành gốc AI thành ưu tiên trung tâm tại Sauce Labs?

Tại Ericsson và Citrix, tôi đã chứng kiến cách một lỗi phần mềm có thể lan nhanh và ảnh hưởng đến hạ tầng toàn cầu, gây ra những tác động nghiêm trọng về bảo mật, hoạt động của khách hàng, niềm tin và doanh thu. Automation Anywhere đã cho tôi thấy AI thay đổi tốc độ và cấu trúc công việc, và tôi nhận ra rằng việc kiểm thử phải được xây dựng lại để đáp ứng nhịp độ của phần mềm được tạo ra bởi AI. Sauce Labs đã tiên phong trong tự động hoá kiểm thử, vì vậy việc đảm bảo phát hành gốc AI là vấn đề lớn tiếp theo mà chúng tôi được thiết kế để giải quyết.

Nghiên cứu của Sauce Labs cho thấy 80% tổ chức đã truy vết một sự cố, gián đoạn hoặc lỗi ảnh hưởng tới khách hàng trong môi trường sản xuất đến mã được tạo ra bởi AI. Điều này chủ yếu chỉ ra điểm yếu trong mã do AI tạo ra, hay là các doanh nghiệp đang áp dụng công cụ lập trình AI mà không cập nhật quy trình kiểm thử và quản trị?

Con số 80% phản ánh một vấn đề trên toàn bộ hệ thống giao hàng phần mềm. Ngành AI đã thu hút hơn một nghìn tỷ đô la vốn tư nhân, phần lớn dựa trên việc AI làm cho doanh nghiệp trở nên năng suất hơn đáng kể. Tuy nhiên, việc tạo ra nhiều mã chỉ có giá trị nếu các công ty có thể tin tưởng vào chất lượng và bảo mật của nó trước khi đưa vào sản xuất.

Mã được tạo ra bởi AI có thể gây ra các lỗi tinh vi và vấn đề bảo mật, và các doanh nghiệp đang bị buộc phải đưa mã đó qua các quy trình kiểm thử và quản trị vốn đã gặp khó khăn trong việc bắt kịp. Điều này tạo ra một vấn đề thực thi trị giá hàng nghìn tỷ đô la: AI có thể tăng tốc tạo phần mềm, nhưng nếu không có một hệ thống đảm bảo phát hành hiện đại, nó cũng sẽ tăng tốc các lỗi. Mọi lỗi cuối cùng sẽ được phát hiện, vì vậy các công ty cần chắc chắn rằng chúng tìm ra lỗi trước khi khách hàng hoặc kẻ tấn công phát hiện.

Báo cáo cho biết các nhà phát triển đang tạo ra nhiều mã hơn 741% trong khi tốc độ phát hành chỉ tăng dưới 20%. Điều gì ngăn cản các hệ thống xác thực bắt kịp, và điểm nghẽn lớn nhất thường xuất hiện ở giai đoạn nào trong vòng đời phát triển phần mềm?

Việc tạo mã đã vượt xa tốc độ tạo và bảo trì các bài kiểm thử, cũng như việc phân tích chúng. Các điểm nghẽn lớn nhất thường xuất hiện sau khi mã đã được viết và cần được xác thực trong bối cảnh hành trình người dùng. Điều này thường rất phức tạp, thậm chí phức tạp hơn mã, vì nó phải tính đến các luồng đầu‑cuối bao phủ các hàm và đối tượng của mã, trong đó những thay đổi nhỏ về ngữ nghĩa ở một nơi có thể tạo ra những ảnh hưởng lớn ở hạ nguồn. Việc soạn thảo các bài kiểm thử sao cho chúng nắm bắt đúng và đầy đủ ý định của ứng dụng từ trước đến nay gần như không thể, đồng thời đòi hỏi một lượng công việc thủ công và bảo trì rất đáng kể. Hơn nữa, sau khi các bài kiểm thử chạy và có lỗi, các nhóm phải hiểu và chẩn đoán vấn đề, bao gồm quyết định liệu lỗi xuất phát từ sản phẩm hay từ một bài kiểm thử đã lỗi thời. Công việc này vẫn phụ thuộc mạnh vào việc xem xét thủ công và bối cảnh kỹ thuật.

Hơn một nửa các doanh nghiệp được khảo sát thừa nhận đã có ý thức phát hành phần mềm có lỗi nghiêm trọng, trong khi 66% cho biết họ đã hy sinh tiêu chuẩn chất lượng hoặc kiểm thử để đáp ứng thời hạn. Tại sao các tổ chức chấp nhận mức độ rủi ro này, và điều gì cần thay đổi để chất lượng phần mềm trở thành ưu tiên cấp doanh nghiệp thay vì chỉ là một bước kiểm tra cuối cùng của kỹ thuật?

Các tổ chức chấp nhận rủi ro vì mục tiêu phát hành thường gắn liền với cam kết ngay lập tức với khách hàng, doanh thu và sản phẩm, và chi phí của lỗi thường xuất hiện sau này ở nhiều bộ phận. Chất lượng chỉ trở thành ưu tiên kinh doanh khi các nhà lãnh đạo đo lường các sự cố trong môi trường sản xuất, tác động tới khách hàng, mức độ phơi bày bảo mật, chi phí sửa chữa và doanh thu bị trì hoãn cùng với tốc độ phát hành.

Sauce Labs đang định vị AURA như một nền tảng vòng khép kín, tự động soạn thảo, thực thi và phân tích các bài kiểm thử đồng thời học hỏi từ mỗi lần phát hành. Điều này khác biệt về mặt kỹ thuật và vận hành so với việc tạo kiểm thử hỗ trợ AI, kịch bản kiểm thử tự sửa, hoặc các công cụ tự động hoá khác mà các đội kỹ thuật đã sử dụng như thế nào?

Phần lớn các công cụ kiểm thử AI chỉ giải quyết một tác vụ cụ thể, chẳng hạn tạo một bài kiểm thử hoặc sửa chữa một locator bị hỏng. AURA kết nối toàn bộ quy trình bằng cách hiểu ý định của ứng dụng, soạn thảo và thực thi các bài kiểm thử, phân tích các lỗi và đưa hành vi sản xuất trở lại quá trình phát triển. Nó có thể tự động xử lý nhiều thay đổi và đưa con người vào quy trình khi ý nghĩa hoặc hành vi mong đợi của ứng dụng thay đổi. Ngoài ra, các bài kiểm thử mà AURA tạo ra đều ổn định, nghĩa là chúng không cần phải chỉnh sửa khi có những thay đổi không ảnh hưởng đến ngữ nghĩa trong ứng dụng, trình duyệt, thiết bị và các yếu tố tương tự. Cuối cùng, vì AURA tích hợp sẵn một đám mây thực thi kiểm thử, nó có thể gánh toàn bộ quy trình khỏi nhà phát triển hoặc đội ngũ kỹ thuật chất lượng.

AURA được thiết kế để xác minh phần mềm dựa trên “ý định kinh doanh”. Ý định này được định nghĩa và chuyển đổi thành các yêu cầu có thể kiểm thử như thế nào, ai chịu trách nhiệm phê duyệt, và nền tảng sẽ xử lý các yêu cầu mơ hồ, chưa hoàn thiện hoặc có khả năng diễn giải đa dạng ra sao?

Ý định kinh doanh xuất phát từ các yêu cầu sản phẩm, tiêu chí chấp nhận, quy tắc kinh doanh, hành trình người dùng và cách khách hàng thực tế sử dụng ứng dụng. Các nhà lãnh đạo sản phẩm xác định kết quả mong đợi, và các đội kỹ thuật và chất lượng dịch kết quả đó thành hành vi mà hệ thống có thể kiểm chứng. Khi các yêu cầu chưa hoàn thiện hoặc mơ hồ, AURA sẽ hiện ra sự không chắc chắn và yêu cầu phê duyệt của con người trước khi thay đổi kết quả dự kiến.

Sauce Labs báo cáo rằng các doanh nghiệp sử dụng AURA đã giảm 90% các sự cố trong môi trường sản xuất, rút ngắn chu kỳ phát hành 47% và thu hồi 38% năng lực kỹ thuật. Những kết quả này được đo lường như thế nào, trong khoảng thời gian triển khai nào, và tiêu chuẩn xác thực độc lập nào đã được dùng để tách biệt tác động của AURA so với các thay đổi tổ chức hoặc kỹ thuật khác?

Trong các triển khai doanh nghiệp, chúng tôi đo lường sự thay đổi về các sự cố trong môi trường sản xuất, tốc độ chu kỳ phát hành và năng lực kỹ thuật sau khi các đội triển khai AURA. Các triển khai đó đã ghi nhận hơn 90% giảm sự cố, rút ngắn chu kỳ phát hành 47% và thu hồi 38% năng lực kỹ thuật, với kết quả được xác thực độc lập. Các khách hàng như Walmart và Keller Williams cũng đã báo cáo những cải thiện đáng kể về tần suất phát hành, độ phủ kiểm thử và thời gian chu kỳ.

Nghiên cứu cho thấy 64% các tổ chức tăng số lượng nhân sự QA ngay cả khi các sự cố vẫn tiếp tục tăng. Tại sao các doanh nghiệp không thể giải quyết khoảng trống xác thực chỉ bằng cách tuyển thêm kiểm thử viên, và bạn dự đoán vai trò của các nhà phát triển, kỹ sư chất lượng và đội ngũ độ tin cậy site sẽ thay đổi như thế nào khi kiểm thử trở nên tự động hơn?

AI có thể tăng khối lượng mã nhanh hơn nhiều so với tốc độ tăng nhân sự kiểm thử của một công ty, và việc tuyển thêm người còn tạo ra nhiều bước chuyển giao và phối hợp hơn. Các nhà phát triển sẽ cần định nghĩa ý định một cách rõ ràng, các kỹ sư chất lượng sẽ tập trung nhiều hơn vào rủi ro, độ phủ và quản trị, còn các đội độ tin cậy site sẽ đưa hành vi sản xuất trở lại quy trình phát hành. Các tác nhân AI có thể xử lý việc thực thi và phân tích lặp đi lặp lại ở quy mô mà mô hình phát triển mới này yêu cầu.

Khi các tác nhân AI nhận trách nhiệm soạn thảo, chạy và diễn giải các bài kiểm thử, ở đâu con người phải giữ quyền quyết định? Những loại không chắc chắn, rủi ro bảo mật hoặc tác động tiềm năng tới khách hàng nào nên tự động dừng một bản phát hành hoặc kích hoạt việc xem xét của con người?

Con người phải giữ quyền quyết định cuối cùng về các bản phát hành, đặc biệt khi có yếu tố phán đoán, tác động khách hàng hoặc rủi ro kinh doanh. Các tác nhân AI có thể tự động hoá các nhiệm vụ kiểm thử tẻ nhạt, lặp lại và rõ ràng, nhưng con người nên phê duyệt các bản phát hành khi mã hoặc kết quả kiểm thử không thể được hiểu, giải thích hoặc tái tạo đầy đủ. Việc xem xét cũng nên bắt buộc khi các yêu cầu chưa rõ ràng, có khả năng xuất hiện lỗ hổng bảo mật, các thành phần bên thứ ba chưa được xác thực đầy đủ, hoặc khi các lỗi có thể ảnh hưởng đến doanh thu, dữ liệu nhạy cảm, trải nghiệm khách hàng hoặc các hoạt động quan trọng.

Trong những tình huống đó, hành vi không giải thích được, kết quả kiểm thử không nhất quán hoặc thiếu bằng chứng về mức độ sẵn sàng phát hành nên tự động dừng việc phát hành.

Chúng tôi đã chứng kiến các trường hợp ở khách hàng của mình, khi một bài kiểm thử có vẻ “khó ổn định”, cho kết quả không đồng nhất mà không có mẫu lỗi rõ ràng, thường bị bỏ qua. Tuy nhiên, quy trình quản trị chặt chẽ ở một số khách hàng đã yêu cầu thực hiện thẩm định, và với sự hỗ trợ của nền tảng của chúng tôi, họ đã truy vết được lỗi thời gian tinh vi nhưng quan trọng, một lỗi dựa trên thời gian có thể gây ra tác động nghiêm trọng nếu được phát hành, với chi phí rất cao.

Bạn cũng đã làm việc với Nhóm Quản trị AI Đạo đức và nhóm làm việc “Hệ thống và Công nghệ An toàn” của Diễn đàn Kinh tế Thế giới. Khi mã do AI tạo ra và kiểm thử tự động ngày càng gắn kết, các tiêu chuẩn quản trị nào doanh nghiệp cần thiết lập để đảm bảo việc tạo phần mềm nhanh hơn không tạo ra rủi ro hệ thống, bảo mật hoặc trách nhiệm mới?

Những gì AI tạo ra càng nhanh, lớp xác thực và quản trị càng phải mạnh mẽ. Lớp này bao gồm nhiều phần. Doanh nghiệp phải có ranh giới rõ ràng về những quyết định mà các tác nhân có thể tự động đưa ra, đồng thời yêu cầu xem xét của con người khi có sự không chắc chắn về ý định kinh doanh, bảo mật, tuân thủ hoặc thay đổi ngữ nghĩa đáng kể. Họ cũng cần khả năng truy xuất nguồn gốc các thay đổi của tác nhân, lý do thay đổi và bằng chứng hỗ trợ quyết định phát hành. Cuối cùng, tiêu chuẩn quản trị nên được đo lường bằng chất lượng và tính dự đoán của những gì đến môi trường sản xuất, chẳng hạn theo dõi cụ thể tần suất mã do AI tạo gây ra sự cố trong vòng 90 ngày sau khi phát hành, chứ không phải tốc độ AI tạo mã.

Cảm ơn bạn đã tham gia buổi phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm nên truy cập Sauce Labs.