เคยเจอบั๊กแปลกๆ ที่ไม่รู้จะ reproduce ยังไงมั้ยคะ
ทำกี่รอบก็ไม่เจอเหมือนที่ลูกค้าเจอ หรือบางทีก็เป็นบ้างไม่เป็นบ้าง
ไม่รู้ว่าเกิดอะไรขึ้นกันแน่
.
เท่าที่พี่กิ่งสังเกตเนี่ย คนที่ไปต่อได้ในสถานการณ์แบบนี้
มักจะไม่ใช่คนที่เขียน test case เก่งที่สุด หรือ เก่ง SQL มากที่สุดหรอกค่ะ
.
แต่มักจะเป็นคนที่
✅ ไปคุยกับ customer support รู้เรื่องว่า user ทำอะไรมาบ้าง แล้วเอามาใช้สืบต่อได้
✅ เปิด log เปิด DB ดู ว่าสิ่งที่เกิดขึ้นมันมีอะไรบ้าง มีตรงไหนที่ดูน่าสงสัย
✅ เข้าใจ behavior ของ business จริงๆ เลยพอเดาออกว่า user จะทำอะไรบ้าง
✅ อธิบายให้ dev ฟังด้วยภาษาที่ dev เข้าใจ หรือเข้าไปช่วย investigate กับ dev เลย
✅ พอเจอ root cause ก็อธิบายให้ business ฟังด้วยภาษาที่เค้าเข้าใจ
.
แต่ละข้อด้านบน ไม่มีข้อไหนที่เราต้องเก่งระดับเทพเซียนเลยค่ะ
แค่ “พอเข้าใจ” ก็พอ
เข้าใจ business ว่าภาพรวมเป็นยังไง
คุยภาษา technical รู้เรื่อง แบบไม่ต้องเขียนโค้ดเก่งก็ได้
Query database เป็น แต่ไม่ถึงขั้นต้องเทพ sql
รู้ว่าข้อมูลมันเชื่อมโยงกันยังไง แม้ว่าจะไม่เข้าใจ table บางตัว
พอรวมกันหลายด้าน มันทำให้เกิดสกิลเฉพาะตัว ที่ใครก็เลียนแบบไม่ได้
.
มีประโยคนึงที่พี่กิ่งเพิ่งไปเจอมาค่ะ
“if you want to be the best, you don’t have to be the best at everything”
ถ้าอยากเป็นคนที่เก่งที่สุด ไม่จำเป็นต้องเก่งที่สุดทุกเรื่องนะคะ
โดยเฉพาะในตอนนี้เรามี AI มาช่วยเติมความลึกในแต่ละด้านให้เราได้มากขึ้นเรื่อยๆ
ยิ่งเรามีความรู้หลากหลายมากเท่าไหร่ ก็จะใช้ประโยชน์จาก AI ได้เยอะขึ้นตามไปด้วยค่ะ
พี่กิ่งมองว่า การเป็น specialist ด้านเดียวแบบสุดโต่ง ไม่ได้สำคัญมากเท่าสมัยก่อนแล้ว
แต่คนที่เป็น generalist ที่เป็นเป็ดที่พอเข้าใจทุกด้าน นี่แหละค่ะที่จะเป็นคนที่น่าสนใจ
คนที่รู้ว่าจุดไหนต้องไปเชื่อมกับจุดไหน เข้าใจภาพรวม และรู้ว่าต้องทำยังไงถึงจะไปต่อได้
.
ลองกลับไปย้อนดูงานที่เราทำอยู่ดูนะคะ
ว่ามีตรงไหนที่พอจะทำให้เราขยายวงออกไปได้
แล้วค่อยดูว่ามันเอามาเชื่อมโยงกันยังไงได้บ้างค่ะ
📌 ถ้าใครอยากได้แนวทางการใช้ AI สำหรับงาน QA
พร้อม prompt ที่เอาไปปรับใช้ได้จริง ทั้งกระบวนการการทำงาน QA ตั้งแต่ requirement analysis ยันทำ test report
ลองเข้าไปดู eBook AI สำหรับ QA ร่างทอง ได้ที่นี่เลยค่ะ มีให้ลองอ่านฟรี 3 บทแรก
👉 https://withnatsiree.com/ai-for-qa-ebook