ถ้าวันนี้บริษัทประกาศว่า“เราจะยุบทีม 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 ที่เกิดขึ้นได้จริงๆ . สมมติเราเจอคำถามว่า “เล่าบั๊กที่ซับซ้อนที่สุดที่เคยเจอให้ฟังหน่อย”