ใครกำลังรู้สึกว่าตัวเองไม่รู้จะไปทางไหนต่อบ้างคะ เป็น 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 ให้เอาขึ้นได้” แล้วเราก็จะรู้สึกว่า นี่คือทั้งหมดที่เราทำได้แล้ว . จริงๆ แล้วยังมีอีกหลายอย่างที่อยู่ในหัวของเรา ที่คนอื่นอาจจะไม่รู้นะคะ อย่างเช่น