Prince Kohli, ประธานและซีอีโอของ Sauce Labs – ชุดสัมภาษณ์

Prince Kohli, ประธานและซีอีโอของ Sauce Labs, เป็นผู้บริหารเทคโนโลยีที่มีประสบการณ์ยาวนานครอบคลุมปัญญาประดิษฐ์, ซอฟต์แวร์องค์กร, คลาวด์คอมพิวติ้ง, ระบบอัตโนมัติ, เครือข่าย, และความปลอดภัยไซเบอร์. ก่อนเข้าร่วม Sauce Labs ในเดือนกุมภาพันธ์ 2025, เขาใช้เวลามากกว่าหกปีในตำแหน่งประธานเจ้าหน้าที่เทคโนโลยีของ Automation Anywhere, ซึ่งเขามีส่วนช่วยพัฒนาเทคโนโลยีระบบอัตโนมัติที่ขับเคลื่อนด้วย AI สำหรับองค์กรขนาดใหญ่. ก่อนหน้านั้น, Kohli ดำรงตำแหน่งรองประธานฝ่ายวิศวกรรมที่ ThoughtSpot และดำรงตำแหน่งผู้นำระดับสูงที่ Ericsson, รวมถึงการดูแลองค์กรวิจัยและพัฒนาระดับโลกที่มีวิศวกรมากกว่า 10,000 คน. เขายังใช้เวลาประมาณหนึ่งทศวรรษที่ Citrix โดยเป็นผู้นำโครงการแพลตฟอร์ม, คลาวด์เน็ตเวิร์ค, วิศวกรรม, และการดำเนินงาน. ในช่วงต้นของอาชีพ, เขาเป็นผู้ร่วมก่อตั้งบริษัทความปลอดภัยแอปพลิเคชัน Teros และทำงานเป็นหัวหน้าฝ่ายเทคนิคที่ SGI. นอกเหนือจากบทบาทผู้บริหาร, Kohli มีส่วนร่วมในโครงการกำกับดูแลเทคโนโลยีผ่าน Ethical AI Governance Group และเคยเป็นสมาชิกของกลุ่มทำงาน Safe Systems and Technologies ของ World Economic Forum.

Sauce Labs เป็นบริษัทด้านคุณภาพซอฟต์แวร์และการทดสอบต่อเนื่องที่ให้โครงสร้างพื้นฐานและเครื่องมือแก่องค์กรสำหรับการทดสอบแอปพลิเคชันเว็บและมือถือบนหลายเบราว์เซอร์, ระบบปฏิบัติการ, สภาพแวดล้อมเสมือน, และอุปกรณ์จริง. แพลตฟอร์มของบริษัทรองรับความสามารถต่าง ๆ เช่น การทดสอบอัตโนมัติและด้วยมือ, การทดสอบแบบภาพ, การจัดจำหน่ายแอปมือถือ, การรายงานข้อผิดพลาด, และการสร้างและวิเคราะห์การทดสอบด้วย AI, พร้อมผสานรวมกับกระบวนการ CI/CD ที่เป็นมาตรฐาน. Sauce Labs กำลังเน้นเทคโนโลยีของตนรอบ AURA, แพลตฟอร์ม AI-Unified Release Assurance, ซึ่งใช้เอเจนต์ AI ช่วยสร้าง, ดำเนิน, และวิเคราะห์การทดสอบโดยยังคงมีการควบคุมจากมนุษย์ตลอดกระบวนการปล่อยซอฟต์แวร์. บริษัทระบุว่าโครงสร้างพื้นฐานของตนได้สนับสนุนการดำเนินการทดสอบมากกว่า 8.7 พันล้านครั้งและผู้ใช้ระดับองค์กรกว่า 300,000 ราย, โดยอิงจากข้อมูลการทดสอบข้ามแพลตฟอร์มเกือบสองทศวรรษ.

ก่อนเข้าร่วม Sauce Labs, คุณได้เป็นผู้นำการอัตโนมัติที่ขับเคลื่อนด้วย AI ที่ Automation Anywhere และจัดการองค์กรคลาวด์และวิศวกรรมระดับใหญ่ในบริษัทต่าง ๆ เช่น Ericsson และ Citrix. ประสบการณ์เหล่านี้มีผลต่อมุมมองของคุณต่อปัญหาคุณภาพซอฟต์แวร์อย่างไร, และอะไรทำให้คุณตัดสินใจทำให้ AI-native release assurance เป็นลำดับสำคัญหลักที่ Sauce Labs?

