Mindset

ใครกำลังรู้สึกว่าตัวเองไม่รู้จะไปทางไหนต่อบ้างคะ เป็น Manual QA ที่ทำแค่งาน manual อย่างเดียวจะขยับไปทาง technical ก็รู้สึกว่ามันยากเกินไปจะทำแบบเดิมไปเรื่อยๆ ก็ไม่สบายใจเอาซะเลยบางทีก็แอบรู้สึกว่าตัวเองเป็นพลเมืองชั้นสองชั้นสามไปอีก . พี่กิ่งเข้าใจความรู้สึกนี้ดีเลยค่ะแต่อยากให้ทุกคนลองมองอีกมุมนึงนะคะเพราะเส้นทางที่เรากลัวกันอยู่เนี่ยหลายคนอาจจะเริ่มเดินมาไกลกว่าที่คิดแล้ว แต่ยังไม่รู้ตัวหรือบางคนที่ไม่เคยลอง ก็อาจจะยังไม่รู้ว่าก้าวแรกนั้นเริ่มได้ง่ายกว่าที่คิดมาก . หลายๆ ครั้งที่เรารู้สึกว่าตัวเองยังไม่เก่งพอ หรือ technical เป็นสิ่งที่ไกลตัวพี่กิ่งอยากให้ลองนึกดูว่าเคยมีบั๊กตัวไหนที่ reproduce ยากๆ แล้วเราไปหามาจนได้มั้ยคะ บางคนอาจจะ✅ อ่าน error message แล้วก็พอเดาได้ว่า เป็นเรื่องข้อมูลไม่ใช่ UI✅ เปิดดู network log เพื่อดูว่า api request มันยิงไปถึงมั้ย✅ ลองไล่ดู log ใน server ว่ามันเริ่มพังตั้งแต่จุดไหน✅ สงสัยว่าทำไม staging ผ่าน แต่ไปพังแค่บน prod เลยไปไล่ดู environment config✅ ไปคุ้ยใน database จนรู้ว่ามันพังตอนใช้ข้อมูลคนละแบบกัน . ทั้งหมดนี้คือก้าวแรกสำหรับคำว่า […]

เพิ่งไปพูดในงาน QA Meetup แล้วไปโชว์แก้วน้ำมาค่ะ ของที่ไม่ว่ามันจะสีอะไร มีหูหรือไม่มีหู หรือจะโดนเอาไปใส่ปากกา มันก็ยังเป็นแก้วน้ำแต่ถ้าเมื่อไหร่ที่มันใส่น้ำไม่ได้ ตอนนั้นมันจะไม่ใช่แก้วน้ำทันที เพราะ “การใส่น้ำได้” มันคือตัวตน คือแก่น ของการเป็นแก้วน้ำ . QA แบบเราก็เหมือนกันค่ะจะไม่เขียน test case เลยไม่ execute test เลยไม่เจอบั๊กเลย เราก็ยังเป็น QA อยู่เพราะเราอาจจะแค่ทำเป็น check list เร็วๆ เทสไปก่อนอาจจะเขียน automate มารันเทสให้อาจจะทำ shift-left ได้ดีมาก จน quality ดีเริ่ดมาตั้งแต่ต้น แต่เมื่อไหร่ที่เราไม่สงสัย ไม่ตั้งคำถามในงานที่เราทำเลยตอนนั้น เราอาจจะไม่ใช่ QA แล้วก็ได้นะคะเราอาจจะกลายเป็นแค่คนที่ทำงานของ QA เฉยๆ . 📍 I doubt, therefore I am เป็นคำที่มาจากนักปรัชญาที่ชื่อ René Descartesที่เค้าไปสงสัยทุกสิ่งทุกอย่าง จนสุดท้ายเหลือแค่

เคยมั้ยคะ 🐛เจอบั๊กที่มันชัดมากๆ ต้องแก้แน่นอน ไม่งั้นกระทบเยอะแน่ แล้วเราก็ไปเปิด bug ticket เขียนรายละเอียดสวยงามscreenshot ครบreproduce steps เป๊ะ ส่งไปให้ทีมPM ตอบกลับมาว่า “เอาไว้ sprint หน้านะ” . เจอแบบนี้ รู้สึกยังไงกันบ้างคะ? “นอยอ่าาา ทำไมไม่มีใครฟัง QA เลย”“แบบนี้แหละ เรามันพลเมืองชั้น 2 ชั้น 3 ของทีมอยู่แล้ว” แล้วเราก็ไปหาหลักฐานมาใส่เพิ่มแปะ log เพิ่มใส่ data เพิ่มEscalate เพิ่ม ให้มันดังกว่าเดิม . แต่ปัญหาจริงๆ ไม่ใช่ “หลักฐานไม่พอ” หรอกค่ะปัญหาคือ “เราไม่ได้พูดภาษาเดียวกับคนที่ตัดสินใจ”เราพูดภาษา technical แต่คนตัดสินใจพูดภาษา business . มีคอนเซปต์นึงที่อยากให้ทุกคนรู้จัก เรียกว่า “Name the Threat” หลักการง่ายๆ เลยค่ะ คนจะไม่สนใจ solution ของเรา

