เทสที่ผ่านตลอด ไม่ได้แปลว่าใช้ได้เสมอไป

“อย่างสีเขียว”
ไม่ได้แปลว่าเทสนี้ใช้ได้เสมอไป

.

ใครเขียน Automation Test มาซักพัก
น่าจะเริ่มชอบสีเขียวขึ้นมาอย่างบอกไม่ถูกใช่มั้ยคะ
เวลาเห็น test รันผ่านฉลุย เขียวหมด
แล้วมันรู้สึกว่า test ของเรานี่มันช่างเริ่ดจริงๆ

เราเขียน test เอาไว้จับว่าระบบมันทำงานถูกมั้ย
แล้วมีใครเคยเช็คมั้ยคะ ว่า test ของเราทำงานถูกจริงรึเปล่า?

ส่วนใหญ่เห็นสีเขียว แล้วก็รู้สึกสบายใจ ปิดจ๊อบ จบงาน
แต่ไม่มีใครถามต่อว่า ถึงเวลาที่มีบั๊กขึ้นมาจริงๆ test นี้จะจับมันได้มั้ย

🟢🟢🟢

พี่กิ่งอยากมาแชร์ประสบการณ์ตรงเลยค่ะ
หลายปีมาแล้วตอนที่ไปสัมภาษณ์กับ Google
มีรอบนึง คุยกันเรื่อง unit test ค่ะ
เป็น technical interview ที่คุยกันแค่เรื่อง unit test เลย

พี่กิ่งก็คุยไปโดยเข้าใจว่า unit test ที่ว่า คือ ส่วนที่เทสระบบของเรา ที่ปกติ dev เขียนนั่นแหละค่ะ

ปรากฏว่าคุยกันจนจบ เค้าถึงบอกว่า ที่คุยกันทั้งหมด เค้าหมายถึง unit test ของ Automation Test นะ

ฟังจบแล้ว อยากจะกรี๊ดออกมาตรงนั้นเลยค่ะ
รู้เลยว่าจบแล้ว ชั้นไม่ผ่านแน่ (แล้วก็ไม่ผ่านจริงๆ)
ก็เลยแอบถามเค้าต่อว่า มันคืออะไร ทำยังไงบ้าง แล้วเค้าก็ใจดี แชร์ให้ฟังด้วยค่ะ

เรียกว่าเปิดโลกมาก ว่า บ. ระดับโลก เค้าเขียน test ให้กับ test อีกทีนึงด้วย

.

💡 สิ่งที่สำคัญมากๆ คือ Automation Test ก็คือโค้ดเหมือนกัน

เพราะฉะนั้น เราจะต้องจัดการมันให้อยู่ในระดับเดียวกันกับโค้ดของ dev ค่ะ
จะปล่อยปละละเลย เพราะคิดว่ามันเป็นของ QA ไม่ได้
เพราะในเมื่อมันเป็นโค้ด ก็แปลว่ามันมีบั๊กได้เหมือนกัน

(ใครเคยอยู่ในทีมพี่กิ่งน่าจะรู้ว่าเรารีวิวกันโหดแค่ไหน)

.

📌 Test ที่มีบั๊ก ก็อันตราย พอๆ กับระบบที่มีบั๊กเลยค่ะ

Test ที่เฟลให้เราเห็นจะๆ เลยยังดีกว่า เพราะเรารู้ว่าต้องเข้าไปแก้
แต่ Test ที่ผ่านตลอด ทั้งๆ ที่จริงๆ มีบั๊ก กว่าจะรู้ตัวอีกที ก็อาจจะขึ้น production ไปแล้ว

และมันก็ปล่อยให้เรามั่นใจแบบผิดๆ มาตลอด

.

หนึ่งในสาเหตุที่เจอบ่อยๆ เลย คือเรื่อง Expected Value นี่แหละค่ะ
บ่อยครั้งเลยที่เราไปเอาวิธีคิดคำนวณมาจากโค้ดที่ dev ใช้
แล้วก็เอามาไว้ใน test ของเรา เพื่อให้มันคิดว่า ผลลัพธ์ที่ถูกต้องควรเป็นอะไร

ก็ฟังดูสมเหตุสมผลดี

แต่ถ้า logic ที่เราเอามาใช้มันมีบั๊กอยู่
ก็กลายเป็นว่าบั๊กนั้น ก็จะติดเข้ามาใน test ของเราด้วย

ยกตัวอย่างเช่น
การคำนวณ VAT หลังหักส่วนลดในระบบมันผิด เพราะดันคิด VAT ก่อน แล้วหักส่วนลดทีหลัง
แต่ความจริง ต้องหักส่วนลดก่อน แล้วค่อยคิด VAT

ถ้า QA เอา logic เดียวกันไปคำนวณราคาใน Automation Test จะเกิดอะไรขึ้น…

ผลคือ ทำยังไงก็เขียว!!! 🟢
เพราะทั้งสองที่มันผิดตรงกัน!

.

📌 แล้วเราควรจะทำยังไง

👉 Specification by Example ช่วยได้

ใน expected result ของ test case มันไม่ควรมีการคิดคำนวณอะไรแล้วค่ะ
มันควรจะรู้แบบชัดๆ ไปเลยว่า Input เข้ามาเป็น A ต้องตอบ B

ถ้าเมื่อไหร่มันตอบ C ก็จะรู้เลยว่าผิดทันที โดยที่ไม่ต้องสนใจว่า logic ของระบบจะทำอะไรบ้าง

อย่างเคสคำนวณราคา เราก็ตั้ง scenario ไว้เลยว่า
ถ้าราคา 100 ส่วนลด 10%
VAT = (100 – 100×0.1) x 7% = 6.3

ถ้าตัวเลขออกมาไม่ใช่ 6.3 ก็จะรู้ว่าต้องมีอะไรผิดแน่นอน

.

👉 อย่าลืมเช็คทุกครั้งว่ามันจับบั๊กได้จริงมั้ย

ลองเช็คว่า ถ้ามันมีอะไรพังขึ้นมาจริงๆ test ของเราต้องเฟล

อาจจะลองไปแก้ระบบให้มันพัง หรือลอง mock data ที่จะทำให้พังเข้าไปก็ได้
ใครใช้ tool ใหม่ๆ เช่น playwright หรือ cypress ก็จะมี network interception ให้เราลองเล่นได้

ถ้า test ของเรากลายเป็นสีแดง ก็เป็นอันว่าใช้ได้
(แล้วอย่าลืมแก้กลับให้เหมือนเดิมนะคะ)

.

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

Test ที่ไม่เคยจับบั๊กได้จริง บางทีก็แย่กว่าการไม่มี test อีกค่ะ
เพราะเราอาจจะกำลังมั่นใจกับสิ่งที่ไม่ได้เป็นจริงอยู่ก็ได้