ที่ Ericsson และ Citrix, ฉันได้เห็นว่าข้อบกพร่องของซอฟต์แวร์สามารถแพร่กระจายอย่างรวดเร็วและส่งผลกระทบต่อโครงสร้างพื้นฐานทั่วโลก, ทำให้เกิดผลกระทบอย่างใหญ่ต่อความปลอดภัย, การดำเนินงานของลูกค้าและความเชื่อมั่น, รวมถึงรายได้. Automation Anywhere ทำให้ฉันเห็นว่า AI เปลี่ยนแปลงความเร็วและโครงสร้างของการทำงาน, และชัดเจนว่าการทดสอบต้องถูกสร้างใหม่ให้สอดคล้องกับความเร็วของซอฟต์แวร์ที่สร้างโดย AI. Sauce Labs เป็นผู้บุกเบิกการอัตโนมัติการทดสอบ, ดังนั้น AI-native release assurance คือปัญหาใหญ่ต่อไปที่เราถูกสร้างมาเพื่อแก้ไข.

การวิจัยของ Sauce Labs พบว่า 80% ขององค์กรสามารถสืบค้นเหตุการณ์การผลิต, การหยุดทำงาน, หรือข้อบกพร่องที่ส่งผลต่อลูกค้าให้เกิดจากโค้ดที่สร้างโดย AI. สิ่งนี้บ่งชี้ว่าปัญหาหลักอยู่ที่ความอ่อนแอของโค้ดที่ AI สร้างขึ้นหรือว่าองค์กรนำเครื่องมือเขียนโค้ด AI ไปใช้โดยไม่อัปเดตกระบวนการทดสอบและการกำกับดูแลของตน?

ตัวเลข 80% ชี้ให้เห็นปัญหาในระบบการส่งมอบซอฟต์แวร์ทั้งหมด. อุตสาหกรรม AI ได้รับเงินทุนส่วนบุคคลมากกว่าหนึ่งล้านล้านดอลลาร์, ส่วนใหญ่ตั้งอยู่บนสมมติฐานว่า AI จะทำให้ธุรกิจมีประสิทธิภาพเพิ่มขึ้นอย่างมหาศาล. แต่การสร้างโค้ดมากขึ้นจะสร้างคุณค่าได้ก็ต่อเมื่อบริษัทมั่นใจในคุณภาพและความปลอดภัยของโค้ดก่อนนำเข้าสู่การผลิต.

โค้ดที่สร้างโดย AI สามารถทำให้เกิดบั๊กและปัญหาความปลอดภัยที่ละเอียดอ่อนได้และองค์กรต้องผลักดันโค้ดนั้นผ่านกระบวนการทดสอบและการกำกับดูแลที่กำลังต่อสู้กับความเร็วอยู่แล้ว. สิ่งนี้สร้างปัญหาการดำเนินการมูลค่าหนึ่งล้านล้านดอลลาร์: AI สามารถเร่งการสร้างซอฟต์แวร์, แต่หากไม่มีการรับประกันการปล่อยที่ทันสมัย, มันก็จะเร่งการเกิดข้อบกพร่องได้เช่นกัน. ทุกบั๊กในที่สุดจะถูกพบ, ดังนั้นบริษัทต้องแน่ใจว่าพบก่อนที่ลูกค้าหรือผู้โจมตีจะพบ.

รายงานระบุว่าผู้พัฒนากำลังผลิตโค้ดเพิ่มขึ้น 741% ในขณะที่ความเร็วของการปล่อยเพิ่มขึ้นน้อยกว่า 20%. สิ่งใดเป็นอุปสรรคที่ทำให้ระบบการตรวจสอบไม่ทัน, และจุดคอขวดที่ใหญ่ที่สุดมักเกิดขึ้นที่ส่วนใดของวงจรการพัฒนาซอฟต์แวร์?

