Technical

“ที่ทีมใช้ Robot Framework แล้วจะเรียนคอร์สที่ใช้ Playwright ได้มั้ย”“อยากสมัครงานที่ใช้ Cypress จะเลือกเรียน Cypress ก่อนดีมั้ย”“ถ้าเรียนแล้วจะไปปรับใช้กับ tool อื่นได้มั้ย” ช่วงนี้มีคนทักมาถามพี่กิ่งเรื่อง tool สำหรับ automation test หลายคนค่ะทุกคำถาม พี่กิ่งตอบว่า “ได้ค่ะ” แต่มันอาจจะเป็นคำตอบที่สั้นเกินไป . จริงๆ แล้ว คำถามพวกนี้ไม่ได้มีคำตอบแค่ “ได้” หรือ “ไม่ได้” ค่ะที่สำคัญกว่าคือ “ได้แค่ไหน” และ “ทำยังไงได้บ้าง” เพราะถ้าตอบไปว่าได้ แล้วถึงเวลาไปเจอ syntax ที่ต่างกันเราอาจจะรู้สึกว่า ไม่เห็นจะเอาไปปรับใช้ได้ตรงไหนเลย วันนี้เลยอยากพาไปดูกันให้ชัดๆ เลยค่ะว่าเราจะทำยังไง ถึงจะตอบคำถามเรื่อง tool นี้ได้แล้วเราจะเอาไปปรับใช้ข้าม tool ยังไงได้บ้าง . 📍 ไม่ว่าจะ tool ไหน หลักการการเขียน Automation Test ก็ยังเหมือนเดิมค่ะ ลองดูตัวอย่างง่ายๆ เช่น

ใครเป็น Manual QA อยู่บ้างคะอยากเริ่ม Automation Testing มานานหลายเดือน หลายปีแต่ก็ไม่รู้จะเริ่มยังไง แค่ลองเปิดขึ้นมาดู แล้วก็ไม่รู้จะไปไหนต่อสุดท้ายก็เลยไม่ได้เริ่มซักที . มีคำถามยอดฮิตหนึ่งข้อ ที่พี่กิ่งได้รับทุกๆ ครั้งที่เปิดรับสมัคร Automation Testing the Right Way“ถ้าเขียนโค้ดไม่เป็น จะเรียน Automation Testing ได้มั้ย” ได้ค่ะ ได้ ได้แน่นอน!!! รู้อะไรมั้ยคะ ใน Automation Testing เนี่ยการเขียนโค้ดคือสิ่งที่เรียนรู้ได้ง่ายที่สุดเลยค่ะแล้วสิ่งที่ยากมันคืออะไร เดี๋ยวจะเล่าให้ฟัง . ก่อนอื่นมาเริ่มจากว่า Automation Testing มันคืออะไรกันแน่? สมมติว่าเรามี test case ของฟีเจอร์ login ที่เราเขียนไว้ประมาณนี้ Expected: เข้าหน้า Dashboard ได้ และเห็นชื่อ user ถูกต้อง ที่มุมขวาบน . ถ้าเราเอาไปเขียน Playwright ก็อาจจะได้หน้าตาประมาณนี้ค่ะ

ทีมบอกให้ทำ BDD เราก็ทำ เขียน Given-When-Then มาเป็นปีแต่ก็ตอบไม่ได้ว่าสิ่งที่ทำอยู่เนี่ย มันดีจริง หรือแค่เขียนตาม syntax ไปวันๆ . Scenario ก็ออกมาครบ รันผ่านหมดเขียวทั้งกระดานปิด ticket สบายใจ จนมีคนมาดู feature file แล้วกุมหัวนั่นแหละ“อันนี้มันเทสอะไรนะ”“อธิบายได้มั้ย อ่านแล้วไม่เข้าใจเลย” . Test ที่แค่ “รันผ่าน” กับ Test ที่เอาไปใช้ “สื่อสารได้จริง” มันคนละเรื่องกันเลยนะคะเขียวหมด แปลว่าไม่พัง แต่ไม่ได้แปลว่าคนอื่นอ่านแล้วเข้าใจว่าเรากำลังเทสอะไรอยู่ วันนี้พี่กิ่งเลยลองรวบรวม 5 สัญญาณเตือน จากสิ่งที่เจอมาบ่อยๆที่บอกว่า Given-When-Then ของเราอาจจะทำให้คนอื่นกุมหัวได้ลองเอาไปเช็คกับสิ่งที่เรากำลังเขียนอยู่ได้เลยค่ะ . 1️⃣ And… And… And… And… And…❌ เมื่อไหร่ที่เจอ And ติดกันยาวๆ เยอะๆ เนี่ย หยุดเลยค่ะมันแปลว่าเรากำลังยัดหลายเรื่องเอาไว้ใน scenario เดียวลองถอยออกมาดูก่อนว่า เป้าหมายของเราคืออะไร แล้วเราจะแยกออกมาเป็นหลาย

