เคยมั้ยคะ มี Automation Test เป็นหมื่นข้อ
แต่ก็เหมือนไม่เคยมีอยู่จริง
มี Automation Test พร้อมแล้ว วิ่งทุกวันวันละ 3-4 ชั่วโมง
แต่พอรันเสร็จ…
แดงเถือก!!! Fail เพียบ
แต่ไม่มี Bug จริงซักอัน
แถมทีมต้องเสียเวลามานั่งเช็คเองอีก
แล้วเราก็ต้องไปไล่เช็ค ดูไปทีละเคสว่าตายเพราะอะไร
บางอันก็ต้องไปลองรัน Manual ดูว่าเป็นบั๊กจริงมั้ย
เสียเวลาไปอีกหลายชั่วโมง กว่าจะตอบได้ว่า build นี้พร้อมหรือไม่พร้อม
แล้วเราก็มานั่งนึกว่า ที่มี Automation Test เนี่ย มันช่วยเราอยู่จริงใช่มั้ย
หรือแค่ย้ายจากงาน Manual Test มาเป็น Manual ดูแล script แทน
.
พี่กิ่งเคยเจอปัญหานี้มาแล้วค่ะ
มีเทสรันทุกวัน วันละเป็น 10,000 ข้อ รัน Parallel อีกต่างหาก
Regression Test ครบทุกอย่าง ครอบคลุมหมดทุก Requirement
ตัวเลขดูดีมากเลยใช่มั้ยคะ
แต่ชีวิตจริงคือกุมหัวทุกวัน 10,000 ข้อ เฟลไปแล้ว 20,000 ข้อ
เช้ามาเข้าออฟฟิสก็กด Rerun อีกละ เดี๋ยวผ่านบ้างไม่ผ่านบ้าง
บางข้อก็ต้องไปนั่งเช็ค Manual เอง
สุดท้ายเป็นยังไงรู้มั้ยคะ
ไม่มีใครเชื่อผลเทสอันนี้เลย
มันแดง ทุกคนก็ปล่อยให้มันแดงอยู่อย่างนั้น
ไม่ได้มีใครรู้สึกว่าต้องรีบมาดู เพราะรู้ว่ามันไม่ stable
.
จนสุดท้ายทนไม่ไหว เลยไปนั่งไล่ดูว่ามันเกิดอะไรขึ้นบ้าง
ปัญหาหลักๆ ก็ตามที่อยู่ในโพสที่แล้วเลยค่ะ (ตามไปอ่านได้ https://withnatsiree.com/why-automation-test-fail/)
❌ เทสหนึ่งข้อทำหลายอย่างเกินไป เป็น E2E heavy สุดๆ พังจุดนึง ทั้ง flow ก็พัง
❌ Hardcoded Data ทั้งนั้น เทสคิดเอาเองว่าต้องมี data นี้อยู่ พอ data หายไป ก็พัง
❌ แค่นั้นยังไม่พอ บางข้อยังไปรอ data จากข้ออื่นอีก รันสลับกันหน่อย ก็พัง
❌ ไม่มีการทำ Isolation ระหว่างแต่ละข้อ บางทีไปแย่ง data กันเอง ก็พัง
❌ ต่อจากข้อเมื่อกี๊ อยากรันให้เร็วขึ้น ไปรัน parallel อีก แย่งกันกว่าเดิมอีก ก็พัง
กลายเป็น Test Suite ที่ไม่มีใครเชื่อเลยค่ะ
เทสที่ไม่มีใครเชื่อ Result ก็คือเทสที่ตายไปแล้ว แค่รอวันฝัง!
.
คิดว่าอาจจะมีบางคนที่อ่านมาถึงตรงนี้ หรืออ่านโพสที่แล้วสงสัยว่า
รู้ปัญหาแล้วจะทำยังไงต่อ หรือลองแก้แล้วแต่แก้ไม่ได้
วันนี้เลยอยากจะเล่าให้ฟังค่ะ ว่าพี่กิ่งผ่านจุดนั้นมาได้ยังไง
.
📌 1. Atomic Test – one test, one objective
เทสหนึ่งข้อ ต้องทดสอบแค่หนึ่งอย่างเท่านั้น
เป็นข้อที่สำคัญมากๆ และอาจจะขัดกับความเชื่อของหลายๆคนด้วยค่ะ
ตอนนั้นที่บอกให้ทีมไปทำแบบนี้ ก็ได้คำถามกลับมาเยอะเลยค่ะ
บางคนกลัวต้องทำซ้ำหลาย step แล้วจะเสียเวลา
บางคนกลัวต้องเตรียม data เยอะขึ้น
บางคนกลัวเทสเยอะแล้วจะรันนาน
แต่ปัญหาทั้งหมดที่กลัวกัน แก้ได้นะคะ
และสิ่งที่ได้กลับมาคือ เวลาเทสพัง เรารู้ทันทีว่าอะไรพัง
ไม่ต้องเสียเวลาไล่เช็คกันเป็นชั่วโมง
ถ้าเทสเฟลสิบข้อ เช็คข้อละห้านาที ก็เกือบชั่วโมงแล้วนะคะ
ยิ่งสเกลใหญ่ระดับเป็นหมื่นนี่ไม่ต้องพูดถึง
เพราะฉะนั้น การทำให้รู้ได้ง่ายที่สุดว่ามันเฟลเพราะอะไร คือวิธีที่ดีที่สุดค่ะ
.
📌 2. Dynamic & Isolated Test Data
แทนที่จะไปพึ่ง test data ที่มีในระบบอยู่แล้ว
เราก็ query เอาตอนที่รันเลยว่ามีอะไรให้ใช้บ้าง
หรือจะดีกว่านั้น ก็สร้างใหม่ทุกครั้งผ่าน API สำหรับเตรียม data
หรือจะดียิ่งกว่านั้นอีก ก็ทำ seed data โหลดข้อมูลเข้า db ก่อนรันไปเลย จะได้รู้ว่ามีแน่นอน
พอเทสแต่ละข้อใช้ data ของตัวเอง ไม่มีการแย่งข้อมูลกัน
ก็ลดปัญหาเทสพังเพราะ data ไม่ถูกไปได้เลย
แถมยังเป็นอิสระจากกัน อยากรัน parallel แค่ไหนก็ตามสบายเลย
.
📌 3. ทำ Environment ให้พร้อม
หลังจากแก้ข้อ 1 กับ 2 ไปแล้ว นึกว่าจะใช้ได้แล้ว
ก็ยังไปเจอเรื่องอื่นที่ทำให้พังอีกค่ะ แก้กันต่อ
เลยไปเจอว่า Test Environment มันไม่ stable พอ
บางทีเจอ timeout กลางทาง เพราะรันนานเกินไป
บางที database รับโหลดไม่ไหว เพราะสร้าง test data เพิ่มทุกวัน
ยิ่งเทสรันพร้อมกันหลายข้อ ยิ่งหนัก Environment เข้าไปอีก
ก็เลยช่วยกันเตรียม cleanup script ไว้ด้วยค่ะ ทำกันหลายท่าเลย
ทั้ง reset test data ให้กลับสภาพเดิม
หรือ ดึง data จริงจาก production มาทำ masking พวก sensitive data แล้วก็โหลดกลับเข้าไป
ขึ้นอยู่กับ setup ของแต่ละทีมเลยค่ะ ว่าท่าไหนเหมาะกว่ากัน
แค่นี้ก็ลดเทสที่พังแบบไม่มีสาเหตุไปได้อีกเยอะ
.
📌 4. Parallel Execution
หลังจากเราเตรียมทุกอย่างพร้อมแล้ว
Test ทุกข้อ เป็น Atomic แยกขาดกันชัดเจน
Data แยกขาดกันหมดทุกข้อ
Environment ก็พร้อมรับแรงกระแทก
ทีนี้ก็ Parallel ไปเลยค่ะ เต็มที่ อยากได้เลขเท่าไหร่ใส่ไปเลย
ตอนนั้นเรารันกันที่ 2-300 threads ค่ะ เรียกว่าไปได้ถึงแค่ไหนก็เอาเลขนั้นเลย
.
✅ ผลที่ได้ จาก 4 ชั่วโมง เหลือ 1 ชั่วโมง
แต่สิ่งที่ได้นอกเหนือจาก execution time ที่ลดได้
คือเวลาที่ทุกคนต้องมานั่งไล่ตามเช็คสิ่งที่ Fail เนี่ย ลดไปมหาศาลค่ะ
และที่สำคัญกว่านั้น พอเทสเราเริ่มนิ่ง ทุกคนก็เชื่อผลเทสของเรามากขึ้น
ทุกครั้งที่ Fail แปลว่ามีบั๊กจริง
เราจะเริ่มเห็น Dev เข้าไปช่วยดูว่า Fail เพราะอะไร แล้วก็แก้บั๊กมาให้เลย
จะเริ่มมีคนมาขอให้เรารัน Regression Test ให้บ่อยขึ้นเวลาที่แก้อะไรไป
หรือบางที Dev เอาไปรันเองเลยก็มี
QA ก็จะมีเวลาไปทำงานที่มีคุณค่ามากขึ้น แทนที่จะมานั่งดูแล Test Suite ทั้งวัน
.
เห็นมั้ยคะ Automation Test ที่ดี ไม่ได้วัดจากจำนวน Test Case หรือ Test Coverage อย่างเดียวนะคะ
แต่วัดได้ง่ายๆ เลยจาะ ความเชื่อมั่นใน Test Suite ของเรา
ถ้าผ่านแปลว่าผ่านจริงมั้ย
ถ้าไม่ผ่านล่ะ แปลว่ามีบั๊กจริงมั้ย
เริ่มจากตรงนี้ก่อนได้เลยค่ะ
.
แล้ว Automation Test ของทุกคนตอนนี้ เป็นยังไงกันบ้างคะ
ทีมยังเชื่อมันอยู่มั้ยคะ