การสร้างโค้ดได้ก้าวหน้าไกลเกินกว่าการสร้าง, การบำรุงรักษา, และการวิเคราะห์การทดสอบ. จุดคอขวดที่ใหญ่ที่สุดมักปรากฏหลังจากโค้ดถูกเขียนแล้วและต้องได้รับการตรวจสอบในบริบทของการเดินทางของผู้ใช้. สิ่งนี้มักซับซ้อนมาก, บางครั้งซับซ้อนกว่าตัวโค้ดเอง, เนื่องจากต้องคำนึงถึงเส้นทางต้นถึงปลายที่ครอบคลุมฟังก์ชันและอ็อบเจ็กต์ของโค้ด, โดยการเปลี่ยนแปลงเล็กน้อยในความหมายที่หนึ่งอาจสร้างผลกระทบใหญ่ต่อส่วนต่อไป. การเขียนการทดสอบให้จับเจตนาของแอปพลิเคชันอย่างถูกต้องและครบถ้วนโดยทั่วไปเป็นเรื่องเกือบเป็นไปไม่ได้, และต้องใช้แรงงานและการบำรุงรักษามืออย่างมาก. นอกจากนี้, หลังจากการทดสอบทำงานและพบความล้มเหลว, ทีมต้องเข้าใจและวินิจฉัยปัญหา รวมถึงตัดสินใจว่าความล้มเหลวมาจากผลิตภัณฑ์หรือการทดสอบที่ล้าสมัย. งานนี้ยังคงพึ่งพาการตรวจสอบด้วยมือและบริบททางวิศวกรรมอย่างมาก.

มากกว่ากึ่งขององค์กรที่สำรวจยอมรับว่าตั้งใจปล่อยซอฟต์แวร์ที่มีข้อบกพร่องสำคัญ, ในขณะที่ 66% ระบุว่าพวกเขาได้ลดมาตรฐานคุณภาพหรือการทดสอบเพื่อให้ทันกำหนดเวลา. ทำไมองค์กรจึงยอมรับความเสี่ยงระดับนี้, และอะไรต้องเปลี่ยนแปลงเพื่อให้คุณภาพซอฟต์แวร์กลายเป็นลำดับความสำคัญระดับธุรกิจแทนที่จะเป็นเพียงจุดตรวจสอบสุดท้ายของวิศวกรรม?

องค์กรยอมรับความเสี่ยงเพราะเป้าหมายการปล่อยเชื่อมโยงกับความต้องการของลูกค้า, รายได้, และข้อผูกมัดของผลิตภัณฑ์ในทันที, และค่าใช้จ่ายจากข้อบกพร่องมักปรากฏในภายหลังในหลายทีม. คุณภาพจะกลายเป็นลำดับความสำคัญทางธุรกิจเมื่อผู้นำวัดเหตุการณ์การผลิต, ผลกระทบต่อผู้ใช้, ความเสี่ยงด้านความปลอดภัย, ค่าใช้จ่ายในการทำซ้ำ, และรายได้ที่ล่าช้า พร้อมกับความเร็วในการปล่อย.

Sauce Labs กำลังวางตำแหน่ง AURA เป็นแพลตฟอร์มปิดวงจรที่สร้าง, ดำเนิน, และวิเคราะห์การทดสอบพร้อมเรียนรู้จากแต่ละการปล่อย. สิ่งนี้แตกต่างเชิงเทคนิคและการปฏิบัติอย่างไรจากการสร้างการทดสอบด้วย AI, สคริปต์การทดสอบที่ซ่อมแซมอัตโนมัติ, หรือเครื่องมืออัตโนมัติอื่น ๆ ที่ทีมวิศวกรรมใช้อยู่แล้ว?

เครื่องมือทดสอบ AI ส่วนใหญ่มุ่งเน้นที่งานเฉพาะ, เช่น การสร้างการทดสอบหรือการซ่อมแซมตัวระบุตำแหน่งที่เสีย. AURA เชื่อมต่อกระบวนการทั้งหมดโดยเข้าใจเจตนาของแอปพลิเคชัน, สร้างและดำเนินการทดสอบ, วิเคราะห์ความล้มเหลว, และส่งพฤติกรรมการผลิตกลับสู่การพัฒนา. มันสามารถจัดการการเปลี่ยนแปลงหลายอย่างโดยอัตโนมัติและนำคนเข้ามาในกระบวนการเมื่อความหมายหรือพฤติกรรมที่คาดหวังของแอปพลิเคชันเปลี่ยนแปลง. นอกจากนี้, การทดสอบที่มันสร้างขึ้นมีความเสถียร, หมายความว่าไม่จำเป็นต้องแก้ไขเมื่อเกิดการเปลี่ยนแปลงที่ไม่กระทบต่อความหมายในแอปพลิเคชัน, เบราว์เซอร์, อุปกรณ์ ฯลฯ. สุดท้าย, เนื่องจาก AURA ฝังคลาวด์การดำเนินการทดสอบไว้ภายในตัวเอง, มันจึงสามารถถ่ายโอนกระบวนการทั้งหมดออกจากนักพัฒนาหรือทีมวิศวกรรมคุณภาพได้.

