เคยรู้สึกมั้ยคะว่าตัวเองเป็นคนสุดท้ายที่ต้องรับจบตลอด เวลาเกิดอะไรขึ้น
🐛 เจอบั๊กก่อนขึ้น production… ทำไมก่อนหน้านี้เทสไม่เจอ
🐛 ลูกค้าเจอบั๊ก… QA เทสรึเปล่า ทำไมหลุด
🐛 Requirement เปลี่ยนกลางคัน… ต้องเริ่มเทสใหม่หมด แต่ deadline ยังเป็นวันเดิม
ทั้งๆ ที่บางทีปัญหามันก็เกิดมาตั้งนานแล้ว ก่อนจะมาถึงมือเราด้วยซ้ำ
แต่ทำไมถึงจะต้องมาพังเอาตอนท้ายๆ แล้วงานก็ดีเลย์ทุกที
.
พี่กิ่งเดาว่าหลายๆ คนที่อ่านอยู่ตอนนี้ ก็น่าจะเคยรู้สึกแบบนี้ใช่มั้ยคะ
QA แบบเรามักจะโดนถามเสมอ “เทสรึยัง ทำไมไม่เจอ” แล้วเราก็ “รับจบตลอด”
ทั้งๆ ที่ปัญหามันเกิดขึ้นมาตั้งแต่ตอน design แล้ว
แล้วทำไมเราไม่ไปหามันให้เจอตั้งแต่ต้นทางไปเลยล่ะ!
.
ลองมาดูเคสตัวอย่างกันดีกว่าค่ะ
สมมติว่าเรากำลังสร้างแอปช็อปปิ้งตัวนึงอยู่ แล้วก็ต้องเก็บข้อมูลวันที่ของออเดอร์นั้น แต่ไม่มีใครคุยกันว่าเราจะเก็บวันที่ใน timezone ไหน ทุกคนเข้าใจเอาเองว่าก็ต้องรู้อยู่แล้วว่าต้องเป็น timezone ที่เป็น local time สิ ไม่ใช่ UTC (ที่เป็นเวลาสากลคือ GMT+0) ก็เลยไม่มี requiremnt ตรงไหนพูดถึงเรื่องนี้ เพราะทุกคนคิดว่า “ก็น่าจะเข้าใจอยู่แล้ว”
ปรากฏว่า backend เก็บวันที่เป็น UTC แล้วก็ไม่มีใครรู้ จนกระทั่งลูกค้าสั่งของเข้ามาตอน 6 โมงเช้า แล้วระบบไปเก็บว่าเป็นออเดอร์ของวันก่อนหน้า เพราะเวลา UTC ยังเป็น 5 ทุ่มของวันก่อนหน้าอยู่ พอลูกค้าหาออเดอร์ของวันนั้นไม่เจอ ถึงได้รู้ว่า timezone ผิด!
❌ ทีนี้กลายเป็นไม่ใช่แค่แก้บั๊กนิดเดียวแล้วจบ เพราะระบบหลังบ้านอาจจะไม่เคยจัดการกับเรื่อง timezone เลย กลายเป็นต้องไปไล่หา แล้ว design logic ใหม่ ใช้เวลาหลายวัน
✅ แต่ลองคิดดูนะคะ ถ้ามีคนถามตั้งแต่วันที่คุย requirement กันตอนแรกว่า “เราจะเก็บวันที่เป็น timezone ไหน” อาจจะใช้เวลาแค่ 5 นาที และทุกคนก็จะเข้าใจตรงกัน และก็จะทำให้ไม่มีบั๊กนี้เกิดขึ้น เพราะ backend ก็จะ design โดยที่คิดเรื่อง timezone เอาไว้ตั้งแต่แรกแล้ว
ผลลัพธ์ต่างกันมหาศาล ระหว่าง 5 นาทีที่คุยกันแต่แรก กับ การต้องมาเร่งแก้บั๊กโดยการออกแบบระบบใหม่เพราะลูกค้าเจอปัญหาบน production
.
📌 นี่คือคำว่า Shift-Left ค่ะ
เราทำยังไงก็ได้ให้การเทสมันเกิดขึ้นได้เร็วที่สุด
และสิ่งที่สำคัญคือ mindset ของทีมค่ะ ว่าเรากำลังมอง quality ว่าเป็นแค่ขั้นตอนหนึ่ง หรือ เป็นความรับผิดชอบร่วมกันของทั้งทีม
เมื่อไหร่ที่เรามองว่าเป็นความรับผิดชอบร่วมกันของทั้งทีม คำถามจะเปลี่ยนไปเลย
จากเดิมที่ถามว่า “ทำไม QA เทสไม่เจอ” กลายเป็น “ทำไมมันถึงหลุดออกมา และเราจะป้องกันบั๊กนี้ตั้งแต่แรกได้ยังไง”
เพราะคำว่า “ทำให้การเทสมันเกิดขึ้นได้เร็วที่สุด” มันไม่ได้หมายถึงแค่การเขียน test case แล้วไปรันเทสอย่างเดียว แต่มันยังหมายถึงว่า
✅ เราจะตั้งคำถามตั้งแต่ตอนคุย requirement ได้มั้ย
✅ เราจะทำ unit test ไปตั้งแต่ตอนที่เขียนโค้ดเลยได้มั้ย
✅ เราจะมี regression test ที่รันอัตโนมัติได้บ่อยๆ ได้มั้ย
.
ซึ่งถ้าทีมไหนมี mindset ที่เป็นแบบนี้แล้ว การเข้าไปของ QA ก็จะเริ่มได้ง่ายหน่อยค่ะ
แต่… ถ้าทีมยังไม่พร้อมล่ะ เราจะ shift left ได้ยังไง
จะให้ไปสู้คนเดียวก็อาจจะเหนื่อยใช่มั้ยคะ เราคนเดียวอาจจะเปลี่ยน culture ของทั้งทีมไม่ได้
แต่มันก็มีบางอย่างที่เราสามารถเริ่มได้เลยค่ะ
.
1️⃣ ลองขอเข้าไปนั่งฟังตั้งแต่ design ไม่ว่าจะเป็นการคุย requirement, grooming ช่วงแรกๆ อาจจะแค่นั่งฟังเฉยๆ ก่อนก็ได้ เพื่อให้เราเข้าใจก่อนว่าเค้าคุยอะไรกัน
2️⃣ พอเริ่มเข้าใจแล้ว ค่อยลองตั้งคำถาม “ถ้า…” ดูค่ะ เช่น “ถ้า user ทำ xxx จะเกิดอะไรขึ้น” ไม่ต้องรอตอนเริ่มเขียน test case ก็ได้
3️⃣ ลองเริ่มแชร์ test case ของเราให้ทีมดูก่อนค่ะ อาจจะเป็นแค่ scenario ที่เราจะเทสคร่าวๆ เอาไปคุยกับ PO/BA หรือ Dev ก่อนที่เค้าจะเริ่มเขียนโค้ด แค่นี้ก็อาจจะทำให้ป้องกันบั๊กไปได้เยอะแล้ว
แล้วทำไปเรื่อยๆ ทีมจะเริ่มคุยกันมากขึ้นไปเอง ยิ่งเราคุยกันเยอะขึ้น ก็ยิ่งทำงานง่ายขึ้น และจะยิ่งเจอปัญหาเร็วขึ้นด้วยค่ะ ทั้งหมดนี้เป็นสิ่งที่เราทำได้เลย โดยที่ไม่ต้องรอใคร approve หรือ รอให้ process เปลี่ยน ไม่ต้องรอให้ automation test พร้อม
.
ใครที่อยาก shift left แต่ยังไม่รู้จะเริ่มยังไง ลองเอาไปปรับใช้ดูนะคะ
ลองดูว่าคำถามไหนที่เราถามออกมาให้เร็วขึ้นได้ แล้วลองมาดูกันว่าจะมีอะไรเปลี่ยนไปบ้าง