Mindset

❓ “เคยปล่อยบั๊กหลุดขึ้น production มั้ย” เป็นคำถามที่พี่กิ่งใช้ถามเวลาสัมภาษณ์บ่อยมากเลยค่ะและก็จะสังเกตว่า หลายๆ คน จะตอบว่า “ไม่เคย” แล้วก็จบ พี่กิ่งก็ไม่แน่ใจเหมือนกันว่าในใจของคนที่ตอบว่า “ไม่เคย” จะคิดอะไรอยู่นะคะอาจจะอยากแสดงความมั่นใจว่าเป็น QA ที่จับบั๊กได้ทุกตัวเป็น QA ที่เขียน test case ได้ครอบคลุมจนไม่เคยมีบั๊กหลุด แต่จริงๆ แล้ว “ไม่เคย” อาจจะไม่ใช่คำตอบที่ดีเสมอไปมันอาจจะแปลว่า ไม่เคยไปตามดูเลยว่าหลังเทสเสร็จแล้ว เกิดอะไรขึ้นบ้างหรืออาจจะแปลว่า ไม่เคยเจอ เพราะทีม track production bug ที่ user ส่งเข้ามาไว้ใน project ของ customer support ทำให้ไม่เคยเห็นหรืออาจจะแปลว่า ไม่เคย จริงๆ ก็ได้ (นั่นแปลว่าคุณโชคดีมากๆ ค่ะ 😂) . แล้วในฐานะคนสัมภาษณ์ อยากได้คำตอบแบบไหน 📍 ถ้าไม่เคยจริงๆ ก็ตอบไปตามตรงได้เลยค่ะ อาจจะเล่าต่อซักหน่อยว่า มีกระบวนการยังไง ที่ทำให้มั่นใจได้ว่าจะเจอบั๊กก่อนขึ้นจริง หรือมีการ

เคยเป็นมั้ยคะ โดน assign งานที่ไม่เคยทำมาก่อน พอเห็นก็คิดในใจเลยว่า อันนี้มันเกินไป ทำไม่ได้แน่ๆ ยังไม่ทันได้เริ่มทำเลย แต่ในหัวก็ตัดสินไปแล้วว่าสู้ไม่ได้ ความรู้สึกนี้มันปกติมากเลยนะคะ ไม่ได้แปลว่าเราไม่เก่งด้วยค่ะความกลัวแบบนี้ มันเป็นของแถมที่มักจะพ่วงมากับงานของเราเสมอ แต่ไม่ค่อยมีใครพูดถึงกันแต่จริงๆ ทุกคนก็เคยผ่านมันมาทั้งนั้นค่ะ . มีครั้งนึง พี่กิ่งต้องรายงาน test result ใน conference call เป็นภาษาอังกฤษตอนนั้นภาษาก็ยังไม่ดีเท่าไหร่ ไม่เคยพูดภาษาอังกฤษในที่ประชุมเลยด้วยซ้ำแต่ก็คิดว่าลองดูซักตั้ง ก็ไปเตรียมตัว เขียนโน้ตไว้ ซ้อมพูดกับคนอื่น สรุปว่าในมีตติ้ง ทุกคนคุยเรื่องอื่นกันจนหมดเวลา ไม่ได้มีจังหวะให้พูดเลยซักคำจบมีตติ้งนั้น ทั้งขำทั้งโล่ง แต่ก็ทำให้ได้รู้ว่า เราก็เตรียมได้นี่นา ถ้ามีครั้งหน้าอีกก็คงไม่กลัวเท่าเดิมแล้ว 💡 ความกลัว มันไม่ได้บอกว่าเราไม่เก่งพอแต่มันแค่บอกว่าเรื่องนี้สำคัญสำหรับเรา . และเรื่องแบบนี้ ก็เป็นสิ่งที่เกิดซ้ำๆ กับงานของเรามากมายจนนับไม่ถ้วน 🔸 เวลาต้องค้านใครซักคนในที่ประชุมไม่ว่าจะเป็น requirement ที่ไม่ได้คิดเรื่องเทสให้ดี หรือคุยเรื่องบั๊กที่เห็นไม่ตรงกัน “ถ้าพูดไปแล้วทีมจะมองเรายังไง”“ถ้าความเห็นเราผิด แล้วจะดูไม่ professional รึเปล่า” 🔸 มีเรื่องที่สงสัยอยากจะถามฟังคนอื่นคุยกันในที่ประชุมแล้วไม่เข้าใจเลย แต่ทำไมไม่มีใครถามอะไรเลยนะ “ถ้าเราถามไปแล้วจะดูโง่มั้ย”“หรือเป็นเราเองที่ตามไม่ทัน” 🔸

