Mindset

ทำงาน QA มา 3 ปี รู้สึกว่าทำไมงานมันก็วนไปวนมาอยู่ที่เดิมอยากย้ายไปที่อื่นก็ไม่กล้า จะขอเลื่อนตำแหน่งก็ไม่ได้ซักที ใครรู้สึกแบบนี้อยู่ ปัญหาอาจจะไม่ใช่แค่เรื่อง skill ก็ได้นะคะ . ช่วงที่ผ่านมาพี่กิ่งได้ไปฟังคลิปนึงของ Dan Koe มาค่ะ ชื่อว่า “How to become so valuable AI will never replace you” ทำยังไงถึงจะเป็นคนที่มีคุณค่ามากจน AI ก็มาแทนไม่ได้ เขาพูดถึง 6 ไอเดีย ที่ทำให้เราเป็นคนที่ AI มาแทนไม่ได้ 1️⃣ Agency: ลงมือทำโดยไม่ต้องรอให้ใครสั่ง2️⃣ Taste: รู้ว่าอะไรดี หรือไม่ดี ได้เอง โดยไม่ต้องถามใคร3️⃣ Flow state: ทำงานที่ท้าทาย ในจุดที่พอดี4️⃣ Persuasion: สื่อสารให้คนอื่นเข้าใจและเห็นคุณค่าสิ่งที่เราทำ5️⃣ Trial & Error: เรียนรู้จากความผิดพลาด ไม่ใช่กลัวมัน6️⃣ […]

จริงๆ ปัญหาอาจจะไม่ได้อยู่ที่คำตอบนะคะ . พี่กิ่งก็เป็นบ่อยเลยค่ะ สัมภาษณ์จบไปแล้ว ก็คิดว่าตอบไปตามความจริงแล้ว ไม่ได้โกหก ไม่ได้แต่งเรื่องขึ้นมา แต่ก็มางงตัวเองว่า พูดอะไรไป แล้วที่เล่าไปมันได้อะไรบ้างนะ ทั้งๆ ที่ก็ไม่ได้พูดอะไรผิดเลย . ปัญหามันอาจจะไม่ได้อยู่ที่เรื่องเล่านะคะแต่เราอาจจะเผลอเล่าโดยคิดว่า “คนฟังรู้เรื่องราวเบื้องลึกเบื้องหลังอยู่แล้ว” แต่ความจริงแล้ว คนที่มาสัมภาษณ์เรา เค้าเป็นคนแปลกหน้าไม่ได้รู้ว่าทีมเราทำงานยังไงไม่รู้ว่าบั๊กที่เล่าไปมันใหญ่แค่ไหนไม่รู้ว่าคำว่า “หาอยู่หลายวัน” ที่เราพูดไป มันหมายความว่ายังไง แล้วพอเราตอบออกไป มันก็จะฟังดูเลื่อนลอย จับประเด็นไม่ค่อยได้ตามไปด้วยค่ะ . วันนี้พี่กิ่งเลยอยากพาไปชวนดูเรื่อง STAR ที่ถูกออกแบบมาเพื่อแก้ปัญหานี้ ⭐ STAR คือ framework ที่บังคับให้เราเล่าเรื่องแบบให้คนนอกตามได้ 📍 เริ่มจากสถานการณ์ที่เจอ (Situation) -> หน้าที่ของเรา (Task) -> สิ่งที่เราทำจริงๆ (Action) -> ผลลัพธ์ที่เกิดขึ้น (Result) มันไม่ใช่สิ่งที่ทำให้เราพูดเกินจริงไม่ใช่เพื่อให้เราเตรียมสคริปต์สำหรับจำเข้าไปตอบ แต่เพื่อให้เราสามารถเล่าประสบการณ์ของเรา ในแบบที่คนนอกจะเข้าใจได้เป็นการร้อยเรียงเรื่องราว ให้คนฟังเห็นภาพตามและเข้าใจ impact ที่เกิดขึ้นได้จริงๆ . สมมติเราเจอคำถามว่า “เล่าบั๊กที่ซับซ้อนที่สุดที่เคยเจอให้ฟังหน่อย”

❓ “เคยปล่อยบั๊กหลุดขึ้น 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 ที่ดี ✅