AURA ถูกออกแบบมาเพื่อยืนยันซอฟต์แวร์ตาม “เจตนาทางธุรกิจ”. เจตนานั้นถูกกำหนดและแปลเป็นข้อกำหนดที่สามารถทดสอบได้อย่างไร, ใครเป็นผู้รับผิดชอบในการอนุมัติ, และแพลตฟอร์มจัดการกับข้อกำหนดที่คล ambiguous, incomplete, หรือเปิดให้ตีความอย่างไร?

เจตนาทางธุรกิจมาจากข้อกำหนดของผลิตภัณฑ์, เกณฑ์การยอมรับ, กฎทางธุรกิจ, การเดินทางของผู้ใช้, และวิธีที่ลูกค้าใช้งานแอปพลิเคชันจริง. ผู้นำผลิตภัณฑ์กำหนดผลลัพธ์ที่คาดหวัง, และทีมวิศวกรรมและคุณภาพแปลงผลลัพธ์นั้นเป็นพฤติกรรมที่ระบบสามารถตรวจสอบได้. เมื่อข้อกำหนดไม่ครบหรือคลุมเครือ, AURA ควรแสดงความไม่แน่นอนและขอการอนุมัติจากมนุษย์ก่อนที่จะเปลี่ยนผลลัพธ์ที่คาดหวัง.

Sauce Labs รายงานว่าองค์กรที่ใช้ AURA มีเหตุการณ์การผลิตลดลง 90%, รอบการปล่อยเร็วขึ้น 47%, และกู้คืนความจุวิศวกรรมได้ 38%. ผลลัพธ์เหล่านี้วัดอย่างไร, ในช่วงระยะเวลาการปรับใช้เท่าใด, และมีการตรวจสอบอิสระใดที่ใช้เพื่อแยกผลกระทบของ AURA จากการเปลี่ยนแปลงองค์กรหรือวิศวกรรมอื่น ๆ?

ในการปรับใช้ระดับองค์กร, เราวัดการเปลี่ยนแปลงของเหตุการณ์การผลิต, ความเร็วของรอบการปล่อย, และความจุของวิศวกรรมหลังจากทีมนำ AURA ไปใช้. การปรับใช้เหล่านั้นพบว่ามีเหตุการณ์การผลิตลดลงมากกว่า 90%, รอบการปล่อยเร็วขึ้น 47%, และความจุวิศวกรรมกู้คืน 38%, โดยผลลัพธ์ได้รับการตรวจสอบอย่างอิสระ. ลูกค้าเช่น Walmart และ Keller Williams ยังรายงานว่ามีการเพิ่มขึ้นอย่างมีนัยสำคัญในความถี่การปล่อย, ความครอบคลุมของการทดสอบ, และเวลารอบการทำงาน.

การวิจัยพบว่า 64% ขององค์กรเพิ่มจำนวนบุคลากรด้านการรับรองคุณภาพแม้เหตุการณ์ยังคงเพิ่มขึ้น. ทำไมองค์กรไม่สามารถแก้ช่องว่างการตรวจสอบได้โดยเพียงจ้างผู้ทดสอบเพิ่ม, และคุณคาดว่าหน้าที่ของนักพัฒนา, วิศวกรคุณภาพ, และทีมความน่าเชื่อถือของไซต์จะเปลี่ยนแปลงอย่างไรเมื่อการทดสอบกลายเป็นอิสระมากขึ้น?

AI สามารถเพิ่มปริมาณโค้ดได้เร็วกว่าที่บริษัทจะเพิ่มจำนวนผู้ทดสอบ, และการเพิ่มคนยังทำให้เกิดการส่งต่อและการประสานงานเพิ่มขึ้น. นักพัฒนาจะต้องกำหนดเจตนาอย่างชัดเจน, วิศวกรคุณภาพจะมุ่งเน้นที่ความเสี่ยง, ความครอบคลุม, และการกำกับดูแล, และทีมความน่าเชื่อถือของไซต์จะส่งพฤติกรรมการผลิตกลับเข้าสู่กระบวนการปล่อย. เอเจนต์สามารถจัดการการดำเนินการและการวิเคราะห์ที่ซ้ำซ้อนได้ในระดับที่โมเดลการพัฒนาใหม่นี้ต้องการ.

เมื่อเอเจนต์ AI รับผิดชอบการสร้าง, การดำเนิน, และการตีความการทดสอบ, จุดใดที่มนุษย์ต้องคงอำนาจการตัดสินใจ? ประเภทของความไม่แน่นอน, ความเสี่ยงด้านความปลอดภัย, หรือผลกระทบต่อผู้ใช้ที่อาจทำให้การปล่อยต้องหยุดโดยอัตโนมัติหรือเรียกการตรวจสอบจากมนุษย์คืออะไร?