เคยรู้สึกมั้ยคะว่าตัวเองเป็นคนสุดท้ายที่ต้องรับจบตลอด เวลาเกิดอะไรขึ้น 🐛 เจอบั๊กก่อนขึ้น production… ทำไมก่อนหน้านี้เทสไม่เจอ🐛 ลูกค้าเจอบั๊ก… QA เทสรึเปล่า ทำไมหลุด🐛 Requirement เปลี่ยนกลางคัน… ต้องเริ่มเทสใหม่หมด แต่ deadline ยังเป็นวันเดิม ทั้งๆ ที่บางทีปัญหามันก็เกิดมาตั้งนานแล้ว ก่อนจะมาถึงมือเราด้วยซ้ำแต่ทำไมถึงจะต้องมาพังเอาตอนท้ายๆ แล้วงานก็ดีเลย์ทุกที . พี่กิ่งเดาว่าหลายๆ คนที่อ่านอยู่ตอนนี้ ก็น่าจะเคยรู้สึกแบบนี้ใช่มั้ยคะQA แบบเรามักจะโดนถามเสมอ “เทสรึยัง ทำไมไม่เจอ” แล้วเราก็ “รับจบตลอด” ทั้งๆ ที่ปัญหามันเกิดขึ้นมาตั้งแต่ตอน design แล้วแล้วทำไมเราไม่ไปหามันให้เจอตั้งแต่ต้นทางไปเลยล่ะ! . ลองมาดูเคสตัวอย่างกันดีกว่าค่ะ สมมติว่าเรากำลังสร้างแอปช็อปปิ้งตัวนึงอยู่ แล้วก็ต้องเก็บข้อมูลวันที่ของออเดอร์นั้น แต่ไม่มีใครคุยกันว่าเราจะเก็บวันที่ใน timezone ไหน ทุกคนเข้าใจเอาเองว่าก็ต้องรู้อยู่แล้วว่าต้องเป็น timezone ที่เป็น local time สิ ไม่ใช่ UTC (ที่เป็นเวลาสากลคือ GMT+0) ก็เลยไม่มี requiremnt ตรงไหนพูดถึงเรื่องนี้ เพราะทุกคนคิดว่า “ก็น่าจะเข้าใจอยู่แล้ว”