มีใครเป็น QA คนเดียวในทีม แล้วรู้สึกเครียดมั้ยคะงานเทสปกติก็ต้องทำ automation test ก็ต้องเขียนแล้วก็กลัวว่าจะไม่รอด จะเขียน automation test ยังไงให้ทันเวลา จริงๆ เราไม่ได้แพ้เพราะเราเขียนโค้ดไม่เร็วหรอกค่ะแต่มันมักจะเป็นเพราะเราเลือก test case ผิดตั้งแต่แรก พอเลือกผิดตั้งแต่ต้น ยิ่งขยันเท่าไหร่ก็ยิ่งช้า ทำไปเท่าไหร่ก็ไม่พอเขียนไปเป็นร้อยข้อ แต่ก่อนขึ้น production ก็ไม่มั่นใจ ต้องมาไล่เทสมือทุกรอบอยู่ดี 😮‍💨 . ถ้าเราเป็นคนนั้นอยู่ เป็นคนที่มีเวลาเขียน automation test แค่สัปดาห์ละไม่กี่ชั่วโมงไม่มีคนช่วยรีวิวโค้ด ไม่มีทีมมาช่วยแบ่งงาน การทำให้ “ครบ” อาจจะเป็นไปไม่ได้เลยค่ะ สกิลที่สำคัญกว่านั้นคือ “การเลือกให้คุ้ม” 📌 เกณฑ์ที่ใช้ตัดสินใจ ถ้ายังไม่รู้จะตัดสินใจยังไง ลองดู 3 เรื่องนี้ก่อนค่ะ รันบ่อยแค่ไหน x พังแล้วเจ็บแค่ไหน x นิ่งหรือยัง ลองเอามาดูพร้อมกัน ไม่ใช่ทีละตัวเคสที่พังแล้วเจ็บหนัก แต่มีลูกค้าใช้ปีละครั้ง ก็อาจจะไม่ใช่เคสแรกที่ควรเลือกมาเขียน . ✅ เคสที่ควรเริ่มก่อน 👉

พี่กิ่งเป็นคนนึงที่จะทำ coding interview เวลาต้องสัมภาษณ์ตำแหน่ง Automation QA ค่ะไม่ใช่เพราะอยากเช็คว่าเขียนโค้ดเก่งแค่ไหนนะคะแต่อยากรู้ว่ามีวิธีรับมือกับปัญหายังไงบ้าง ที่ผ่านมาสัมภาษณ์มาหลายคน สิ่งที่เห็นประจำเลยคือ “หลายคนไม่กล้าทำ” มีทั้งคนที่ขอไม่ทำเลย บอกว่าทำไม่ได้แล้วก็จบแค่นั้นบางคนขอเอากลับไปทำที่บ้านบางคนนิ่งไปเลย แล้วนั่งทำเงียบๆ ไม่ถามอะไร . พี่กิ่งเข้าใจทุกคนนะคะ เพราะน่าจะกดดันมาก อยู่ๆ มาโดนขอให้เขียนโค้ดให้ดูบางคนอาจจะคิดว่า คนสัมภาษณ์ต้องการเห็นคำตอบที่ perfect, syntax เป๊ะ รันผ่านในครั้งเดียว แต่จริงๆ แล้ว อยากบอกทุกคนว่า พี่กิ่งไม่ได้ให้คะแนนอะไรพวกนั้นเลยค่ะ 💡 สิ่งที่อยากเห็นจริงๆ คือ “วิธีคิด” ต่างหาก คำถาม coding มักจะเป็นแค่จุดเริ่มต้น เพื่อที่จะดูวิธีการจัดการกับปัญหาค่ะเช่น ดูว่าถ้าให้โจทย์ไปแล้ว จะทำยังไง จะถามเพื่อเช็คให้แน่ใจก่อนมั้ย หรือจะโดดลงไปเขียนโค้ดเลยมีการจัดลำดับความคิดของตัวเองก่อนมั้ย หรือคิดไปโค้ดไป สุยๆ ไปตามทาง บางทีอาจจะมีคำถามต่อหลังจากนั้นอีก เช่น จะเทสยังไง คิดว่ามีตรงไหนที่จะเจอบั๊กได้บ้าง บางคนที่ได้ไปต่อ ก็ไม่ใช่คนที่เขียนโค้ดได้เป๊ะแบบเอามารันได้จริง ก็มีบ่อยไปค่ะ . และความจริงก็คือ QA อย่างเรา

