นักทดสอบที่มีใบเซอร์ 10 ใบ แต่กลับหาบั๊กไม่เจอ
คุณมีใบเซอร์ครบทุกอย่าง ทั้ง ISTQB, ScrumMaster, Cloud และ Security เรซูเม่ของคุณเต็มไปด้วยตัวย่อเต็มไปหมด
แต่คุณกลับเขียนเทสต์แม้แต่เคสเดียวที่สามารถหาบั๊กจริงๆ เจอไม่ได้เลย
เมื่อไตรมาสที่แล้ว ผมได้สัมภาษณ์ผู้สมัครคนหนึ่ง เขาพูดแต่เรื่องทฤษฎี เขาพูดถึง V-model และ shift-left แต่พอผมขอให้เขาแสดงเทสต์สักเคสหนึ่งที่เขาเคยเขียนแล้วเจอตัวบั๊ก เขากลับเงียบไป
เขาไม่เคยเขียนเทสต์ที่ทำให้ระบบพังเลย เขาเขียนแต่เทสต์ที่ผ่าน (pass) เท่านั้น
ใบเซอร์วัดความจำของคุณ แต่บั๊กวัดกระบวนการคิดของคุณ
ใบเซอร์ช่วยให้คุณมีคำศัพท์และโครงสร้างในการทำงาน ช่วยให้คุณผ่านด่านคัดกรองของ Recruiter แต่ไม่ได้สอนวิธีหาข้อผิดพลาด (defects)
ข้อสอบมีหลักสูตรที่ชัดเจน แต่แอปพลิเคชันจริงๆ ไม่มี ฟอร์มล็อกอินไม่มีหลักสูตรให้คุณอ่าน แต่มันมี edge cases แปลกๆ เช่น เวลาของเซิร์ฟเวอร์คลาดเคลื่อนไป 4 นาที หรือปัญหาเรื่อง timing เฉพาะเจาะจง
นักทดสอบที่มีใบเซอร์จะทำตามเช็คลิสต์ พวกเขาเขียนเทสต์ตามความต้องการ (requirements) แล้วทำเครื่องหมายว่าผ่านหรือตก
ส่วนนักล่าบั๊ก (bug hunter) จะมองการทดสอบเหมือนการสืบสวน พวกเขาเริ่มจากสมมติฐาน และพยายามพิสูจน์ว่าแอปพลิเคชันนั้นทำงานผิดพลาด
ลองดูความแตกต่างของแนวคิด (mindset) นี้
การทดสอบแบบมาตรฐานจะเช็คแค่ happy path:
- ไปที่หน้าสินค้า
- เพิ่มลงตะกร้า
- กรอกรายละเอียดบัตรที่ถูกต้อง
- คาดหวังการยืนยันคำสั่งซื้อ
เทสต์นี้พิสูจน์ว่าฟีเจอร์ทำงานได้เมื่อทุกอย่างสมบูรณ์แบบ แต่มันจะไม่มีวันหาบั๊กเจอ
แต่เทสต์ของนักล่าบั๊กจะเต็มไปด้วยความสงสัย:
- กรอกหมายเลขบัตรผิด (typo)
- คาดหวังข้อความแจ้งเตือนข้อผิดพลาด
- ตรวจสอบว่าการยืนยันคำสั่งซื้อต้องไม่ปรากฏขึ้นมา
เทสต์ที่สองตั้งสมมติฐานว่าแอปพลิเคชันจะล้มเหลว โดยตั้งคำถามว่า "มันจะพังตรงไหน?"
นักทดสอบหลายคนมีช่องว่างในด้านประสบการณ์ ไม่ใช่ช่องว่างในเรซูเม่ คุณอาจเคยเห็นเทสต์ล้มเหลวเพราะข้อมูลไม่ดีหรือสภาพแวดล้อม (environment) ล่ม แต่คุณยังไม่เคยเห็นเทสต์ล้มเหลวเพราะคุณไปเจอข้อบกพร่องในตรรกะ (logic)
เลิกมุ่งแต่จะอ่านหนังสือสอบใบเซอร์ใหม่ๆ แล้วมาปิดช่องว่างนั้นด้วยการเขียนเทสต์ที่ออกแบบมาเพื่อให้มัน "พัง"
ลองทำแบบฝึกหัดนี้ดู: เลือกมาหนึ่งฟีเจอร์ แล้วใช้เวลาหนึ่งชั่วโมงพยายามทำให้มันพัง
สำหรับฟีเจอร์การค้นหา:
- ทดสอบด้วยคำค้นหาที่ไม่มีความหมาย (gibberish)
- ทดสอบด้วยตัวอักษร SQL injection
- ทดสอบด้วยค่าว่าง (empty strings)
สำหรับการอัปโหลดไฟล์:
- ทดสอบไฟล์ที่ไม่มีนามสกุล
- ทดสอบไฟล์ที่มีขนาดใหญ่ยักษ์
- ทดสอบชื่อไฟล์ที่เป็นอันตราย (malicious)
ครั้งหนึ่งผมเคยทำงานในระบบชำระเงินที่มี Test Coverage ถึง 95% ทุกการทดสอบผ่านฉลุย แต่แล้วระบบกลับทำเงินหายในขั้นตอน Production เพราะข้อผิดพลาดจากการปัดเศษ (rounding error) การทดสอบของเราครอบคลุมแค่ Happy Path แต่ไม่มีใครคิดที่จะทดสอบตรรกะทางคณิตศาสตร์เลย
ตอนนี้ ทุกครั้งที่ผมเริ่มทดสอบ ผมจะตั้งคำถามหนึ่งอย่างเสมอว่า: "ต้องเกิดเงื่อนไขอะไรขึ้น ฟีเจอร์นี้ถึงจะทำงานผิดพลาดโดยที่เราไม่รู้ตัว (fail silently)?"
อย่ามัวแต่สร้างเว็บไซต์ Portfolio อย่ามัวแต่ไปอัปเดต LinkedIn ของคุณ
จงเขียนการทดสอบหนึ่งอย่างที่ออกแบบมาเพื่อให้ "พัง" ถ้ามันผ่าน แสดงว่าคุณมีหลักประกันความปลอดภัย แต่ถ้ามันพัง แสดงว่าคุณเจอ Bug แล้ว
จดบันทึกไว้ว่าคุณทดสอบอะไร ทดสอบอย่างไร และคุณพบอะไร นั่นคือหลักฐานที่แท้จริงว่าคุณเป็นคนที่รู้จักคิด
สัปดาห์นี้ คุณจะเขียนการทดสอบอะไรหนึ่งอย่าง เพื่อพิสูจน์ว่าคุณสามารถหา Bug ได้?
ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi