Technical

6 วิธีง่ายๆ ที่ทำให้ Test Stable ขึ้นได้ทันที . ไม่ว่าคุณจะเพิ่งเริ่มเขียน Gherkin เพื่อใช้เป็น Acceptance Criteriaหรือ เอาไปใช้เป็น Feature File ใน Automation Test อยู่แล้ว มีสิ่งนึงที่เราทุกคนเจอเหมือนกันค่ะ เขียน Scenario ไปหมดแล้ว Given-When-Then ครบทุกข้อแต่ทีมก็ยังอ่านไม่รู้เรื่อง ไม่มีใครเข้าใจว่าจะเทสอะไรหรือถ้าใช้ใน Automation Test อยู่ ก็พังหมดจนตามแก้แทบไม่ไหว ปัญหาไม่ใช่ว่า Gherkin ไม่ดีแต่อยู่ที่วิธีที่เราเขียนมันต่างหาก วันนี้พี่กิ่งเอา checklist 6 ข้อมาฝากกันค่ะเอาไปทำตามกันได้เลย . 📌 1. บอกว่า “ต้องการอะไร” ไม่ใช่ “ทำยังไง” Gherkin ที่ดี ต้องบอก behavior ค่ะ สิ่งที่ต้องการจะทำคืออะไรไม่ใช่ implementation ว่าทำยังไง ขั้นตอนเป็นยังไง เรามาลองดูตัวอย่างกันค่ะ ❌ […]

ทีมใครใช้ BDD กันอยู่บ้างคะ ตอนที่พี่กิ่งได้ยินคำว่า BDD ครั้งแรกมันมาคู่กับคำว่า Cucumber ค่ะ 🥒 แล้วทุกคนก็บอกว่าเราจะเริ่มเขียน Test และ Acceptance Criteria แบบนี้กันนะทุกคนก็ไปเริ่มทำตาม รวมทั้งพี่กิ่งด้วย ทั้งที่ตอนนั้นยังไม่รู้เลยว่า BDD คืออะไรรู้แค่ว่า Cucumber มันเขียน Given-When-Then แล้วเราก็เริ่ม ทำ BDD กัน จนผ่านมาซักพักนั่นแหละค่ะถึงได้รู้ว่าเราไม่ได้เข้าใจอะไรมันจริงๆ เลยสักนิด 😅 . 🤔 Cucumber ≠ BDD นี่คือความเข้าใจผิดที่เจอบ่อยที่สุดในวงการ QA เลยค่ะ BDD ไม่ใช่ CucumberBDD ไม่ใช่ GherkinBDD ไม่ใช่ Given-When-Then ไม่ใช่อะไรซักอย่าง แล้วมันคืออะไรกันแน่ จริงๆ แล้วทุกอย่างที่พูดไปมันคือคนละเรื่องกันเลยค่ะ . 💡 BDD คือ วิธีคิดและวิธีทำงานของทีม Behavior-Driven Development

💡 เลิกกางตำราเขียน Test Case แล้ว EP/BVA จะมีค่าขึ้นมาทันที จาก Test Design Workshop ครั้งที่แล้ว มีคำถามนึงที่คนถามเข้ามาเยอะก็คือ EP BVA ไอ้ตัวย่ออะไรพวกนี้เนี่ย มันคืออะไร ซึ่งวันนั้นพี่กิ่งบอกไว้ว่า ยังไม่ต้องสนใจ เพราะจริงๆแล้วเราไม่ควรเริ่มต้นจากสิ่งนี้ค่ะ  วันนี้เลยจะอยากมาขยายความเพิ่มเติมให้อีกนิด เผื่อว่าจะช่วยตอบคำถามของหลายๆ คนในวันนั้นได้นะคะ คิดว่าหลายๆ คนน่าจะเจอปัญหาคล้ายกัน ที่ตอนเรียนเราก็เข้าใจดีอยู่หรอกว่ามันคืออะไร แต่พอเจองานจริง เจอ Requirement จริง ก็ไม่รู้จะเอาไปใช้ยังไง หรือบางคนเริ่มมาก็กางตำรา ใส่เทคนิคเข้าไปรัวๆ เสร็จแล้วก็ไม่มั่นใจอยู่ดีว่า Test Case ครบหรือไม่ครบกันแน่ อย่างที่พี่กิ่งย้ำบ่อยๆ ค่ะ สิ่งที่สำคัญที่สุดคือ “วิธีที่เราเริ่มต้นคิด” ต่างหาก ที่จะบอกว่าเราเป็น QA ทั่วไป หรือ เป็น QA ร่างทอง ถึงตรงนี้ถ้าใครยังไม่รู้จักว่า EP BVA คืออะไร สามารถเข้าไปดูในโพสเก่าได้นะคะ ในนี้จะมีอธิบายพื้นฐานเอาไว้ เดี๋ยวเรามาลองตัวอย่าง Requirement

