A/B testing: วิธีการทดสอบการทดสอบของคุณ

ทำไมเราต้องทดสอบการทดสอบ (A/B testing)

ในการพัฒนาเว็บหรือแอปพลิเคชัน A/B testing (การทดสอบเปรียบเทียบสองเวอร์ชันเพื่อหาว่าแบบไหนดีกว่า) เป็นเครื่องมือสำคัญที่ช่วยให้เราตัดสินใจเลือกฟีเจอร์หรือการออกแบบได้แม่นยำขึ้น แต่นักพัฒนาหลายคนมักโฟกัสแค่ตัวเลขสถิติ จนลืมตรวจสอบว่าระบบที่ใช้ทดสอบนั้นทำงานถูกต้องจริงหรือเปล่า หากระบบหลังบ้านมีปัญหา ข้อมูลที่ได้มาก็อาจเป็นตัวเลขที่ผิดพลาดตั้งแต่ต้น

ลองจินตนาการว่าคุณมีเครื่องขายขนมสองตู้ที่ตั้งอยู่ข้างกัน คุณใส่ขนมชนิดเดียวกันในราคาเท่ากันเป๊ะ แต่พอผ่านไปหนึ่งสัปดาห์ เครื่อง B กลับขายได้มากกว่าเครื่อง A ถึง 20 เปอร์เซ็นต์ หากคุณรีบสรุปว่าเครื่อง B ดึงดูดลูกค้ามากกว่า คุณอาจกำลังเข้าใจผิด เพราะปัญหาอาจเกิดจากเครื่อง B หยอดเหรียญง่ายกว่า หรือเครื่อง A เสียจนคนหยอดเหรียญไม่ลง

การเป็นโปรแกรมเมอร์ที่ดีไม่ใช่แค่การเขียนโค้ดให้รันผ่าน แต่คือการสร้างระบบที่ เชื่อถือได้ (น่าไว้ใจและให้ผลลัพธ์ที่ถูกต้อง) ก่อนที่คุณจะเริ่มวิเคราะห์ผลการทดสอบใดๆ คุณต้องตรวจสอบก่อนว่ากลไกการสุ่มและการเก็บข้อมูลของคุณไม่มีบั๊ก (ข้อผิดพลาดในโค้ด) แอบแฝงอยู่ เพราะต่อให้ใช้สูตรคณิตศาสตร์ที่ซับซ้อนแค่ไหน หากข้อมูลที่ใส่เข้าไปมันเพี้ยน ผลลัพธ์สุดท้ายก็ไร้ความหมาย

การทำ A/A test เพื่อตรวจสอบระบบ

วิธีที่ง่ายและได้ผลที่สุดในการตรวจเช็กว่าระบบทดสอบของคุณทำงานปกติไหม คือการทำ A/A test (การทดสอบโดยใช้เวอร์ชันที่เหมือนกันทั้งสองฝั่ง) ซึ่งก็คือการรันประสบการณ์เดียวกันเป๊ะให้ผู้ใช้ทั้งสองกลุ่มเห็น หากระบบของคุณไม่มีปัญหา ผลลัพธ์ที่ได้ควรจะเท่ากันหรือใกล้เคียงกันมากที่สุด เพราะทั้งสองกลุ่มไม่ควรมีความแตกต่างในเชิงสถิติเลย

หลายคนมองข้ามขั้นตอนนี้เพราะรู้สึกว่ามันดูไม่ค่อยมีประโยชน์ แต่ในความเป็นจริง Regression (การที่ระบบเคยทำงานดีแล้วกลับมาพัง) ในระบบทดสอบนั้นเกิดขึ้นได้เสมอ ไม่ว่าจะเป็นเรื่องของตัวแปรที่รั่วไหลระหว่างกลุ่ม หรือตัววัดผลที่ทำงานซ้ำซ้อนกัน การทำ A/A test อย่างต่อเนื่องจะช่วยให้คุณมั่นใจได้ว่าเครื่องมือที่คุณใช้ไม่ได้กำลังหลอกคุณอยู่

