คลิกครั้งเดียวไม่ใช่การรู้ว่ามันใช้ได้
คุณแก้เสร็จ กดลองดู มันใช้ได้ คุณก็ปิดงาน แต่คุณคลิกแค่ทางเดียวที่คุณนึกถึง พอผู้ใช้จริงเดินอีกทางที่คุณไม่เคยคลิก มันพัง บทนี้สอนให้คุณหาทางเดินสำคัญที่ห้ามพัง ตรวจมันด้วยมือ แล้วให้ AI เขียนตัวทดสอบอัตโนมัติคอยเฝ้าให้ตลอดไป
คลิกครั้งเดียวไม่ใช่การรู้ว่ามันใช้ได้
คุณเพิ่งให้ AI แก้อะไรสักอย่างเสร็จ คุณเปิดดู กดปุ่ม มันทำงาน หน้าจอขึ้นถูก คุณก็พึงพอใจ ปิดงาน แล้วบอกตัวเองว่า "เรียบร้อย ใช้ได้"
แต่ลึก ๆ ในใจคุณรู้ว่ามีอะไรไม่ชัด คุณกดดูแค่ทางเดียว ทางที่คุณนึกถึงตอนนั้น คุณกรอกข้อมูลที่ถูกต้อง กดปุ่มตามลำดับที่คุณคิดไว้ แล้วมันก็ผ่าน แต่คุณไม่รู้เลยว่าถ้ามีคนกรอกผิด หรือกดข้าม หรือเดินอีกทางที่คุณไม่เคยลอง มันจะยังใช้ได้ไหม
แล้ววันหนึ่งมันก็เกิดขึ้นจริง ผู้ใช้คนหนึ่งเดินทางที่คุณไม่เคยคลิก แล้วมันพัง คุณถึงรู้ว่าที่ผ่านมาคุณไม่เคย "รู้" ว่ามันใช้ได้เลย คุณแค่ "เห็น" ว่ามันใช้ได้ในครั้งเดียวที่คุณลอง
ความกลัวข้อนี้มีจริง และมันคือ "มันดูโอเคตอนฉันกดดู แต่ฉันไม่รู้จริง ๆ ว่ามันใช้ได้" บทนี้จะเปลี่ยนความกลัวนั้นให้เป็นวิธีทำที่ชัดเจน คุณจะรู้ว่าอะไรที่ห้ามพัง ตรวจมันให้เป็น แล้วให้ AI สร้างตาข่ายคอยเฝ้ามันแทนคุณตลอดไป
คลิกครั้งเดียว ไม่ใช่การรู้
ก่อนอื่นต้องแยกสองคำนี้ออกจากกันให้ชัด การ "เห็นว่ามันทำงาน" กับการ "รู้ว่ามันใช้ได้" ไม่ใช่เรื่องเดียวกัน และคนส่วนใหญ่สับสนสองอย่างนี้ตลอดเวลา
เวลาคุณกดดูครั้งเดียว คุณกำลังทดสอบเส้นทางเดียว ด้วยข้อมูลชุดเดียว ในสถานการณ์เดียว ถ้ามันผ่าน คุณรู้แค่ว่า "เส้นทางนี้ ด้วยข้อมูลนี้ ในตอนนี้ ใช้ได้" เท่านั้น คุณไม่รู้อะไรเลยเกี่ยวกับเส้นทางอื่น ข้อมูลแบบอื่น หรือคนที่ใช้ต่างจากคุณ
ปัญหาคือผู้ใช้จริงไม่ได้เดินเหมือนคุณ คุณสร้างมันเอง คุณรู้ว่าต้องกดอะไรก่อนหลัง คุณกรอกข้อมูลที่คุณรู้ว่าถูก แต่คนอื่นไม่รู้ เขากดข้าม กรอกเว้น ใส่ตัวอักษรในช่องที่ควรเป็นตัวเลข กดปุ่มเดิมสองครั้งเพราะไม่แน่ใจว่ากดติดไหม ทุกอย่างที่คุณไม่เคยทำ เขาทำหมด
💡 ใจความสำคัญ: การกดดูครั้งเดียวบอกคุณแค่ว่า เส้นทางเดียวที่คุณคลิก ใช้ได้ในตอนนั้น มันไม่ได้บอกว่าทั้งระบบใช้ได้ "เห็นว่ามันทำงาน" กับ "รู้ว่ามันใช้ได้" เป็นคนละเรื่องกัน และระยะห่างระหว่างสองคำนี้คือที่ที่บั๊กชอบซ่อนตัว
หาทางเดินที่ห้ามพัง
ถ้าจะตรวจทุกเส้นทาง ทุกข้อมูล ทุกสถานการณ์ คุณคงไม่ได้ทำอะไรอย่างอื่นทั้งวัน นั่นเป็นไปไม่ได้ และไม่จำเป็น ความจริงคือในแอปของคุณ มีเส้นทางอยู่ไม่กี่เส้นที่ "ห้ามพังเด็ดขาด" และมีอีกหลายเส้นที่ถ้าพังก็แค่รำคาญ ไม่ถึงตาย
เส้นทางที่ห้ามพัง คือเส้นทางที่ถ้ามันพัง แอปของคุณก็ไม่มีความหมาย เราเรียกมันในวงการว่า critical path แปลตรงตัวว่า "เส้นทางวิกฤต" หรือพูดเป็นภาษาคนคือ "ทางเดินสำคัญที่ขาดไม่ได้"
มันคือสิ่งที่ผู้ใช้ ต้อง ทำได้ ไม่งั้นมาที่แอปคุณทำไม สำหรับแอปทั่วไป ทางเดินสำคัญมักจะเป็นพวกนี้
- สมัครสมาชิกได้ ถ้าคนใหม่สมัครไม่ได้ คุณก็ไม่มีผู้ใช้เพิ่มเลย
- ล็อกอินได้ ถ้าคนเก่ากลับเข้ามาไม่ได้ คุณก็เสียคนที่มีอยู่
- ทำสิ่งหลักของแอปได้ ถ้าแอปคุณคือร้านขายของ ก็ต้องหยิบของลงตะกร้าได้ ถ้าเป็นเว็บเรียน ก็ต้องเปิดบทเรียนอ่านได้
- จ่ายเงินได้ ถ้าแอปคุณมีการจ่ายเงิน แล้วจ่ายไม่ได้ นั่นคือเงินที่หายไปตรง ๆ
สังเกตว่ามันมีไม่กี่อย่าง นี่คือประเด็นสำคัญ ทางเดินสำคัญของแอปส่วนใหญ่นับนิ้วได้ ไม่เกินห้าหกอย่าง งานของคุณไม่ใช่ตรวจทุกอย่าง แต่คือ เลือก ว่าอะไรคือไม่กี่อย่างที่ห้ามพัง แล้วตรวจแค่พวกนั้นให้ดี
ลองหยุดอ่านตรงนี้แล้วถามตัวเองว่า ในของที่คุณกำลังสร้าง ถ้ามีอยู่สามอย่างที่พังไม่ได้เลย มันคืออะไร เขียนออกมา นั่นคือทางเดินสำคัญของคุณ
ตรวจด้วยมือก่อน ทุกครั้งที่แก้
พอคุณรู้แล้วว่าทางเดินสำคัญคืออะไร ขั้นต่อไปง่ายมาก ทุกครั้งที่คุณแก้อะไร ให้เดินทางเดินสำคัญเหล่านั้นด้วยมือตัวเองหนึ่งรอบ ก่อนจะบอกว่า "เสร็จ"
ไม่ใช่แค่กดดูส่วนที่คุณเพิ่งแก้ แต่เดินทั้งเส้น สมมติคุณเพิ่งแก้สีปุ่มในหน้าล็อกอิน อย่าดูแค่ว่าสีเปลี่ยนไหม ให้ลองล็อกอินจริงตั้งแต่ต้นจนเข้าได้ เพราะอย่างที่บท เปลี่ยนทีละนิด เพื่อจะรู้ว่าอะไรพัง อธิบายไว้ ส่วนต่าง ๆ ของแอปแอบผูกกันอยู่ใต้ผิว การแตะจุดเดียวอาจกระเทือนทางเดินทั้งเส้นโดยที่คุณมองไม่เห็น
การเดินด้วยมือนี้ยังควรลองเดินแบบ "ผู้ใช้ที่ไม่ใช่คุณ" ด้วย ลองกรอกเว้นช่อง ลองใส่ข้อมูลผิด ๆ ลองกดปุ่มผิดลำดับ สิ่งที่คุณไม่เคยทำตอนสร้าง คือสิ่งที่ผู้ใช้จริงจะทำในวันแรก ถ้าคุณเจอมันพังตอนนี้ ดีกว่าให้ผู้ใช้เจอ
นี่คือขั้นต่ำที่คุณทำได้ทันที ไม่ต้องใช้เครื่องมืออะไร แค่ตั้งใจเดินทางเดินสำคัญเองทุกครั้งหลังแก้ แต่มันมีจุดอ่อนใหญ่อยู่หนึ่งข้อ และจุดอ่อนนั้นคือเหตุผลที่เราต้องไปต่ออีกขั้น
จุดอ่อนคือ คุณเป็นคน คุณลืม คุณขี้เกียจ และยิ่งแอปโตขึ้น ทางเดินสำคัญก็มีหลายเส้นจนคุณไม่มีทางเดินครบทุกเส้นด้วยมือทุกครั้งที่แก้ของเล็ก ๆ พอแก้ครั้งที่ห้าสิบ คุณก็จะเริ่มข้าม "แก้นิดเดียว ไม่น่าพังหรอก" แล้วมันก็พังตรงนั้นแหละ
ตาข่ายที่ไม่มีวันลืม คือสิ่งที่เรียกว่า test
มาถึงหัวใจของบทนี้ ถ้าปัญหาคือคนลืมและขี้เกียจ ทางแก้คือเอาการตรวจไปให้เครื่องทำแทน เครื่องไม่ลืม ไม่ขี้เกียจ และทำเร็วกว่าคุณเป็นพันเท่า
ลองคิดถึงสิ่งนี้ คุณเขียนคำสั่งสั้น ๆ ไว้ชิ้นหนึ่ง ที่บอกว่า "เปิดหน้าล็อกอิน กรอกอีเมลกับรหัสที่ถูกต้อง กดปุ่มเข้าสู่ระบบ แล้วเช็คว่าได้เข้าหน้าหลักจริงไหม ถ้าได้ ผ่าน ถ้าไม่ได้ ไม่ผ่าน" คำสั่งชิ้นนี้คือโปรแกรมเล็ก ๆ ที่ รันโปรแกรมของคุณ แล้วเช็คว่าคำตอบถูกหรือเปล่า โดยอัตโนมัติ
สิ่งนี้ในวงการเรียกว่า test แปลตรงตัวว่า "การทดสอบ" มันคือโค้ดที่เขียนไว้เพื่อรันโค้ดอีกชิ้น แล้วตรวจว่าผลออกมาตรงกับที่ควรจะเป็นไหม ทำเองทั้งหมด ไม่ต้องมีคนนั่งกด
จุดสำคัญที่สุดของ test ไม่ใช่ว่ามันตรวจได้ แต่คือมันตรวจ ทุกครั้งที่มีอะไรเปลี่ยน คุณตั้งมันไว้ครั้งเดียว แล้วต่อจากนั้น ทุกครั้งที่คุณหรือ AI แก้อะไรในแอป test ชุดนี้จะรันใหม่ทั้งหมดอัตโนมัติ เช็คซ้ำว่าทุกทางเดินสำคัญยังใช้ได้อยู่ไหม ถ้ามีเส้นไหนพัง มันจะร้องบอกทันที ก่อนที่ของพังจะไปถึงผู้ใช้
นี่คือคำตอบตรง ๆ ของความกลัว "แก้อย่างเดียว พังไปสามอย่าง" ที่บท 5.11 พูดถึง ปัญหานั้นเกิดเพราะของในแอปผูกกันใต้ผิว คุณแก้ตรงนี้ แล้วของข้าง ๆ พังโดยคุณไม่รู้ตัว test คือตาข่ายที่คอยเช้คของข้าง ๆ ให้ตลอด พอคุณแก้ของใหม่ test เก่าจะรันทันทีเพื่อยืนยันว่าของเก่าที่เคยใช้ได้ ยังใช้ได้อยู่ ถ้าการแก้ใหม่ไปทำของเก่าพัง test จะจับได้ก่อนคุณจะ "เสร็จ" ด้วยซ้ำ
💡 ใจความสำคัญ: test ไม่ใช่แค่เครื่องมือเช็คของใหม่ มันคือตาข่ายที่คอยเช็คของ เก่า ทุกครั้งที่คุณเปลี่ยนของใหม่ มันคือเหตุผลที่คุณกล้าแก้แอปที่โตแล้ว โดยไม่ต้องกลัวว่าจะเผลอทำของที่เคยใช้ได้พังเงียบ ๆ
คนสร้างเว็บนี้ไม่ได้เขียน test เอง แต่เขาให้ AI เขียน
ตรงนี้สำคัญมากสำหรับคุณ คุณอาจกำลังคิดว่า "ฉันเขียน test ไม่เป็นหรอก ฉันเขียนโค้ดยังไม่เป็นเลย" ถูกต้อง และคุณไม่ต้องเขียน
หน้าที่ของคุณไม่ใช่เขียน test หน้าที่ของคุณคือ ตัดสินใจว่าอะไรคุ้มที่จะ test แล้วบอก AI ให้เขียนให้ คุณเป็นคนที่รู้ว่าทางเดินไหนของแอปคุณห้ามพัง AI ไม่รู้เรื่องธุรกิจคุณดีเท่าคุณ แต่ AI เขียนโค้ด test ได้คล่องมาก งานแบ่งกันชัดเจน คุณเลือกว่าอะไรสำคัญ AI ลงมือเขียนตามที่คุณเลือก
เว็บที่คุณกำลังอ่านอยู่นี้เป็นตัวอย่างจริง มันสร้างโดยคนที่ไม่ใช่โปรแกรมเมอร์ ด้วยการสั่ง AI และตอนนี้มันรันอยู่จริงบนอินเทอร์เน็ต เว็บนี้มีตาข่ายแบบที่บทนี้พูดถึงทำงานอยู่จริง ตอนนี้มี test ที่ตรวจส่วนย่อย ๆ ของโค้ดอยู่ 59 ชุด บวกกับ test อีก 13 ชุดที่เปิดเบราว์เซอร์จริงขึ้นมาแล้วเดินทางเดินสำคัญทั้งเส้นเหมือนผู้ใช้จริง
test พวกนี้แหละคือเหตุผลที่เจ้าของเว็บกล้าแก้เว็บแล้วเชื่อใจได้ว่าไม่พัง ทุกครั้งที่เขาหรือ AI เปลี่ยนอะไร test ทั้ง 72 ชุดจะรันใหม่หมด ถ้าผ่านทุกชุด เขารู้ว่าของเก่ายังดีอยู่ ถ้ามีชุดไหนไม่ผ่าน เขารู้ทันทีว่าเพิ่งทำอะไรพัง ก่อนจะ deploy ขึ้นเว็บจริง (คำว่า deploy คือการดันของจากเครื่องตัวเองขึ้นไปอยู่บนเว็บที่คนทั้งโลกเข้าได้ ตามที่บท ขึ้นเว็บจริง อธิบายไว้)
มี test ตัวหนึ่งที่เห็นภาพชัดดี เว็บนี้มีส่วนที่รวมของเล่นเชิงโต้ตอบไว้หลายชิ้น แต่ละชิ้นต้องมีรหัสประจำตัวที่ไม่ซ้ำกัน และต้องมีไฟล์ต้นฉบับของมันอยู่จริง test ตัวนี้ทำหน้าที่เดียว คือไล่เช็คว่าของเล่นทุกชิ้นมีรหัสไม่ซ้ำใคร และไฟล์ที่มันชี้ไปถึงมีอยู่จริง
ลองคิดว่าทำไมต้องมี test แบบนี้ สมมติวันหนึ่งเจ้าของเว็บให้ AI เพิ่มของเล่นชิ้นใหม่ แล้ว AI เผลอตั้งรหัสซ้ำกับชิ้นที่มีอยู่แล้ว หรือเผลอชี้ไปยังไฟล์ที่ลบไปแล้ว ถ้าไม่มี test ตัวนี้ เจ้าของเว็บจะไม่มีทางเห็นเลย หน้าจอตอนเขากดดูอาจขึ้นปกติด้วยซ้ำ เพราะเขาบังเอิญกดดูชิ้นที่ไม่มีปัญหา แล้วของพังก็จะหลุดขึ้นเว็บจริง ไปโผล่ตอนผู้ใช้คนหนึ่งกดเปิดชิ้นที่รหัสซ้ำ แต่เพราะมี test ตัวนี้ พอ AI ตั้งรหัสซ้ำ test จะไม่ผ่านทันที งานหยุดอยู่ตรงนั้น ของพังไม่มีวันได้ขึ้นเว็บ นี่คือบั๊กที่ test จับได้ ทั้งที่ตาเปล่ามองไม่เห็น
พิธีกรรมก่อนบินของนักบิน
มีภาพหนึ่งที่ช่วยให้เข้าใจว่า test คืออะไรในชีวิตจริง
ก่อนเครื่องบินจะออกทุกเที่ยว นักบินต้องไล่เช็กตามรายการที่เรียกว่า checklist ทีละข้อ ล้อ เบรก เชื้อเพลิง ระบบสื่อสาร ทุกอย่างในรายการ นักบินที่บินมาพันเที่ยวแล้ว ก็ยังต้องไล่เช็กรายการเดิมนี้ทุกเที่ยว ไม่มีข้อยกเว้น ไม่ใช่เพราะเขาลืมวิธีบิน แต่เพราะของที่เคยดีเมื่อวาน อาจมีอะไรเปลี่ยนไปวันนี้โดยไม่มีใครรู้ การไล่เช็กทุกครั้งคือสิ่งที่ทำให้เขามั่นใจได้ว่าทุกอย่างพร้อม ก่อนจะพาคนเป็นร้อยขึ้นฟ้า
test ก็คือ checklist ก่อนบินของแอปคุณ มันคือรายการของ "สิ่งที่ต้องใช้ได้" ที่ถูกไล่เช็กใหม่ทุกครั้งก่อนของจะขึ้นเว็บจริง ต่อให้คุณแก้มาแล้วร้อยครั้ง ครั้งที่ร้อยเอ็ดมันก็ไล่เช็กให้ครบเหมือนเดิม โดยที่คุณไม่ต้องจำเอง
แต่การเปรียบเทียบนี้ใช้ได้แค่จุดเดียว และจุดที่มันต่างคือเรื่องที่คุณต้องไม่ลืม checklist ของนักบินเช็กได้แค่สิ่งที่มี คนคิดไว้ล่วงหน้า ว่าต้องเช็ก test ก็เหมือนกัน มันเช็กได้แค่สิ่งที่คุณ นึกออก ว่าต้องเช็ก ถ้ามีวิธีพังแบบหนึ่งที่ไม่มีใครเคยจินตนาการถึง test ก็จับมันไม่ได้ เพราะไม่มีใครเขียน test มาดักมันไว้ test ลดความเสี่ยง มันไม่ได้ลบความเสี่ยงทิ้ง การมี test เต็มไปหมดไม่ได้แปลว่าแอปคุณพังไม่ได้ มันแปลว่าแอปคุณพังด้วยวิธีที่คุณเคยคิดถึงไม่ได้ ส่วนวิธีที่คุณไม่เคยคิดถึง ยังเหลืออยู่เสมอ
ความเข้าใจผิดที่ต้องแก้
หลายคนคิดว่า ถ้าหน้าจอขึ้นถูก แปลว่ามันใช้ได้ ภาพขึ้นสวย ปุ่มอยู่ครบ ก็น่าจะเรียบร้อยแล้ว จริง ๆ แล้วการที่หน้าจอขึ้นถูก บอกแค่ว่ามัน แสดงผล ได้ ไม่ได้บอกว่ามัน ทำงาน ได้ ปุ่มอาจขึ้นสวยแต่กดแล้วไม่เกิดอะไร ฟอร์มอาจดูครบแต่กดส่งแล้วข้อมูลหาย สิ่งที่หน้าจอแสดง กับสิ่งที่เกิดขึ้นจริงตอนคนใช้ เป็นคนละเรื่อง โดยเฉพาะกรณีแปลก ๆ ที่ตาเปล่ามองไม่เห็น เช่น กรอกเว้นช่อง หรือใส่ข้อมูลผิดประเภท
อีกความเข้าใจผิดคือ test เป็นงานเพิ่มที่โปรแกรมเมอร์ทำกันเล่น ๆ ให้ดูขยัน หลายคนมองว่ามันคืองานพิเศษที่ไม่จำเป็น เสียเวลาเปล่า จริง ๆ แล้ว test คือสิ่งที่ทำให้คนสร้างแอปนอนหลับได้ มันไม่ใช่งานโชว์ มันคือเหตุผลที่คุณกล้าแก้แอปที่มีคนใช้จริงอยู่ โดยไม่ต้องลุ้นทุกครั้งว่าจะมีอะไรพังโดยไม่รู้ตัว คนที่ทำงานกับโค้ดจริงจังไม่ได้เขียน test เพราะถูกบังคับ แต่เพราะไม่มี test แล้วชีวิตน่ากลัวเกินไป
สรุป
กลับไปที่ความกลัวตอนต้น "มันดูโอเคตอนฉันกดดู แต่ฉันไม่รู้จริง ๆ ว่ามันใช้ได้" ตอนนี้คุณรู้แล้วว่าทำไมความรู้สึกนั้นถึงถูกต้อง การกดดูครั้งเดียวบอกแค่ว่าเส้นทางเดียวที่คุณคลิก ใช้ได้ในตอนนั้น มันไม่ใช่การรู้ว่าทั้งระบบใช้ได้
ทางออกเป็นขั้น ๆ หนึ่ง เลือกทางเดินสำคัญของแอปคุณ ไม่กี่เส้นที่ห้ามพังเด็ดขาด สมัคร ล็อกอิน ทำสิ่งหลัก จ่ายเงิน สอง เดินทางเดินสำคัญเหล่านั้นด้วยมือทุกครั้งหลังแก้ และลองเดินแบบผู้ใช้ที่ไม่ใช่คุณด้วย สาม ให้ AI เขียน test ดักทางเดินสำคัญที่สำคัญที่สุดไว้ เพื่อให้มันถูกเช็กใหม่อัตโนมัติทุกครั้งที่มีอะไรเปลี่ยน ตลอดไป
test คือตาข่ายที่ทำให้คุณกล้าแก้ของต่อ มันคอยเช็กว่าของเก่ายังดีอยู่ทุกครั้งที่คุณเพิ่มของใหม่ จึงเป็นคำตอบโดยตรงของปัญหา "แก้อย่างเดียว พังสามอย่าง" คุณไม่ต้องเขียนมันเอง คุณแค่ตัดสินใจว่าอะไรคุ้มที่จะเฝ้า แล้วให้ AI สร้างตาข่ายให้ เว็บที่คุณอ่านอยู่นี้มี test 72 ชุดเฝ้าอยู่จริง และนั่นคือเหตุผลที่คนที่ไม่ใช่โปรแกรมเมอร์ ยังกล้าแก้เว็บที่มีคนใช้จริงได้ทุกวัน
จำไว้ข้อเดียว test ไม่ได้ลบความเสี่ยงทิ้ง มันลดความเสี่ยงลง มันจับได้แค่สิ่งที่คุณนึกออกว่าต้องเช็ก ส่วนวิธีพังที่คุณไม่เคยคิดถึง ยังเหลืออยู่เสมอ นี่คือเหตุผลที่บทต่อไปจะพาคุณไปดูว่า ตรงไหนของแอปที่อันตรายเป็นพิเศษ จุดที่คุณควรระวังให้มากกว่าที่อื่น
อ่านต่อ: แผนที่เขตอันตราย