ถ้าวันนี้บริษัทประกาศว่า“เราจะยุบทีม QA เพราะจะใช้ AI ทำแทน” ความรู้สึกแรกที่เข้ามาในหัวทุกคนคืออะไรคะ . คำตอบคือ “แล้วแต่ว่าเราเป็น QA แบบไหน” วันนี้เลยอยากพาไปดูว่า AI จะแทนได้จริงตรงไหน และแทนไม่ได้ตรงไหนและที่สำคัญคือ จะทำยังไง ให้เราเป็นคนที่จะอยู่รอดได้ . ❌ งานที่ AI แทนได้ชัวร์ งานในกลุ่มนี้เราน่าจะเห็นกันชัดๆ อยู่แล้วค่ะ ว่ามันทำแทนเราได้ดีแค่ไหน 🤖 เขียน test case จาก requirement ที่ชัดเจน🤖 เขียน regression script จาก flow ที่มี🤖 สร้าง test data ที่จะเอาไปใช้เทส🤖 สรุป bug จาก log หรือ test result ที่มี งานพวกนี้มี input และ output ที่ชัดเจน

Report ที่เราใช้เวลาครึ่งวัน นั่งสรุปผลเทส ใส่ตาราง ใส่กราฟ อย่างดีแล้วก็ส่งออกไปให้ทีม ให้หัวหน้า ให้ผู้บริหาร หรือใครที่เกี่ยวข้องแล้วก็จบงานของเรา ถามหน่อยว่า มีใครเคยกลับมาดูมั้ยคะ ว่ามีคนอ่านจริงกี่คน แล้วมีกี่คนที่ได้ประโยชน์จาก report ตัวนั้น บางคนอาจจะคิดว่าเพราะคนอื่นไม่สนใจงาน QA ไง งานเรามันลูกเมียน้อยอยู่แล้วแต่ลองกลับมามองดู report ที่เราส่งไปมั้ยคะ ว่ามันเป็นข้อมูลอะไร มันเป็น “บันทึกว่าเราทำอะไรไปบ้าง”หรือเป็น “ข้อมูลที่ช่วยให้ใครซักคนเอาไปตัดสินใจต่อได้” . ❌ Sprint นี้ เขียน Test Case ไป 312 เคส เทสไปแล้ว 290 เคสเหลือ edge case บางข้อที่ยังทำไม่ได้เจอบั๊ก 45 ตัว ปิดไปแล้ว 43 ถามว่าอ่านจบแล้วยังไงต่อ…คำตอบคือ “ไม่รู้” ทั้งๆ ที่ตัวเลขในนั้นก็ถูกหมด ไม่มีอะไรผิดซักนิด . ✅ Sprint นี้เทสไปแล้ว 80%

เคยนั่งประชุมใน sprint planning แล้วรู้สึกว่าเราไม่ได้มีอะไรจะไป contribute ให้ทีมเลยมั้ยคะ Dev ก็ estimate งานกัน ให้ story point กันไปPO ก็เรียง priority เลือกของเข้า sprint ส่วน QA อย่างเราก็นั่งฟังไป จดไป ว่ามีงานอะไรรอให้เราเทสบ้าง บางทีเราอาจจะรู้สึกว่า “ก็มันไม่มีอะไรจะพูด แค่ตั้งใจฟังก็พอแล้ว” แต่จริงๆ มันเป็นแบบนั้นรึเปล่า . เราไม่มีอะไรจะพูดจริงๆ หรือ เราอาจจะแค่คิดว่าสิ่งที่เรารู้มันไม่ได้สำคัญพอ QA หลายคนอาจจะรู้สึกว่าตัวเองถูกกำหนดบทบาทหน้าที่มาให้อยู่แล้ว “รอ Dev โค้ดเสร็จก็เอามาเทส”“ออกแบบ Test Case ตาม Requirements ที่ได้รับมา”“เจอบั๊ก ก็เปิด ticket ให้แก้”“ถ้าเทสผ่าน ก็ approve ให้เอาขึ้นได้” แล้วเราก็จะรู้สึกว่า นี่คือทั้งหมดที่เราทำได้แล้ว . จริงๆ แล้วยังมีอีกหลายอย่างที่อยู่ในหัวของเรา ที่คนอื่นอาจจะไม่รู้นะคะ อย่างเช่น

Automation Coverage ก็เกือบ 100% มีเทสเป็นร้อยๆ ข้อตัวเลขสวยงาม ตรงตาม KPI ทุกอย่างแต่พอต้อง deploy ก็ยังไม่มั่นใจอยู่ดี ทั้งๆ ที่ test มันก็รันอยู่ทุกวัน หรือบางทีมีคนถามว่า test พวกนี้เอาไว้ทำอะไรก็ช็อค ตอบไม่ได้ซะงั้น ใครเป็นแบบนี้ยกมือค่ะ . มีใครเคยลองหยุดถามตัวเองดูมั้ยคะ ว่าเรากำลังทำ Automation Test ไปเพื่ออะไร 🔴 เราทำเพราะแค่ต้องส่งตัวเลขรึเปล่า ได้ Objective มาว่า Coverage ต้องเกิน 80%ต้องมี Automation Test ครบตาม spec ที่ได้มา แล้วเราเคยลองถามมั้ยว่า แล้ว test พวกนี้มันช่วยให้ทีมมั่นใจขึ้นรึเปล่า??? 🔴 เราแค่เอา manual test มาแปลงเป็น script รึเปล่า มี manual test case อยู่

ทำงาน 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 ทำให้ไม่เคยเห็นหรืออาจจะแปลว่า ไม่เคย จริงๆ ก็ได้ (นั่นแปลว่าคุณโชคดีมากๆ ค่ะ 😂) . แล้วในฐานะคนสัมภาษณ์ อยากได้คำตอบแบบไหน 📍 ถ้าไม่เคยจริงๆ ก็ตอบไปตามตรงได้เลยค่ะ อาจจะเล่าต่อซักหน่อยว่า มีกระบวนการยังไง ที่ทำให้มั่นใจได้ว่าจะเจอบั๊กก่อนขึ้นจริง หรือมีการ