มนุษย์ต้องคงอำนาจสุดท้ายในการตัดสินใจปล่อย, โดยเฉพาะเมื่อมีการตัดสินใจ, ผลกระทบต่อผู้ใช้, หรือความเสี่ยงทางธุรกิจ. เอเจนต์ AI สามารถอัตโนมัติงานทดสอบที่น่าเบื่อ, ทำซ้ำได้, และกำหนดชัดเจน, แต่มนุษย์ควรอนุมัติการปล่อยผลิตภัณฑ์เมื่อโค้ดหรือผลการทดสอบไม่สามารถเข้าใจ, อธิบาย, หรือทำซ้ำได้อย่างเต็มที่. การตรวจสอบควรเป็นสิ่งบังคับเมื่อข้อกำหนดไม่ชัดเจน, มีความเสี่ยงด้านความปลอดภัย, ส่วนประกอบของบุคคลที่สามไม่ได้รับการตรวจสอบอย่างเพียงพอ, หรือความล้มเหลวอาจส่งผลต่อรายได้, ข้อมูลสำคัญ, ประสบการณ์ของลูกค้า, หรือการดำเนินงานที่สำคัญต่อภารกิจ.

ในสถานการณ์เหล่านั้น, พฤติกรรมที่ไม่อธิบายได้, ผลการทดสอบที่ไม่สอดคล้อง, หรือหลักฐานไม่เพียงพอของความพร้อมในการปล่อย ควรทำให้การปล่อยหยุดโดยอัตโนมัติ.

เราเคยเห็นกรณีในลูกค้าของเราที่การทดสอบที่ดูเหมือน “flaky”, ผ่านอย่างไม่สม่ำเสมอโดยไม่มีรูปแบบการล้มเหลวที่ชัดเจน, มักจะถูกละเลย. แต่กระบวนการที่กำกับดูแลอย่างดีในบางลูกค้าเหล่านี้ต้องการการตรวจสอบอย่างละเอียดและด้วยความช่วยเหลือจากแพลตฟอร์มของเรา, พวกเขาสามารถติดตามความล้มเหลวไปยังข้อบกพร่องที่ละเอียดอ่อนแต่สำคัญซึ่งอิงตามเวลา ซึ่งอาจทำให้เกิดผลกระทบใหญ่หากปล่อยออกไป, ด้วยค่าใช้จ่ายที่สูงมาก.

คุณยังเคยทำงานกับ Ethical AI Governance Group และกลุ่มทำงาน Safe Systems and Technologies ของ World Economic Forum. เมื่อโค้ดที่สร้างโดย AI และการทดสอบอัตโนมัติเชื่อมโยงกันอย่างลึกซึ้ง, มาตรฐานการกำกับดูแลใดที่องค์กรต้องมีเพื่อให้การสร้างซอฟต์แวร์ที่เร็วขึ้นไม่ก่อให้เกิดความเสี่ยงใหม่ด้านระบบ, ความปลอดภัย, หรือความรับผิดชอบ?

AI สามารถสร้างซอฟต์แวร์ได้เร็วเท่าใด, ชั้นการตรวจสอบและกำกับดูแลก็ต้องแข็งแกร่งเท่านั้น. ชั้นนี้ประกอบด้วยหลายส่วน. องค์กรต้องกำหนดขอบเขตที่ชัดเจนว่าตัวเอเจนต์สามารถตัดสินใจด้วยตนเองได้ในเรื่องใด, โดยต้องมีการตรวจสอบจากมนุษย์เมื่อมีความไม่แน่นอนเกี่ยวกับเจตนาทางธุรกิจ, ความปลอดภัย, การปฏิบัติตามกฎระเบียบ, หรือการเปลี่ยนแปลงเชิงความหมายที่สำคัญ. พวกเขายังต้องมีการติดตามที่มาของการเปลี่ยนแปลงของเอเจนต์, เหตุผลที่ทำการเปลี่ยนแปลง, และหลักฐานที่สนับสนุนการตัดสินใจปล่อย. สุดท้าย, การกำกับดูแลควรวัดจากคุณภาพและความสามารถคาดการณ์ของสิ่งที่เข้าสู่การผลิต, เช่น การติดตามโดยเฉพาะว่ารหัสที่สร้างขึ้นทำให้เกิดเหตุการณ์บ่อยแค่ไหนภายใน 90 วันหลังการปล่อย, ไม่ใช่ความเร็วที่ AI สามารถสร้างโค้ดได้.

ขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม, ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม Sauce Labs.