เคยเจอมั้ยคะ ได้ Ticket มาแล้ว Requirement เขียนเอาไว้ว่า“ระบบต้องทำงานได้ถูกต้อง”“ระบบต้องคำนวณส่วนลดได้ถูกต้อง” ถูกต้อง ถูกต้อง ถูกต้อง BA อาจจะเข้าใจแบบนึงQA อ่านแล้วตีความไปอีกแบบนึงDev ก็ตีความไปคนละแบบ พอได้ของออกมา ทุกคน “งง” ทำไมไม่มีใครเข้าใจตรงกันเลยทั้งๆ ที่ทุกคนทำตาม Requirement ทั้งหมด เนี่ยแหละค่ะ บางทีสิ่งที่เราคิดว่าทุกคนน่าจะเข้าใจอยู่แล้วมันตีความได้ต่างกันหลายแบบ และแต่ละคนก็อาจจะเข้าใจไม่ตรงกัน Requirement ที่ไม่มี Example มันตีความได้หลายแบบ . 📌 มาลองดูตัวอย่างว่าทำไมตัวอย่างจริงถึงสำคัญ Requirement บอกว่า “ระบบต้องคำนวณส่วนลดและ VAT ให้ถูกต้อง” Dev อาจจะเข้าใจว่า คำนวณ VAT จากยอดสั่งซื้อก่อน แล้วค่อยหักคูปองส่วนลด(1000 + 0.07*1000) – 50 = 1020 บาท แต่สิ่งที่ business ต้องการคือ ให้หักส่วนลดก่อน ค่อยบวก VAT(1000 –

เคยเป็นกันมั้ยคะตัดสินใจลงทุนทำ Automation Testing กันจริงจังใช้เวลาหลายสัปดาห์ เขียน Script แปลง Test Case ที่มีอยู่เป็น Automationแล้วก็เอาไปให้ทุกคนใช้ ทีมก็ภูมิใจกับของที่ทำไป ทุกคนตื่นเต้นที่จะได้ใช้อะไรใหม่ๆ 6 เดือนผ่านไป… 🤖💥 Script เริ่มพังไปทีละตัวเราก็เข้าไปแก้ตรงจุดที่พัง แล้วก็ใช้ต่อผ่านไปซักพัก เอ๊า ทำไมพังอีกแล้ว ก็แก้อีกผ่านไปอีกซักพัก มีฟีเจอร์ใหม่ออกมา เอ๊า Test ที่มีอยู่พังหมดเลย สุดท้ายก็ไม่มีใครสนใจผลเทสของเราอีกไม่มีใครไปกดรัน เพราะรู้ว่าเดี๋ยวมันก็แดงงานก็เร่ง ต้องออกตาม timeline ที่เลื่อนแล้วเลื่อนอีกสุดท้ายทุกคนก็กลับไปรัน Manual เหมือนเดิม เพราะไม่มีเวลามาดู แค่ทำงานใน Sprint ก็หัวหมุนแล้ว คิดว่าปัญหาเกิดจากอะไรคะมีใครไม่เก่งรึเปล่า?หรือเราเลือก Tool ผิด?หรือเรายังตั้งใจทำงานกันไม่พอ? ไม่ใช่ซักอย่างเลยนะคะ แต่จริงๆ แล้วมันเกิดจากสิ่งเหล่านี้ค่ะ 🧑‍🎨 1. ไม่ Design ตั้งแต่แรก แล้วก็เขียนเหมือน Manual Test รันต่อกันยาวๆ เคยเห็น Automation Test

หลายๆทีมคงเป็นแบบนี้กันอยู่ใช่มั้ยคะ ไม่ว่าจะ Dashboard ที่โชว์ ranking ตามจำนวนบั๊กที่หาได้ หรือ KPI ที่วัดจากจำนวน Ticket ที่เปิด 😅กลายเป็นเราวัดผลงานของ QA กันด้วยจำนวนบั๊กที่หาเจอ แต่ลองมาคิดดูอีกทีนะคะ ถ้าทีมส่งมอบ product ออกไปโดยที่ไม่มีบั๊กเลยQA ในทีมนั้นหาบั๊กได้ 0 ตัว แปลว่าเขาทำงานได้ดีที่สุด หรือ แย่ที่สุด บั๊กน้อย อาจไม่ได้แปลว่า QA ทำงานน้อยนะคะแต่อาจจะแปลว่า QA เข้าไปช่วยทำให้งานมีคุณภาพมากขึ้น และป้องกันได้ดีตั้งแต่ต้น ลองเปรียบเทียบสองทีมนี้ดูนะคะ ทีม A 👉 QA รอของมา -> เข้าไปเทส -> เจอบั๊ก 20 ตัว👉 แล้วก็ส่งกลับไปให้ Dev แก้ 👉 แก้เสร็จเรียบร้อย -> ส่งกลับมาให้เทส -> QA เจอบั๊กอีก 5 ตัว ->

ไหน ใครเป็นมือใหม่บ้างคะ บางทีตอนที่เราเป็น QA แรกๆ เนี่ย เราไม่รู้หรอกว่าสิ่งที่เราทำไปมันดีหรือไม่ดียังไงวันนี้เลยอยากจะมาแชร์ 5 ข้อ ที่มักจะเห็นคนพลาดกันบ่อยๆ (และตัวพี่กิ่งเองก็เคยผ่านมาทุกข้อเลย 😅) ลองมาดูกันนะคะ ว่ามีตรงไหนที่เราสามารถทำให้ดีขึ้นได้บ้าง ❌ เทสทุกอย่างให้ครบก่อน✅ เทสให้ตรงจุดก่อน เทสครบก็ควรจะเป็นเรื่องดีไม่ใช่เหรอ แต่จริงๆ การที่เราจัดลำดับไม่ถูก แล้วพุ่งไปเทสเคสยิบย่อยก่อน เพราะอยากเทสให้ครบทุกอย่าง ก็อาจจะทำให้เราเจอบั๊กที่สำคัญจริงๆ ช้ากว่าที่ควรจะเป็นนะคะ ลองถามตัวเองว่า “ตรงไหนที่สำคัญสำหรับ User” แล้วเริ่มจากตรงนั้นก่อนถ้ามีบั๊ก เราจะได้แก้จุดที่สำคัญก่อนค่ะ ❌ รอ dev ส่งงานแล้วค่อยเทส ✅ คุย requirement ก่อน dev เริ่มโค้ด บั๊กที่เจอหลังจากเขียนโค้ดเสร็จแล้ว กับบั๊กที่เจอตั้งแต่ก่อนเริ่มโค้ด ราคาต่างกันมหาศาลค่ะแค่นัดคุย scenario กับ dev ก่อนจะเริ่มงานนั้นๆ ก็ช่วยให้ประหยัดเวลาได้เยอะ และคุณภาพของงานก็ดีขึ้นตามไปด้วย ❌ เขียน test case เยอะ = QA ที่ดี ✅

เชื่อว่าหลายๆทีมคงจะเคยเจอโมเมนต์ที่กด deploy ขึ้น productionแล้วทุกคนนั่งจ้องหน้าจอ ไม่กล้าลุกไปไหน เอาแต่จ้อง slack รอดูว่าจะมีอะไรระเบิดมั้ย บางทีเราก็อาจจะต้องรอ deploy ดึกๆ เพราะกลัวจะไปพังตอนลูกค้าใช้อยู่บางทีก็ต้องมีคนอยู่เวรเฝ้าหลังจากนั้นอีก อยู่ยาวกันจนตีสามตีสี่หรือบางที เราก็กังวลเวลาที่แก้บั๊กช่วงใกล้ๆ release จนต้องเร่ง retest ทุกอย่างซ้ำจนดึกดื่น เพราะไม่มั่นใจว่าที่แก้ไปจะไปทำอะไรพังบ้าง ถ้าทีมของคุณเป็นแบบนี้อยู่ อยากบอกว่า มันไม่ใช่เรื่องที่ต้องทนนะคะ และมันแก้ได้ ‼️ 🙏 ทำไม deploy ทีไรต้องสวดมนต์ตลอด ส่วนใหญ่ไม่ได้เกิดจากทีมเราเขียนโค้ดไม่ดีค่ะ และ ไม่ได้เกิดจากเทสไม่ละเอียดพอด้วยแต่มันมักจะเกิดจากการที่ทีมไม่รู้ว่า “สิ่งที่แก้ไปจะกระทบอะไรบ้าง”และไม่มั่นใจว่า “ที่เทสไปนั้นครอบคลุมพอหรือยัง” ลองดูเหตุการณ์นี้นะคะ แต่พอ deploy เท่านั้นแหละ 💥 โค้ดที่แก้ดันไปกระทบส่วนที่ตรวจสอบ promo code ได้ยังไงก็ไม่รู้ กลายเป็นลูกค้าใช้ส่วนลดไม่ได้ และเราก็ไม่รู้เรื่องนี้จนลูกค้าไปเจอนั่นแหละ เพราะไม่มีใครคิดถึง scenario นี้ตั้งแต่แรก นี่คือตัวอย่างคลาสสิคของการที่ทีม “เทสผ่าน” แต่ก็ไม่ทำให้มั่นใจอยู่ดีค่ะ เพราะเทสที่ทำไปไม่ได้ครอบคลุม scenario ที่อาจจะกระทบทั้งหมด 🤔 แล้ว QA จะมาช่วยตรงนี้ได้ยังไง??? เรามาลองดูว่า

“It’s not a bug, It’s a feature”“ไม่ใช่บั๊กนะ มันเป็นฟีเจ้อ” คลาสสิค!! เป็นประโยคที่ QA ทุกคนเคยได้ยินกันมาแน่ๆ ใช่มั้ยคะ 😅 บางทีเราแน่ใจสุดๆ ว่ามันพังแน่ๆ กด reproduce ซ้ำได้ทุกรอบแต่พอ report ไปปุ๊บ โดนสวนกลับทันที “อันนี้ตั้งใจทำแบบนี้แหละ” แล้วเราจะทำยังไงต่อดีล่ะ!?. ก่อนอื่นเลย อยากให้ทุกคนเข้าใจก่อนนะคะ ว่าเราไม่ได้จะมาหาว่าใครผิดใครถูก ไม่ได้จะบอกว่าใครดีกว่าใครเพราะ “Bug” หรือ “Not a Bug” มันมี grey area อยู่เยอะมาก ลองนึกตามดูค่ะ ใครเคยเจอสถานการณ์เหล่านี้บ้าง ❌ Requirement ไม่ได้เขียนไว้ชัดเจนระบบทำงานตรงตาม spec แต่ user งงมาก แบบนี้เป็นบั๊กมั้ย? ❌ Dev กับ QA ตีความ Requirement ต่างกันบางทีอาจจะมี edge