เราควรนำทราฟฟิก (จำนวนผู้ใช้งานที่เข้ามาในระบบ) ที่ไม่ได้อยู่ในช่วงการทดสอบจริง มาเข้าสู่ระบบ A/A test ไว้ตลอดเวลา เพื่อให้ระบบแจ้งเตือนทันทีหากตัวเลขเริ่มมีความผิดปกติเกิดขึ้น หากคุณพบว่าค่า False-positive (การที่ระบบแจ้งว่าพบผลลัพธ์ที่น่าสนใจ ทั้งที่จริงๆ ไม่มีอะไรเกิดขึ้น) สูงผิดปกติ นั่นคือสัญญาณเตือนว่าระบบสถิติของคุณมีปัญหาและต้องรีบแก้ไขก่อนเริ่มงานจริง

// โค้ดตัวอย่างการสุ่มกลุ่มผู้ใช้แบบง่าย
function getTestGroup(userId) {
  // สุ่มเลข 0 หรือ 1 เพื่อแบ่งกลุ่ม
  const group = userId % 2 === 0 ? 'A' : 'B';
  return group;
}

// ตรวจสอบความเท่ากันของกลุ่ม
const users = [1, 2, 3, 4, 5, 6];
const results = users.map(id => getTestGroup(id));
console.log(results); // แสดงผลกลุ่มที่ผู้ใช้แต่ละคนได้รับ

โค้ดด้านบนรับ userId (รหัสประจำตัวของผู้ใช้) เข้ามาแล้วใช้การหารเอาเศษเพื่อแบ่งกลุ่มเป็น 'A' หรือ 'B' ซึ่งถ้าทุกอย่างทำงานถูกต้อง จำนวนกลุ่ม A และ B ควรจะเท่ากันเสมอ หากรันแล้วเห็นว่ากลุ่มหนึ่งได้คนมากกว่าอย่างชัดเจน แสดงว่าตัวสุ่มของคุณอาจมีปัญหา

ผลลัพธ์ที่ได้จากการรันโค้ด: ['B', 'A', 'B', 'A', 'B', 'A'] จะเห็นว่าแบ่งกลุ่มได้อย่างสมดุล หากผลลัพธ์ออกมาเป็นกลุ่ม A ทั้งหมด แสดงว่าบั๊กในฟังก์ชัน getTestGroup กำลังทำให้การทดสอบพังตั้งแต่เริ่มต้น

การตรวจสอบความสมดุลด้วย Sample Ratio Mismatch (SRM)

Sample Ratio Mismatch หรือ SRM (เหตุการณ์ที่สัดส่วนผู้ใช้ในแต่ละกลุ่มไม่เป็นไปตามที่ตั้งค่าไว้) คือสัญญาณเตือนภัยที่สำคัญมาก หากคุณตั้งค่าให้แบ่งคน 50/50 แต่ผลที่ได้กลับกลายเป็น 52/48 คุณต้องหยุดดูว่าเกิดอะไรขึ้นทันที เพราะในสเกลการใช้งานจริง ความแตกต่างเพียงเล็กน้อยอาจเกิดจากบั๊กที่ซ่อนอยู่

เมื่อเรามีผู้ใช้งานจำนวนมาก การที่สัดส่วนไม่เท่ากันมักไม่ใช่เรื่องบังเอิญ แต่เกิดจากปัญหาทางเทคนิค เช่น Bot traffic (โปรแกรมอัตโนมัติที่เข้ามาเยี่ยมชมเว็บ) ที่พุ่งเข้าหาเฉพาะบางกลุ่ม หรือการที่รหัสผู้ใช้เกิดการชนกัน (ID collision) ทำให้ระบบสับสนและส่งคนไปอยู่ผิดที่ผิดทาง ซึ่งถ้าคุณไม่เช็กค่านี้ก่อน ผลลัพธ์ที่ได้จากการทดสอบจะเชื่อถือไม่ได้เลย