พอถึงจุดนึง Automation Test ของเราจะเริ่ม “หนัก” มีใครกำลังเจอบ้างคะ . ไม่ใช่หนักเพราะมี test case เยอะ มีข้อใหม่ๆ เพิ่มขึ้นทุกวัน แต่มันหนักเพราะ ทุกครั้งที่กลับมาอ่าน เราจะงง และต้องใช้เวลาทำความเข้าใจมากกว่าเดิมคนในทีมต้องมาทำต่อ ก็งง “ตัวแปรนี้มาจากไหนเหรอ เอาไว้ทำอะไร”ส่งให้ Dev ช่วยดูก็งง ให้ Business ช่วยเช็ค ก็งง หรือไม่ก็ แก้ requirement นิดเดียว แต่ Test พังหลายที่รัน local ผ่าน แต่ขึ้น CI แล้วต้องไปลุ้นตลอด . ส่วนใหญ่เรามักจะคิดว่า ก็ Test มันซับซ้อนขึ้น เยอะขึ้น มันก็เป็นเรื่องธรรมดาแต่จริงๆ ปัญหามักไม่ได้อยู่ที่โค้ดของ Automation Test ของเราค่ะหลายครั้งที่พี่กิ่งเจอ ต้นเหตุส่วนหนึ่งมาจาก test data ที่กระจัดกระจายอยู่เต็มไปหมดเพราะเราไม่ได้วางมันไว้ให้ถูกที่ตั้งแต่แรก . ลองนึกภาพตามดูค่ะ

มาคุยเรื่อง Automation Test กันต่ออีกซักหน่อย กับอีกหนึ่งปัญหาที่ทำให้“เมื่อวานยังรันผ่านอยู่เลย ทำไมวันนี้เฟลอีกแล้ว ไม่มีใครแก้อะไรซักนิด” เคยเจอกันมั้ยคะเมื่อวาน pass วันนี้ fail ลอง rerun ดูซักหน่อย pass อีกแล้ว ยังไม่ได้แตะโค้ดสักบรรทัดอยากจะจับ Automation Test ของเรามาถามว่าเกิดอะไรขึ้น ทำไมผีเข้าผีออกทำอะไรตามใจแบบนี้ บอกเลยว่าคุณไม่ได้เจออยู่คนเดียว(ใช่ค่ะ พี่กิ่งก็เคยเจอ กว่าจะหาทางแก้ปัญหาได้ บางทีใช้เวลาเป็นเดือน) และส่วนใหญ่มันไม่ได้เกิดจาก tool ไม่ดี หรือ เราเขียนไม่ดีหรอกค่ะอีกหนึ่งในสาเหตุที่เจอบ่อยๆ คือ วิธีที่เราจัดการกับ test data วันนี้จะพาไปเจาะลึกอีกหนึ่งเรื่องที่มักจะทำให้เจอปัญหาบ่อยๆ ค่ะคือ Static Data กับ Dynamic Data . 🧊 Static Data คืออะไร คือค่าที่เรากำหนดไว้ตายตัวใน test เลย บางทีเราเรียกว่า hardcode ค่ะเช่น บอกไปเลยว่าใช้ username: “test01@test.com”

