มีคำถามที่พี่กิ่งได้ยินบ่อยมากตอนบอกให้ใครแตก e2e ยาวๆ ออกเป็น scenario ย่อยๆ คือ
“แล้วเราจะรันสเต็ปเดิมซ้ำหลายรอบเหรอ”
“แบบนี้เทสก็จะเพิ่มขึ้นเยอะเลย”
“จะไม่เสียเวลารันนานเกินไปเหรอ”
พี่กิ่งจะมาเล่าสิ่งที่เคยเจอให้ฟังค่ะ
.
ตอนที่พี่กิ่งเริ่มเขียน automation test ใหม่ๆ ก็เขียนเป็น flow ยาวๆ เหมือนกันค่ะ
คิดว่าไหนๆ ก็เทสแล้ว ก็ทำให้ครบไปทีเดียวเลย
Login -> สร้าง product -> verify -> แก้ไข product -> verify -> ลบทิ้ง
รันผ่านก็ดีใจ รันครั้งเดียว ไปใส่ result ว่าผ่านได้หลายข้อเลย
แต่พอมันพังขึ้นมา… ก็งงว่ามันพังตรงไหน
เสียเวลาไล่หาไปอีกเป็นวัน
.
รอบสอง “ฉันจะแยก”
ทีนี้ก็ทำแบบที่เราคุยกันไปโพสก่อนหน้านี้ค่ะ
ไปแตก test scenario ออกให้ย่อยลงไปอีก เพื่อให้มันเทสแค่อย่างเดียว
ตอนนี้การ “แก้ไข product” ก็เลยมี test scenario แยกออกมาเป็นของตัวเอง
ทำให้อ่านง่ายขึ้นมาก เวลาอะไรพังก็เช็คได้เร็วขึ้น
แต่ข้างในยังเหมือนเดิมทุกอย่าง แค่แยกออกเป็น 2 scenarios
- Login -> สร้าง product -> verify
- Login + เตรียม data ด้วยการสร้าง product -> แก้ไข product -> verify
.
แต่มันก็ยังต้องพึ่งคนอื่นอยู่ดี
แล้ววันนึง ฟีเจอร์ “สร้าง product” พัง
สรุปก็พังทั้ง 2 scenario อยู่ดี แถมเรายังไม่รู้ด้วยว่าจริงๆ แล้ว การแก้ไข product มันยังทำงานได้อยู่มั้ย เพราะเทสยังไปไม่ถึงตรงนั้น มันชิงตายไปซะก่อน
.
หนักกว่านั้น อยู่มาวันนึง Login พัง!!!
รอบนี้ทุก scenario พังหมดเลย เพราะทุกข้อต้อง login ก่อนตลอด
พอผ่าน login ไปไม่ได้ ก็เช็คอะไรต่อไม่ได้เลย
ตอนนั้นแหละ พี่กิ่งถึงได้รู้ว่า เราไม่ได้เทสแค่การ สร้าง หรือ แก้ไข product อย่างเดียว แต่เรากำลังเช็คว่า login + create + edit ทำงานได้มั้ย ไปพร้อมๆ กัน
การเตรียมรันเทส ในสเต็ป Given หรือ pre-condition ของเรา
กลายเป็น test case ที่ซ่อนอยู่ข้างใน test case อีกที
.
ทางออกที่ใช้ได้จริง
ยังไงเทสเราก็ต้อง set state ค่ะ เพราะมันเป็นการเตรียมระบบของเราให้พร้อม ไม่ว่าจะเป็น state (เช่น เปิดหน้าไหนอยู่ หรือ ต้อง login มาแล้ว) รวมทั้ง test data (เช่น ต้องมีข้อมูล product อยู่แล้ว ก่อนจะแก้ไข)
แต่ถ้าเราเตรียมผ่าน UI ก็แปลว่า scenario ของเรา ยังต้องพึ่งพาการทำงานของ UI ตรงนั้นอยู่ค่ะ
แทนที่จะใช้ UI เราลองเปลี่ยนท่าดูค่ะ
.
💡 ใช้ API:
ใน scenario “แก้ไข product” เราสร้าง product โดยเรียกผ่าน API แทน
เร็วกว่า และ stable กว่าใช้ UI และ ถึง UI จะพังก็ไม่กระทบ
แต่… วิธีนี้ ก็ยังขึ้นอยู่กับ API อยู่ดี ถ้า API พังก็เจอปัญหาเดิม แต่ก็ดีกว่าใช้ UI เยอะค่ะ
.
💡 ใช้ data ที่มีอยู่แล้ว: query database ที่มีอยู่แล้ว
ใน test environment ของเราจะมี data ที่เราสร้างไว้อยู่แล้ว เราใช้ database ไป query ออกมาใช้ได้เลย เช่นไปหาว่า มี product ไหนที่ใช้ได้บ้าง แล้วก็ใช้ data นั้นในการเทส แก้ไข product แทน
แต่… วิธีนี้ ก็ยังขึ้นอยู่กับ data ที่เรามีอยู่ดีค่ะ ถ้าวันไหนไม่มี data ขึ้นมา เทสก็พัง
.
💡 ใช้ Auth Token หรือ การ login ด้วย API
ทำได้ทั้งขอ token ผ่าน API หรือ ให้ dev ช่วยหาท่าที่สามารถเอามาได้ง่ายกว่า login ด้วย UI ก็ได้ค่ะ แล้วก็เอามาใช้ใน browser โดยตรง โดยที่ไมต้องพึ่งการ Login ด้วย UI ถึงจะพังก็ยังเทสอย่างอื่นต่อได้
วิธีนี้ อาจจะขัดความรู้สึกของหลายคน เพราะมันเป็นเรื่องการ login ที่ควรจะต้องมี security ใช่มั้ยคะ แต่ให้คิดว่า เรากำลังเทสการทำงานของฟีเจอร์ ไม่ได้เทสการ login ค่ะ
ส่วนการเทสว่า “ถ้าไม่ login หรือ login ไม่ถูก ต้องใช้ฟีเจอร์นี้ไม่ได้” เราแยกออกไปเทสต่างหากได้เลยค่ะ
.
💡 Seed Data:
การ Seed data คือเรายัด data ที่เราจะใช้เข้าไปใน database เลย หรืออาจจะเตรียม database ทั้งก้อน ที่มีข้อมูลที่เราต้องใช้เทสแต่ละ scenario เตรียมไว้แล้ว เช่น มีข้อมูล user, product, การสั่งซื้อ ที่ต้องใช้
แล้วทุกครั้งก่อนจะเริ่มรันเทส เราก็ทำให้ database ของเราอยู่ในสภาพที่เราเตรียมไว้ (ตรงนี้อาจจะต้องมีวิชาอาคมนิดหน่อย หรือจะให้ dev, devops ช่วยก็ได้ค่ะ) วิธีนี้ตอนรันเทสเราจะรู้แน่นอนเลยว่าต้องหยิบ data ไหนมาใช้ในเคสไหน ต้องใช้เวลาเตรียมเยอะหน่อยค่ะ แต่ถ้าทำได้ ชีวิตเราจะง่ายขึ้นมาก
.
ผลที่ได้
✅ ทีนี้ถึง Login จะพัง ก็ยังเทสได้ปกติ
ถ้า scenario แก้ไข product พัง ก็รู้ได้เลยว่ามันพังที่นี่ ไม่ใช่ “อาจจะพังเพราะ login พัง” หรือ “อาจจะพังเพราะ สร้าง product ไม่ได้”
✅ และ Test Suite ของเรา รันได้เร็วขึ้นมากๆ เพราะไม่ต้องพึ่งพาการกด UI ทุกข้อ
จะรันสเต็ปเดิมซ้ำหลายๆ ที่ก็ไม่เป็นไร เพราะมันเร็วอยู่แล้ว
✅ เทสพัง ก็ debug ง่ายสุดๆ
เพราะเรารู้อยู่แล้วว่าเทสข้อนั้น ต้องการเช็คเรื่องอะไร
.
แล้วเราก็จะตอบคำถามตอนต้นได้หมดเลย
“แล้วเราจะรันสเต็ปเดิมซ้ำหลายรอบเหรอ”
ซ้ำก็ไม่เป็นไร เพราะเราไม่ได้กด UI แต่ใช้วิธีที่เร็วกว่า และ stable กว่า
“แบบนี้เทสก็จะเพิ่มขึ้นเยอะเลย”
เหมือนเดิมค่ะ เยอะก็ไม่เป็นไร เพราะแต่ละเทสจะดูแลง่ายขึ้นมากๆ
“จะไม่เสียเวลารันนานเกินไปเหรอ”
เสียเวลารันนานขึ้นอีกนิด ดีกว่าเสียเวลามานั่งหาว่าทำไมเทสถึงพังค่ะ เพราะอย่างหลังใช้เวลาเยอะกว่าเยอะมากๆ!
.
เห็นมั้ยคะว่า เขียน automation ได้แล้ว เป็นแค่จุดเริ่มต้นเท่านั้นเอง
เทสที่ดี ไม่ใช่เทสที่กดได้ตามที่เขียนไว้ทุกอย่าง
แต่คือ เทสที่รู้ว่าต้องการจะเช็คอะไร และ ถ้ามันเฟล เรารู้ได้ทันทีว่าอะไรพัง
และการเตรียมระบบให้อยู่ใน state ที่พร้อมก่อนจะเริ่มรันเทส ก็เป็นส่วนหนึ่งในนั้นค่ะ