วิธีแก้คือการใช้ Chi-squared test (การทดสอบทางสถิติเพื่อดูว่าข้อมูลที่เห็นจริงต่างจากที่คาดหวังไหม) เพื่อดูว่าช่องว่างที่เกิดขึ้นนั้นเป็นเรื่องปกติหรือเป็นความผิดพลาด คุณควรตั้งค่าความเข้มงวดไว้สูงหน่อย เช่น ถ้าค่า p-value (ตัวเลขแสดงโอกาสที่ผลลัพธ์จะเกิดจากความบังเอิญ) ต่ำกว่า 0.001 ให้รีบตรวจสอบระบบทันที อย่าปล่อยผ่านเด็ดขาด

ระวังกับดักจาก Simpson’s Paradox

Simpson’s Paradox (ปรากฏการณ์ที่ผลรวมดูเหมือนกลุ่ม B ชนะ แต่เมื่อแยกย่อยข้อมูลออกมา กลุ่ม A กลับชนะในทุกกลุ่ม) เป็นกับดักที่น่ากลัวมาก มันเกิดขึ้นเมื่อมีการกระจายตัวของข้อมูลที่ไม่เท่ากันในแต่ละกลุ่มเปรียบเทียบกัน เช่น การที่กลุ่มหนึ่งได้ผู้ใช้ที่เป็นลูกค้าประจำเยอะกว่าอีกกลุ่มหนึ่งโดยบังเอิญ ทำให้ตัวเลขภาพรวมบิดเบือนไปจากความเป็นจริง

สมมติว่าคุณกำลังทดสอบปุ่มสั่งซื้อใหม่ ผลรวมบอกว่าปุ่มสีแดง (กลุ่ม B) ขายดีกว่าปุ่มสีน้ำเงิน (กลุ่ม A) แต่เมื่อคุณลองแยกดูตามอุปกรณ์ที่ใช้ ทั้งบนมือถือและคอมพิวเตอร์ ปุ่มสีน้ำเงินกลับชนะปุ่มสีแดงในทุกอุปกรณ์ นั่นหมายความว่าผลรวมที่เห็นนั้นเชื่อไม่ได้ และมีปัจจัยบางอย่างซ่อนอยู่เบื้องหลังความสำเร็จที่เห็น

คำแนะนำสำหรับโปรแกรมเมอร์คือ อย่าดูแค่ตัวเลขภาพรวม ให้ลอง Segment (การแบ่งกลุ่มข้อมูลย่อยตามคุณสมบัติ) ดูเสมอ เช่น แยกตามประเภทอุปกรณ์ ภูมิภาค หรือสถานะผู้ใช้ หากเห็นว่าทุกกลุ่มย่อยมีแนวโน้มไปในทางเดียวกันแต่ภาพรวมกลับตรงข้าม นั่นคือสัญญาณว่าระบบสุ่มของคุณมีปัญหา และคุณไม่ควรประกาศผลการทดสอบนี้จนกว่าจะหาสาเหตุเจอ

การตั้ง Guardrail metrics เพื่อป้องกันการพัง

Guardrail metrics (ตัววัดผลด้านสุขภาพของระบบที่ต้องติดตามตลอด) คือสิ่งที่จะช่วยปกป้องโปรเจกต์ของคุณจากการทำลายระบบโดยไม่รู้ตัว แม้ว่าฟีเจอร์ใหม่ของคุณจะช่วยเพิ่มยอดขายได้ แต่ถ้ามันทำให้นหน้าเว็บโหลดช้าลง 2 วินาที คุณก็อาจจะสูญเสียผู้ใช้ในระยะยาวไปโดยไม่คุ้มค่าเลย ดังนั้นการติดตามตัววัดผลเหล่านี้จึงเป็นเรื่องบังคับ