มีคำถามที่พี่กิ่งได้ยินบ่อยมากตอนบอกให้ใครแตก e2e ยาวๆ ออกเป็น scenario ย่อยๆ คือ “แล้วเราจะรันสเต็ปเดิมซ้ำหลายรอบเหรอ”“แบบนี้เทสก็จะเพิ่มขึ้นเยอะเลย”“จะไม่เสียเวลารันนานเกินไปเหรอ” พี่กิ่งจะมาเล่าสิ่งที่เคยเจอให้ฟังค่ะ . ตอนที่พี่กิ่งเริ่มเขียน automation test ใหม่ๆ ก็เขียนเป็น flow ยาวๆ เหมือนกันค่ะคิดว่าไหนๆ ก็เทสแล้ว ก็ทำให้ครบไปทีเดียวเลย Login -> สร้าง product -> verify -> แก้ไข product -> verify -> ลบทิ้ง รันผ่านก็ดีใจ รันครั้งเดียว ไปใส่ result ว่าผ่านได้หลายข้อเลย แต่พอมันพังขึ้นมา… ก็งงว่ามันพังตรงไหนเสียเวลาไล่หาไปอีกเป็นวัน . รอบสอง “ฉันจะแยก” ทีนี้ก็ทำแบบที่เราคุยกันไปโพสก่อนหน้านี้ค่ะไปแตก test scenario ออกให้ย่อยลงไปอีก เพื่อให้มันเทสแค่อย่างเดียว ตอนนี้การ “แก้ไข product” ก็เลยมี test scenario แยกออกมาเป็นของตัวเองทำให้อ่านง่ายขึ้นมาก

ใครเคยเขียน scenario แบบนี้บ้างคะ Scenario: ทดสอบการ checkoutGiven ผู้ใช้ login แล้วWhen เพิ่มสินค้าลงตะกร้าAnd กรอกที่อยู่จัดส่งAnd เลือกวิธีชำระเงินAnd กด confirm orderThen ระบบแสดงหน้า order successAnd ส่ง email ยืนยันAnd ตัดยอดบัญชีWhen ผู้ใช้ดู order historyThen เห็น order history ถูกต้อง . Scenario เดียว เทสมันให้หมดทุกอย่างไหนๆ ก็ทำไปแล้ว ก็เทสให้ครบไปเลย จะได้ไม่เสียเวลา พี่กิ่งเข้าใจความรู้สึกนี้มากๆ เลยค่ะเพราะเป็นคนนึงที่เคยทำแบบนี้มาก่อน! แล้วก็ต้องมาชดใช้กรรม หาวิธีแก้สิ่งที่ตัวเองทำไว้ 😅 เพราะจริงๆ scenario ด้านบน ถือว่าไม่ได้ทำตามหลักของ BDD แล้วค่ะ . ❌ ปัญหาคืออะไร? Scenario ที่ดี ต้องเทสแค่ 1 behavior

เขียน Automation Test Scenario เป็น Gherkin ไว้ 40 ข้อลองรันบนเครื่องก็ผ่านหมด ส่งขึ้นไปบน CI/CD ก็ผ่าน ทีมภูมิใจมาก เรามี Automation Test ที่ Test Coverage ดีเยี่ยม ครอบคลุมครบทุก requirement ผ่านไป 2 สัปดาห์ มีการอัพเดต UI เข้ามา 🔴 เทสพังไป 38 ข้อทีมต้องวิ่งวุ่นไปไล่อัพเดตจุดที่หน้า UI เปลี่ยน ปัญหาไม่ได้เกิดเพราะโค้ดพัง แต่เพราะเขียนผิดวิธีมาตั้งแต่แรก . เรื่องนี้เป็นอีกหนึ่งปัญหาที่เจอบ่อยมากๆ ในทีมที่เพิ่งทำ Automation Test ค่ะ วันนี้จะพาทุกคนไปรู้จักกับวิธีเขียน Scenario 2 แบบ คือ Imperative กับ Declarative กันค่ะและถ้าเลือกผิด ชีวิตอาจจะเปลี่ยนโดยไม่รู้ตัว . 📌 Imperative