ทำไมต้อง Automate Testing

ทีมไม่ได้เริ่มทำ automation เพราะเบื่อเฉย ๆ

หลายทีมเริ่มสนใจ automation ในจังหวะที่ manual testing เริ่มไม่พอแล้ว เช่น:

• ทุก sprint ต้องรัน regression ชุดเดิมซ้ำ
• release ใกล้ทีไร QA ต้องเร่งตรวจ flow หลักแบบแทบไม่พัก
• พอเวลาไม่พอ ทีมต้องตัดบางเคสออกทุกครั้ง
• dev อยากได้ feedback เร็ว แต่ต้องรอ QA จนงานค้าง

ปัญหาเหล่านี้ไม่ใช่เพราะ QA ทำงานไม่ดี แต่เพราะระบบเริ่มใหญ่เกินกว่าที่การตรวจแบบ manual อย่างเดียวจะรับไหว

ตัวอย่างที่เจอบ่อย

สมมติระบบ e-commerce มี flow หลัก 6 ส่วน:

• login
• search
• add to cart
• checkout
• payment
• order history

ถ้าทีม deploy บ่อยขึ้นจากเดือนละครั้งเป็นสัปดาห์ละหลายครั้ง แต่ regression suite ยังต้องรันด้วยมือเกือบทั้งหมด ปัญหาจะมาเร็วมาก:

• QA ใช้เวลาส่วนใหญ่ไปกับงานเดิม
• exploratory testing ถูกเบียดหาย
• บั๊กหลุดเพราะความล้า ไม่ใช่เพราะไม่รู้วิธีเทสต์

นี่คือบริบทที่ automation เริ่มมีความหมาย

อย่ามองแค่ “เร็วกว่า” ให้มองว่า “ทำให้ทีมทำงานคนละแบบ”

1. Speed

งานที่ manual ใช้ครึ่งวัน บางครั้ง automation อาจเหลือไม่กี่นาที ซึ่งไม่ได้แปลว่าแค่ “จบไวขึ้น” แต่หมายถึง:

• ทีม merge งานได้เร็วขึ้น
• release decision มาเร็วขึ้น
• defect ถูกจับก่อนลาม

2. Consistency

manual test ทำโดยคน ซึ่งแปลว่ามีผลจาก:

• ความเหนื่อย
• ความเคยชิน
• การตีความ step ไม่เท่ากัน

automation ช่วยให้เคสเดิมถูก execute แบบเดิมทุกครั้ง ลด noise จากมนุษย์ในงานที่เป็น routine

3. Repeatability

บาง flow ต้องรัน:

• ทุก pull request
• ทุก deploy
• ทุกคืน

ถ้ายังใช้ manual ทั้งหมด ทีมจะเริ่มเลือกรันเฉพาะบางส่วน แต่ automation ทำให้การรันซ้ำบ่อย ๆ เป็นเรื่องปกติได้

เป้าหมายไม่ควรเป็น “QA ว่าง” แต่เป็น “QA มีเวลาไปทำงานที่มีคุณค่ากว่า”

เวลาที่ automation ช่วยประหยัดได้ มักถูกเอาไปใช้กับงานที่มนุษย์ยังเก่งกว่า เช่น:

• exploratory testing
• requirement review
• risk assessment
• bug investigation
• test design ที่ซับซ้อน

ถ้ามองแบบนี้ automation ไม่ได้มาแทน QA แต่มาช่วยย้าย effort จากงานซ้ำ ๆ ไปสู่งานคิดวิเคราะห์มากขึ้น

จาก regression ที่กินเวลา 2 วัน เหลือรายงานที่เช็กตอนเช้า

สมมติทีมหนึ่งมี regression suite 250 เคสสำหรับระบบ subscription:

• ก่อน automation: QA 2 คนใช้เวลาเกือบ 2 วันก่อน release
• หลัง automation: core regression 60 เคสถูกรันทุกคืน

สิ่งที่เปลี่ยนจริงไม่ใช่แค่เวลา:

• bug บางตัวถูกจับตั้งแต่วันเดียวกับที่ merge
• QA ไม่ต้องรอใกล้ release ค่อยเห็นปัญหา
• ทีมเริ่มกล้าปล่อยของถี่ขึ้น เพราะมี safety net บางส่วน

ตรงนี้คือเหตุผลที่หลายทีมมอง automation เป็นตัวเร่ง feedback loop มากกว่าจะมองว่าเป็นแค่การ “เขียน script”

ถ้าเป้าหมายผิด ผลลัพธ์ก็ผิดได้

สิ่งที่ automation ทำไม่ได้ด้วยตัวมันเอง:

• ไม่ช่วยเลือกว่าควรทดสอบอะไร
• ไม่รับประกันว่าทีมกำลังทดสอบสิ่งที่สำคัญจริง
• ไม่แทนสายตาของมนุษย์ในเรื่อง usability หรือ exploratory discovery

บางทีมรีบเริ่มเขียน test scripts เยอะมาก แต่ไม่ได้ตอบคำถามพื้นฐานก่อนว่า:

• flow ไหนควร automate ก่อน
• ระดับการทดสอบไหนเหมาะ
• ใครจะดูแล suite นี้ระยะยาว

ผลคือได้ suite ใหญ่ แต่เปราะและไม่มีใครรักมัน

ถ้าทีมเริ่มเจออาการเหล่านี้ ให้เริ่มคิดจริงจังได้

• regression ซ้ำเดิมจนกินเวลาทีมมาก
• มี flow หลักที่ต้องมั่นใจทุก release
• ทีม deploy บ่อยขึ้น
• มี bug regression เกิดซ้ำ
• dev ต้องการ feedback เร็วกว่าเดิม

ไม่จำเป็นต้องรอให้ระบบใหญ่ระดับ enterprise ก่อนถึงจะเริ่ม แต่ก็ควรเริ่มเพราะ pain ที่ชัด ไม่ใช่เริ่มเพราะกระแส

เริ่มให้ถูก จะประหยัดแรงในระยะยาวมาก

ก่อนเริ่ม คุณควรถามอย่างน้อย:

1. เรากำลังอยากแก้ pain อะไร
2. flow ไหนสำคัญและรันบ่อยที่สุด
3. ระดับไหนเหมาะกว่า ระหว่าง unit, integration, UI automation
4. ใครจะดูแล test suite นี้เมื่อ feature เปลี่ยน
5. จะวัดความคุ้มค่าจากอะไร เช่น regression time, escaped defects, release confidence

การตอบคำถามพวกนี้ทำให้ automation เป็นกลยุทธ์ ไม่ใช่โปรเจกต์เขียนสคริปต์แบบไร้ทิศทาง