ตัวอย่างเช่น เมื่อคุณทำการทดสอบการปรับเปลี่ยนหน้าตะกร้าสินค้า คุณควรติดตามทั้งอัตราการซื้อและ Page load time (ระยะเวลาที่หน้าเว็บใช้ในการโหลดจนเสร็จ) ควบคู่กันไป หากยอดซื้อเพิ่มขึ้น 3 เปอร์เซ็นต์ แต่เวลาในการโหลดเพิ่มขึ้นถึง 400 มิลลิวินาที นี่ไม่ใช่ความสำเร็จ แต่มันคือบั๊กที่ต้องรีบแก้ไขก่อนที่ระบบจะล่ม

การมี Multiple-comparison correction (เทคนิคการปรับค่าทางสถิติเพื่อป้องกันการสรุปผลผิดพลาดจากการดูข้อมูลหลายจุดพร้อมกัน) เป็นอีกเรื่องที่ต้องรู้ หากคุณติดตามตัววัดผลเป็นสิบตัวพร้อมกัน โอกาสที่จะมีตัวใดตัวหนึ่งดูดีขึ้นมาโดยบังเอิญนั้นมีสูงมาก ดังนั้นอย่ารีบดีใจกับตัวเลขตัวเดียวที่ดูดี ให้ดูภาพรวมของระบบและตรวจสอบเสมอว่าไม่มีอะไรพังจากการเปลี่ยนแปลงนี้

สรุป: ตรวจสอบก่อนเชื่อถือตัวเลข

สรุปสั้นๆ คือการทดสอบ A/B testing ที่ดีต้องเริ่มจากการมั่นใจว่า Pipeline (ขั้นตอนการทำงานของข้อมูลตั้งแต่ต้นจนจบ) ของคุณทำงานถูกต้องเสมอ การทำ A/A test, การตรวจสอบ SRM, และการเฝ้าระวังด้วย Guardrail metrics เป็นสิ่งที่โปรแกรมเมอร์ต้องทำจนเป็นนิสัย เพราะผลลัพธ์ที่แม่นยำที่สุดจะไม่มีค่าเลยหากมันถูกวัดจากระบบที่บิดเบี้ยว

ตัวอย่างการนำไปใช้จริง: หากคุณกำลังเตรียมตัวทำโปรเจกต์จบ หรือเริ่มงานแรกในบริษัท ให้ลองสร้างระบบบันทึกผลการทดสอบที่แยกการเก็บข้อมูลของแต่ละกลุ่มออกจากกันอย่างชัดเจน และใส่การเช็กค่าความสมดุล (SRM) ไว้ในโค้ดส่วนวิเคราะห์ข้อมูลเสมอ ถ้าวันหนึ่งระบบแจ้งเตือนว่ากลุ่ม A มีผู้ใช้มากกว่ากลุ่ม B อย่างผิดปกติ คุณจะภูมิใจมากที่ได้ติดตั้งระบบตรวจสอบนี้ไว้ตั้งแต่ต้น

การเป็นโปรแกรมเมอร์ที่เก่งไม่ใช่แค่คนที่เขียนโค้ดเร็ว แต่คือคนที่รอบคอบและตั้งคำถามกับข้อมูลที่ตัวเองได้รับเสมอ ก่อนที่คุณจะกด Deploy ฟีเจอร์ใหม่ ให้ถามตัวเองว่า "ฉันแน่ใจได้อย่างไรว่าข้อมูลที่เห็นเป็นความจริง" หากคุณตอบคำถามนี้ได้ด้วยผลการตรวจสอบที่น่าเชื่อถือ คุณก็พร้อมแล้วที่จะก้าวไปสู่การเป็นนักพัฒนาที่มืออาชีพมากยิ่งขึ้น

ที่มา: A/B testing: how to test your test — DEV Community