Technical

169 wordpress feature image (18)

แค่คำว่ารักคงยังไม่พอ แค่ Happy Path ก็อาจจะยังไม่พอเหมือนกัน

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

แค่คำว่ารักคงยังไม่พอ แค่ Happy Path ก็อาจจะยังไม่พอเหมือนกัน Read More »

169 wordpress feature image (16)

JSON is not a person: น้องเจสันเป็นใคร แล้วเราจะคุยกับเค้ายังไง

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

JSON is not a person: น้องเจสันเป็นใคร แล้วเราจะคุยกับเค้ายังไง Read More »

169 wordpress feature image (14)

Postman 101: เลิกกดเทสแมนวล แล้วมาเป็น “เทพเซียน API” กันเถอะ

สารภาพมาค่ะ… ทุกวันนี้ใครเปิด 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 เป็น

Postman 101: เลิกกดเทสแมนวล แล้วมาเป็น “เทพเซียน API” กันเถอะ Read More »

169 wordpress feature image (9)

Postman เวอร์ชั่นใหม่มาแน่ พร้อม AI และ Git Native

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

Postman เวอร์ชั่นใหม่มาแน่ พร้อม AI และ Git Native Read More »

169 wordpress feature image (8)

Severity vs Priority

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

Severity vs Priority Read More »

169 wordpress feature image (6)

หยุด!! บอกแค่ว่า “มันพัง” แต่ต้องบอกให้ได้ว่า “พังท่าไหน” ด้วย API Response Code

คิดว่าทุกคนต้องเคยเป็นแบบนี้ เราเทสงานอยู่ดีๆ หน้าจอก็ขึ้น loading ไม่หยุดหรือไม่ก็มี error ตัวแดงเด้งขึ้นมา แล้วทุกอย่างก็ระเบิด เทสต่อไม่ได้  แล้วสิ่งแรกที่เราทำก็คือ วิ่งไปโวยวายกับ Dev (หรือทัก slack) แล้วก็บอกว่า  “หน้า xxx มันพังค่ะพี่” ทีนี้เราอาจจะได้คำถามกลับมาจาก Dev ว่า  “พังยังไง”“หน้าจอโชว์อะไร”“ใส่ data ไม่ถูกรึเปล่า” แล้วเราก็ได้แต่ทำตาปริบๆ ไม่รู้จะตอบยังไงสุดท้ายก็ต้องรอให้ Dev มาเช็คให้ เสียเวลาทั้งคู่ ตรงนี้แหละ คือเส้นแบ่งระหว่าง QA ทั่วไป กับ QA ที่ดี QA ร่างทองที่เราอยากจะเป็นกันQA ที่ดี จะไม่ทำแค่รายงานว่าของพัง แต่เราต้องช่วย “วินิจฉัยโรค” เบื้องต้นได้ด้วย สิ่งแรกที่จะช่วยเราได้คือ API Response Code นี่แหละค่ะ หรือบางทีเราก็เรียกมันว่า Status Code วิธีที่เราจะดูมันได้เนี่ย อย่างแรกเลย เวลาเทสงาน ให้เราเปิด

หยุด!! บอกแค่ว่า “มันพัง” แต่ต้องบอกให้ได้ว่า “พังท่าไหน” ด้วย API Response Code Read More »