เคยเป็นเหมือนกันมั้ยคะเขียน Test Case ไปเป็น 100 ข้อ เช็คครบทุกอย่างแล้ว แต่พอ Release ไปจริงๆลูกค้าดันเจอบั๊กที่เราไม่เคยคิดถึงเลย 🫠 ปัญหาไม่ได้อยู่ที่เราเทสน้อยเกินไปค่ะ แต่เราอาจจะกำลังเทสไม่ตรงจุดเพราะเราแตก task ย่อยเกินไป อย่างสมมติว่าเราต้องเทสหน้า Login พอเห็นปุ๊บเราก็จะคิดทันทีว่ามี Username / มี Password / มีปุ่ม Login → เช็คไปทีละอัน พอครบก็ผ่าน มันไม่ได้ผิดค่ะ แค่… ไม่พอ เพราะ User จริงๆ เค้าใช้งานระบบค่ะ เค้าอาจจะ Login ผิดซ้ำ 2-3 รอบเพราะจำ password ไม่ได้เค้าอาจจะปิดแท็บไป แล้วกลับมาใหม่ หรือเค้าอาจจะเปิดค้างไว้จน session หมด บั๊กที่หลุดไปส่วนใหญ่ ไม่ได้หลุดเพราะแต่ละ field ทำงานไม่ถูก แต่มันหลุดเพราะ ช่วงรอยต่อระหว่างแต่ละส่วนที่เราไม่ได้คิดถึงค่ะ ลองดูตัวอย่างต่อจากหน้า Login กันค่ะ ❌ แบบที่คนมักทำ (เช็ค

ถ้าใครเคยส่ง Bug Report ไปแล้วโดนถามกลับมาว่า “Reproduce ยังไง” หรือ โดนตีกลับมาว่า “ไม่ใช่บั๊ก” บ่อยๆ นั่นอาจจะเป็นสัญญาณว่า report ของเรายังไม่สามารถช่วยให้ Dev ทำงานได้ อย่าเพิ่งโทษว่าเป็นความผิดของใครนะคะเรามาดูกันดีกว่าว่า Bug Report ที่ดี ควรจะมีอะไรบ้าง วันนี้พี่กิ่งเอา 3 เคสจริงมาให้ดูกันว่า แบบที่ ✅ ควรทำ และ ❌ ไม่ควรทำ ต่างกันยังไง ตัวอย่างที่ 1: ระบบคำนวณส่วนลดผิด ❌ แบบนี้งง Description: ใส่ coupon แล้วราคาไม่ถูกExpected: แสดงส่วนลดถูกต้องActual: คำนวณส่วนลดผิด ปัญหาคือ “ไม่ถูก” “ถูกต้อง” “ผิด” คือยังไง คำนวณส่วนลดผิด หรือ แสดงผลไม่ถูก อ่านแล้วบอกไม่ได้เลยใช่มั้ยคะ dev ต้องเดาเอาว่าจะไปเริ่มดูโค้ดตรงไหน จะลองเทสเองด้วย coupon ไหนกับสินค้าอะไร

เทสผ่านฉลุย เขียวทุกเคส ให้ผ่าน พร้อม Releaseแต่พอ Deploy ขึ้น Prod เท่านั้นแหละ User ดันเจอบั๊กซะงั้น!!! เนี่ยแหละชีวิต พี่กิ่งเชื่อว่า QA ทุกคนต้องเคยผ่านเหตุการณ์นี้กันมาบ้างแหละบอกเลยว่า มันไม่ได้แปลว่าเราเทสไม่เก่งนะคะแต่มันเกิดจากการที่เราอาจจะเผลอเดินตามสิ่งที่เรียกว่า“Happy Path” มากเกินไป Happy Path คือเส้นทางที่โลกสวยงามที่สุดที่จะเกิดขึ้นได้ค่ะUser กรอกข้อมูลถูกต้องเป๊ะ กดตามสเต็ป 1-2-3 ไปเรื่อยๆอย่างถูกต้องแต่ในโลกความเป็นจริง User มีมากมายหลากหลาย บางทีก็อาจจะทำอะไรที่ “ไม่ปกติ” บ้าง และบั๊กก็มักจะซ่อนอยู่แถวๆนั้นแหละค่ะ ไม่ใช่ว่า Happy Path ไม่สำคัญนะคะ มันคือสิ่งที่สำคัญมากๆๆๆๆ และควรจะเทสเป็นลำดับแรกแต่สิ่งที่นอกเหนือจากนั้นก็สำคัญเช่นกัน และที่สำคัญกว่านั้นคือ เราจะทำยังไง ถึงจะเทสความ “ไม่ปกติ” เหล่านั้นได้ครอบคลุมมากที่สุด โดยไม่เหนื่อยจนเกินไป วันนี้พี่กิ่งเลยอยากมาแชร์ 2 เทคนิคการทำ Test Case Design ที่จะช่วยให้เราดักจับบั๊กได้ดีขึ้นช่วยลดจำนวน Test Case ลง แต่ได้ Coverage

😱 ใครเคยเป็นบ้าง เห็น Error เด้งขึ้นมาเป็นพรืดๆๆ ใน Console แล้วทำตัวไม่ถูกหรือ Dev ขอ API Payload ไปใช้ investigate bug ก็ทำหน้างงไม่รู้จะต้องส่งอะไรไป วันนี้พี่กิ่งจะพาไปทำความรู้จัก JSON กันนะคะ “น้องเจสัน” ที่ไม่ใช่คน แต่น้องคือ “ข้อความ” ที่ระบบส่งมาบอกเราว่าเกิดอะไรขึ้นหลังบ้านบ้างค่ะ 💡 ลองนึกภาพตามนะคะ: การอ่าน JSON ก็เหมือนเราอ่าน “ใบออเดอร์ GrabFood” นั่นแหละ! แค่เรารู้ว่าฟอร์แมทของใบออเดอร์เป็นยังไง เราก็อ่านรู้เรื่องได้สบาย ✅ โครงสร้างหลักคือ Key & Value ที่จะมาเป็นคู่หูดูโอ้เสมอ ลองมาดูตัวอย่างง่ายๆ กับแอพที่เราน่าจะใช้ทุกวัน ว่า QA ทั่วไป กับ QA ร่างทอง ต่างกันยังไง สมมติว่าเราเทส Food Delivery App อยู่แล้วเจอปัญหาว่ากดสั่งอาหารแล้วขึ้น Error

สารภาพมาค่ะ… ทุกวันนี้ใครเปิด Postman มาแล้วทำแค่นี้บ้าง ✋ ถ้าใช่ พี่กิ่งบอกเลย “เสียของ!!”เพราะ Postman จริงๆ แล้วมีฟีเจอร์มากมายที่ช่วยให้เราเทสได้ง่ายขึ้น ประหยัดเวลาได้มากขึ้น  ใครอยากเป็น QA ร่างทอง มาดู 3 ฟีเจอร์นี้กันค่ะ รับรองเทสง่ายขึ้น 300% 🔥 1. Environment Variables: หยุดแก้ URL ทีละตัว! 🛑 Before (ชีวิตเศร้า):สมมติเรามี 50 Requests ที่ยิงไปที่ https://dev-api.shopping.com/xxxxเทสบน Dev Environment อยู่ดีๆ ทีมบอก “เดี๋ยวจะเอาขึ้น Staging แล้ว ฝากเทสอีกรอบหน่อย” 😱 สิ่งที่เกิดขึ้น:ถ้าใครไม่ได้ใช้ Environment Variables จุดนี้เศร้า! เพราะเราต้องมานั่งแก้ URL ทั้ง 50 ตัว จาก dev-api เป็น

ถ้าใครทำงานเป็น QA หรืออยู่ในสายนี้อยู่แล้วน่าจะรู้จัก Postman กันดีอยู่แล้ว (ส่วนใครที่ยังไม่รู้จัก เอาเป็นว่ามันเป็นเครื่องมือในการใช้เทสอีกตัวนึง แล้วเดี๋ยวโพสต่อๆ ไปเราจะมาเจาะลึกเครื่องมือนี้กัน) ล่าสุด Postman ประกาศเตรียมปล่อยของช่วงมีนาคม 2026 นี้ เตรียมตัวอัพเกรดสกิลกันได้เลยค่ะทุกคนพี่กิ่งลองเข้าไปส่องมาแล้ว บอกเลยว่ารอบนี้เปลี่ยนเยอะมากจริงๆ และนี่คือ 3 ไฮไลท์ที่ QA อย่างพวกเราน่าจะต้องรู้ค่ะ: 1️⃣ Native Git Workflows (ซักที!!!): 🐙 อวสานปัญหาส่ง collection กันไปมา แล้วก็แก้ทับกัน! เวอร์ชั่นใหม่เราทำงานได้เหมือนเขียนโค้ดเลยค่ะ แตก feature branch มาทำงานได้เลย 2️⃣ AI Native: 🤖 ไม่ใช่แค่ผู้ช่วยเขียนเทสเล็กๆ น้อยๆ แล้ว แต่รอบนี้ AI จะสามารถ อ่าน เขียน และ คิด เชื่อมโยงข้อมูลใน Workspace ได้ น่าจะช่วย Generate

Severity vs Priority เรื่องเส้นผมบังภูเขาที่ QA หลายคนยังสับสน เคยเถียงกับ Dev หรือ PO เรื่อง Severity หรือ Priority กันมั้ยคะอันนี้คนนั้นบอก Critical คนนี้บอกไม่ใช่ Medium ก็พอ อีกคนบอก ไว้แก้รอบหน้าก็ได้ ตรงนี้คนไม่ได้ใช้เยอะขนาดนั้น แล้วสรุปใครถูก… ในฐานะที่เป็นคนที่ต้องใส่ Severity ลงไปใน Bug Ticket ของเราเนี่ย เราจะเชื่อใครดี แล้วเราจะรู้ได้ยังไงว่าทีมควรจะแก้เรื่องนี้ “เดี๋ยวนี้” เลย หรือ”รอก่อน” ก็ได้ จริงๆแล้วปัญหานี้แก้ได้ง่ายมาก ถ้าเราแยกคำว่า Severity และ Priority ให้ขาดค่ะ 🔥 1. Severity = ความรุนแรง ผลกระทบที่มีต่อระบบว่ารุนแรงแค่ไหน เราต้องลองถามตัวเอง หรือถามทีมดูว่า บั๊กนี้มีพลังทำลายล้างมากแค่ไหนระบบพังแค่ไหน กระทบฟีเจอร์อื่นมั้ย หรือไปขวางการทำงานของระบบอื่นหรือเปล่า ตัวอย่างเช่น: กด Save