ให้ AI เขียนเทสให้ รันผ่านหมดแต่ไม่เข้าใจเลยว่ามันทำอะไร . เมื่อเช้าพี่กิ่งมี Q&A session พิเศษ ให้คนในคลาส Automation ค่ะตั้งใจจะให้คนมาถามคำถาม พูดคุยกัน เผื่อใครไปทำการบ้านแล้วติดอะไรแต่สุดท้ายคุยกันเรื่อง AI เป็นส่วนใหญ่เลยค่ะ เรื่องที่คุยกันก็ประมาณนี้ “ลอง vibe code แล้วไม่รู้จะคุมยังไงให้ผลลัพธ์ตรงกับที่อยากได้”“ทำออกมาได้ แต่ไม่รู้ว่าสิ่งที่ถูกควรเป็นยังไง”“ใช้ AI ทำได้หมดทุกอย่าง เร็วมาก แต่ไม่เข้าใจที่มันทำเลย” พอ AI มันทำให้ได้เร็วขึ้นมากๆบางทีเราก็เผลอข้าม ไม่อ่าน ไม่ทำความเข้าใจสิ่งที่มันทำพอไม่เข้าใจ ก็เกิดปัญหาตามมาทีหลังค่ะ . สิ่งที่พี่กิ่งอยากให้ทุกคนลองมองไปด้วยกันไม่ว่าจะมี AI หรือไม่มี AIปัญหาของการทำ Software ก็ยังอยู่เหมือนเดิมค่ะ ไม่ว่าจะเป็น communication, processการคุย requirement ให้ชัดเจนการตกลง architecture ให้ชัดการทำ unit test และ shift-left เพื่อให้มี quality ที่ดี ถ้ายังมีปัญหาพวกนี้อยู่แล้วเอา AI

อยู่ตำแหน่งเดิมมา 6 ปี ไม่ขยับไปไหนเลยแต่พอย้ายงาน เงินเดือนกลับขึ้นแบบก้าวกระโดด . ช่วงแรกของการทำงาน พี่กิ่งเป็น QA engineer อยู่ 6 ปีเลยค่ะตำแหน่งเดิม ชื่อเดิม ไม่ได้ขึ้นเป็น senior กับเค้าซักที ตอนนั้นก็เริ่มกังวลว่าเราอยู่ที่เดิมนานเกินไปมั้ยทำไมไม่ได้โตเหมือนคนอื่นเค้าบ้าง . แต่พอย้อนกลับไปดูในช่วง 6 ปีนั้น ว่าทำอะไรไปบ้างเลยค้นพบว่ามันไม่เคยได้อยู่นิ่งเลยค่ะ ทำอะไรไปหลายอย่างมากย้ายไปทำหลายทีม หลาย product ได้จับทั้งเรื่อง functional test เขียน test case รันเทส ปกติทั่วไปรวมทั้ง non-functional test ที่ตอนนี้น่าจะไม่ได้หาทำง่ายๆอย่างพวก infrastructure, เทส hardware, server, networkต้องเรียนของใหม่อยู่เรื่อยๆ แล้วก็ได้ทำงานกับทีมหลายแบบมากๆ แต่ทั้งหมดที่พูดไป มันไม่ได้ไปโผล่อยู่ที่ชื่อตำแหน่ง . 💡 สกิลหลายๆ อย่างที่ใช้ทำงานอยู่ตอนนี้ ก็มาจากช่วงนั้นแหละค่ะ ที่ทุกวันนี้เซ็ต CI/CD ได้เอง ก็เพราะเคยใช้ unix

ใครเป็นแบบนี้บ้างคะ เปิดประกาศรับสมัครงาน QA แล้วมีเขียนว่าต้องได้ Automationอ่านจบ แล้วก็ปิดไป เปิด Tutorial ทิ้งไว้ อยากเริ่มทำ Automation แต่ก็ไม่ได้เริ่มซักทีสุดท้าย ก็ปิดหน้านั้นทิ้งไป ปีที่แล้วก็ทำแบบนี้ปีก่อนหน้าก็ทำแบบเดียวกัน ทั้งๆ ที่เราก็ไม่ได้อยู่เฉยๆ เลยนะคะ ทำงานหนักมาตลอดตั้งใจพัฒนาตัวเอง มีงานมาให้ทำเยอะขึ้นทุกวัน งานเทสก็ไม่เคยหลุด แต่พอมานั่งคิดดูก็รู้สึกว่า ทำไมยังทำตำแหน่งเดิม งานเดิม ใช้สกิลเดิม . มีหลายๆ คนที่ทักมาคุย มาปรึกษา ทั้งใน Line OA, Facebook หรือจะใน Workshop ต่างๆ(รวมทั้งคนที่เข้ามาอ่านโพสยาวๆ แบบนี้ด้วยค่ะ) เกือบทุกคนเป็นคนที่ตั้งใจอยากพัฒนาตัวเองมากๆ อยากพาตัวเองไปเจอโอกาสใหม่ๆ หลายคนทั้งอ่านบทความ ดู Tutorial ดู Youtube มาก็เยอะ บางคนซื้อคอร์สเก็บไว้แล้วด้วยซ้ำแต่ก็ยังมีคำถามที่เจอบ่อยๆ คือ “ไม่รู้จะเริ่มยังไง” “รู้สึกว่าตัวเองยังเก่งไม่พอ” พอได้คุยกับหลายๆคนแล้ว พี่กิ่งบอกได้เลยนะคะว่า ปัญหามันไม่ได้อยู่ที่ความตั้งใจเลยค่ะแต่มันมักจะเป็นเพราะว่าเราแก้ปัญหาไม่ถูกจุด และจุดที่ติดของแต่ละคนก็ไม่เหมือนกันด้วยค่ะ เท่าที่พี่กิ่งเจอ มันมักจะเป็น 3

ใครกำลังรู้สึกว่าตัวเองไม่รู้จะไปทางไหนต่อบ้างคะ เป็น 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 ของเรา