Mindset

เคยเป็นมั้ยคะ โดน 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

มีใครคิดว่าซอฟท์แวร์ที่ดีต้อง “Zero Defect” บ้างคะ ระบบที่ดีที่จะเอาขึ้นได้ต้องเพอร์เฟค 100% ถ้าเจอบั๊กแม้แต่นิดเดียว ก็ต้องรีบขวางไว้ทันที ผลคืออะไรรู้มั้ยคะ กลายเป็นเราทำงานเครียด รู้สึกต้องสู้ ต้องไฟท์ตลอดเวลา อยากให้ทุกอย่างออกมาสมบูรณ์แบบที่สุด แต่พอเราเติบโตขึ้น ก็ทำให้รู้ค่ะว่า เราไม่ควรหมกมุ่นกับความสมบูรณ์แบบที่จับต้องไม่ได้ แต่เราจะต้องทำงานแบบมีกลยุทธ์ คิดถึงRisk และ Cost ที่จะเกิดขึ้นเสมอ ลองมาดูสถานการณ์ตัวอย่างกันค่ะ ว่าแบบไหนเราปล่อยได้ แบบไหนปล่อยไม่ได้ แล้วเราจะจัดการกับมันยังไง 🚨 เมื่อ Business Deadline สำคัญกว่า Minor Bug ลองคิดดูว่าถ้าพรุ่งนี้บริษัทจะต้องปล่อยแคมเปญใหญ่ (เช่น 11.11) ที่ใช้งบการตลาดมหาศาล ฟีเจอร์ที่กำลังจะออกมีมูลค่าสูงมากต่อยอดขาย แต่ดันมาเจอบั๊กในนาทีสุดท้าย แล้วเราจะทำยังไงกับบั๊กพวกนั้นดี ถ้าแก้ก็อาจจะต้องมาเร่งเทสฟีเจอร์นั้นใหม่อีกรอบ แล้วอาจจะทำให้ปล่อยฟีเจอร์นี้ไม่ทัน ขั้นแรกเราต้องประเมินก่อนค่ะว่าบั๊กนี้ “ร้ายแรง” แค่ไหน โดยอาจจะคุยกับฝั่ง Business หรือ PO เพื่อตกลงร่วมกันด้วยก็ได้ ถ้าบั๊กที่เจอเป็น Minor Bug เช่น “ปุ่มแชร์ลง Social