เคยมั้ยคะ รอ Dev ทำฟีเจอร์ให้เสร็จพร้อมเทสมาเป็นอาทิตย์ พอได้มาเทสจริงๆ ปุ๊บ…
แค่กดปุ่มแรกไป หน้าจอก็หมุนไม่หยุด หรือ Error แดงเถือก!
แล้วเราก็จะรู้สึกว่า “ให้ฉันรอแล้วได้อะไร” ในเมื่อของก็ยังพังอยู่แบบนี้แล้วชั้นจะเทสยังไงไหว
พอไปบอก Dev ก็อาจจะได้คำตอบว่า เดี๋ยวต้องไปแก้ Logic หลังบ้านก่อน แล้วต้องแก้ UI ให้รับค่าใหม่ด้วย
สรุป… ต้องรอต่อไปอีก 2 วันเพื่อให้ระบบพร้อมเทส (อีกรอบ)
นี่แหละค่ะคือความเจ็บปวดของการทำ UI-Heavy Testing
หรือที่บางคนอาจจะเคยเห็นชื่อ “Ice Cream Cone Testing” 🍦
คือการทำเทสผ่านหน้าจอ (Layer บน) เยอะๆ แต่ฐานข้างล่างอย่าง API หรือ Unit Test กลับกลวงโบ๋
กลายเป็นสามเหลี่ยมกลับหัวที่ฐานไม่แน่น พร้อมล้มตลอดเวลา
วันนี้พี่กิ่งจะมาแชร์ให้เห็นภาพชัดๆ ค่ะว่าการมี API First Mindset จะช่วยให้เราเป็น “QA ร่างทอง” ที่เจอบั๊กไวกว่า และทำงานอย่างมีความสุขขึ้นได้ยังไง
🔥 ลองมาดูตัวอย่างจริงกัน จะได้เห็นภาพ
ตัวอย่างที่ 1: 🛵 ฟีเจอร์ “คำนวณค่าส่งตามระยะทาง” ของแอพสั่งอาหาร
Requirements:
ค่าส่งกม.ละ 5 บาท เกิน 10 กม. ลดค่าส่ง 20%
❌ UI Heavy: เราต้องรอจะกว่าหน้าจอเลือกที่อยู่ หน้าสรุปยอดเงิน และปุ่มชำระเงิน เสร็จก่อน
ถึงจะไปถึงหน้าที่สามารถเทสการคำนวณค่าส่งได้ ถ้าหน้าจอโหลดช้า กว่าจะเทสจบแต่ละเคสกินเวลาเป็นนาที
แล้วพอเทสไป 2-3 ชม อาจจะเพิ่งมาเจอว่า“ถ้าระยะทางเกิน 10 กม. ระบบไม่คำนวณค่าส่งให้”
ผลคือ Dev ต้องรื้อ Logic การคำนวณใหม่หมด เท่ากับว่าเราเสียเวลา 2-3 ชม.นั้นไปฟรีๆ เพราะต้องเทสซ้ำใหม่หมดอยู่ดี
✅ QA ร่างทอง ต้อง API First: เราไม่รอหน้าจอค่ะ เราขอ API Endpoint จาก Dev มาเทสก่อนได้เลย
แล้วใช้เครื่องมืออย่าง Postman ส่งข้อมูลของเคสต่างๆ เข้าไปถามตรงๆ แล้วก็เช็คผลการคำนวณจากที่ API ตอบกลับมา
- ลองส่งระยะทาง 5 กม. -> API ตอบ 25 บาท ถูกต้อง ตรงเป๊ะ!
- ลองส่งระยะทาง 100 กม. -> API คำนวณส่วนลดถูกมั้ย
- ลองส่งระยะทางแปลกๆไป เช่น ติดลบ, 0 -> API ต้องด่ากลับมานะ ไม่ใช่ตอบอะไรแปลกๆกลับมา
- และเคสอื่นๆทั้งหมด ที่เราสามารถเตรียมข้อมูลไว้ก่อนได้เลย
การเทสผ่าน API เราสามารถลิสต์เคสของ Logic ที่มีทั้งหมดไว้ให้พร้อม และเตรียมข้อมูล Input ที่จะใช้ในแต่ละเคสไว้ก่อนได้เลย
ตอนเทสเราก็ลองส่งข้อมูลแต่ละแบบที่เตรียมไว้ และเช็คผลลัพธ์ที่ออกมาได้ทันที โดยไม่ต้องรอกดผ่าน UI
ซึ่งการคิดเคสและการเตรียมข้อมูล เราสามารถคุยและรีวิวร่วมกันกับ Dev และ PO เพื่อที่จะได้มีเคสที่ครอบคลุมทั้งทาง Technical และ Business
ตัวอย่างที่ 2: 🔐 ฟีเจอร์สมัครสมาชิกและตั้งรหัสผ่าน
Requirements:
รหัสผ่านต้องมีตัวใหญ่ ตัวเล็ก ตัวเลข และต้องยาวกว่า 8 ตัวอักษร
❌ UI Heavy: เราต้องพิมพ์ชื่อ อีเมล รหัสผ่านที่ผิดเงื่อนไข ทีละข้อ -> กด Submit -> Error เด้ง -> จดผล -> พิมพ์เคสต่อไป วนไปเรื่อยๆ เหนื่อยเหลือเกินพี่ชาย 😩
✅ QA ร่างทอง ต้อง API First: เตรียมรหัสที่ถูกต้อง และ ผิดเงื่อนไขแต่ละแบบไว้เลย เตรียมส่งรัวๆไปให้ API และเช็ค HTTP Status Code ว่าตรงกับ Expected มั้ย
ผลลัพธ์: เจอบั๊กใน 1 วินาที ตั้งแต่ UI ยังสร้างไม่เสร็จ
ตัวอย่างที่ 3: 💸 เคสแปลกๆ หรือสถานการณ์ที่เกิดขึ้นยาก (Edge Cases)
Requirements:
ถ้าลูกค้ากดจ่ายเงินเข้ามาสองครั้ง ระบบต้องห้ามตัดซ้ำ และขึ้น Error สำหรับการจ่ายเงินครั้งที่สอง
❌ UI Heavy: การจะทำให้เกิดเคสนี้ขึ้นบน UI เพื่อเทส Error ที่เกิดขึ้ดนั้นทำได้ยากมากกก
สมมติว่าหน้า UI block ให้กดปุ่มแล้ว disable ทันที เราก็อาจจะต้องเตรียมสองหน้าจอที่กดพร้อมกัน หรือเข้าไปแก้ Database กว่าจะเทสได้อาจจะเสียเวลานานหลายชั่วโมง
✅ QA ร่างทอง ต้อง API First: เราสามารถ Mock ข้อมูล หรือเขียน script เผื่อยิง API เข้าไปซ้ำๆกันได้ง่ายกว่าเยอะ และสามารถเช็คได้ทันทีว่าระบบหลังบ้านรับมือกับเคสนี้ได้มั้ย
💡 จะเห็นว่า API ชนะขาด
- เจอบั๊กใน 1 วินาที: การยิง API คือการคุยกับ Logic ส่วนนั้นโดยตรง ไม่ต้องผ่าน UI การลดเวลาจากหลัก นาที เป็น วินาที นี่ไม่ใช่น้อยๆนะคะ ถ้าเทสกันหลักสิบหลักร้อยเคสก็ประหยัดเวลาไปได้มากเลยทีเดียว
- คัดกรองบั๊กเล็กๆออกไปก่อน: ถ้า API ยังคำนวณเงินผิด ต่อให้หน้าจอจะสวยงามอลังการขนาดไหน มันก็คือแอพที่ใช้ไม่ได้อยู่ดี การเทส API คือการเทส “Logic” ของ Dev ก่อนจะกลายเป็นภาพ
- ลดความขัดแย้ง: ยิ่งเราบอก Dev เร็วแค่ไหนว่า “API ตัวนี้คำนวณเงินไม่ถูกนะ” เขาจะยิ่งกลับไปแก้ได้ง่ายขึ้นและเร็วขึ้น เพราะในตอนนั้นเขาอาจจะแค่กลับไปแก้โค้ดแค่ 2-3 บรรทัดก็เสร็จแล้ว แต่ถ้าเรารอจน UI เสร็จ เขาอาจจะต้องไปแก้โค้ดฝั่ง UI รวมถึงการเชื่อม API ด้วย
How-to: จะคุยกับทีมยังไง (ถ้า Dev บอกว่ายังไม่เสร็จ หรือให้รอเทสทีเดียว)
QA ร่างทองเราต้อง Shift Left ขยับไปช่วยทีมให้เร็วขึ้นค่ะ
- ขอ Contract หรือ Request/Response Schema มาดูก่อน ไม่ต้องรอโค้ดเสร็จก็ได้ค่ะ เราสามารถขอดู API Doc หรือ Swagger ก่อนได้เลย เพื่อที่เราจะได้ช่วยรีวิวได้ตั้งแต่ตอนออกแบบเลย “เอ๊ะ ตรงนี้ต้องส่ง User ID ไปด้วยรึเปล่า” และเราอาจจะเจอบั๊กตั้งแต่ยังไม่เริ่มเทสหรือเขียนโค้ดด้วยซ้ำ)
- อย่ารอ UI เสร็จ ถ้า API พร้อม เราขอ API มาเทสก่อนเลยค่ะ บอกทีมว่าจะได้ช่วยเช็ค Logic ให้ก่อน มีอะไรจะได้รีบบอกตั้งแต่เนิ่นๆ ที่สำคัญคือต้องทำให้ทีมรู้ว่า “เรากำลังช่วยลดงานเขา” ไม่ใช่ไปจับผิดเขา
- ใช้เครื่องมือช่วย ถ้าส่วนไหนยังไม่เสร็จจริงๆ เราสามารถสร้าง Mock Server ขึ้นมาก่อนได้ เพื่อเทสส่วนที่เสร็จได้ก่อน ยิ่งถ้าได้ API Doc หรือ Swagger มาแล้ว เราสามารถเขียน Test Script รอไว้ได้เลย ได้ของมาเทสเมื่อไหร่ กด Run ปุ๊บ รู้ผลปั๊บ!
การเป็น QA ที่ดี ไม่ใช่แค่เทสสิ่งที่เห็นบนหน้าจอเท่านั้น แต่คือการ ตรวจสอบโครงสร้าง (API/Logic) ให้แข็งแรงตั้งแต่เริ่มต้น ยิ่งเราสามารถกรองบั๊กเล็กๆ ออกไปได้เร็วมากแค่ไหน เราก็ยิ่งมีเวลามาทำงานอย่างอื่นที่ช่วยเพิ่ม Value ให้ทีมได้มากยิ่งขึ้นไปอีก อย่างเช่นการทำ Exploratory Test หรือ การทำความเข้าใจ Use case ของ User จริง เป็นต้น
เลิกเทสแบบไอศกรีมโคน 🍦 ที่สวยแต่ละลายง่าย แล้วมาช่วยกันสร้างพีระมิด 🔺 ที่มั่นคงกันเถอะค่ะ!
📌 อ่านมาถึงตรงนี้ ใครอยากลองเริ่มเทส API แต่ยังใช้เครื่องมือไม่คล่อง เดี๋ยวพี่กิ่งจะเริ่ม Series “Postman 101” พาจับมือทำตั้งแต่พื้นฐาน ไปยันเขียน Script เทสแบบอัตโนมัติ ใครไม่อยากพลาดก็กดติดตามเพจ “With Natsiree” ไว้ได้เลยนะคะ