❓ “เคยปล่อยบั๊กหลุดขึ้น production มั้ย”
เป็นคำถามที่พี่กิ่งใช้ถามเวลาสัมภาษณ์บ่อยมากเลยค่ะ
และก็จะสังเกตว่า หลายๆ คน จะตอบว่า “ไม่เคย” แล้วก็จบ
พี่กิ่งก็ไม่แน่ใจเหมือนกันว่าในใจของคนที่ตอบว่า “ไม่เคย” จะคิดอะไรอยู่นะคะ
อาจจะอยากแสดงความมั่นใจว่าเป็น QA ที่จับบั๊กได้ทุกตัว
เป็น QA ที่เขียน test case ได้ครอบคลุมจนไม่เคยมีบั๊กหลุด
แต่จริงๆ แล้ว “ไม่เคย” อาจจะไม่ใช่คำตอบที่ดีเสมอไป
มันอาจจะแปลว่า ไม่เคยไปตามดูเลยว่าหลังเทสเสร็จแล้ว เกิดอะไรขึ้นบ้าง
หรืออาจจะแปลว่า ไม่เคยเจอ เพราะทีม track production bug ที่ user ส่งเข้ามาไว้ใน project ของ customer support ทำให้ไม่เคยเห็น
หรืออาจจะแปลว่า ไม่เคย จริงๆ ก็ได้ (นั่นแปลว่าคุณโชคดีมากๆ ค่ะ 😂)
.
แล้วในฐานะคนสัมภาษณ์ อยากได้คำตอบแบบไหน
📍 ถ้าไม่เคยจริงๆ ก็ตอบไปตามตรงได้เลยค่ะ อาจจะเล่าต่อซักหน่อยว่า มีกระบวนการยังไง ที่ทำให้มั่นใจได้ว่าจะเจอบั๊กก่อนขึ้นจริง หรือมีการ monitor หลัง release ยังไงบ้าง
📍ถ้าเคย อย่าตอบแค่ “เคยค่ะ ตอนนั้นมีบั๊กเรื่อง payment หลุดไป แล้วก็เรื่องใหญ่เลย” แล้วก็จบแค่นั้น
ลองเล่าต่ออีกหน่อยว่าหลุดไปแล้ว ทำยังไงต่อ
👉 รู้จากช่องทางไหน มี process แบบไหนให้เรารู้ได้เร็วที่สุด
👉 มีวิธีการจัดการปัญหายังไง
👉 ได้หา root cause ต่อมั้ย ว่าพลาดไปตรงไหน test case ไม่ครบ หรือ environment ต่างกัน หรือ requirement ไม่ชัดตั้งแต่ต้น
👉 ที่สำคัญคือ ย้อนกลับมาแก้ไขมั้ย ได้คุยกันมั้ยว่าจะแก้ root cause ยังไง
ทั้งหมดนี้คือสิ่งที่อยากได้ยินค่ะ จริงๆ ก็ไม่ได้อยากรู้หรอกว่าเทสเก่งแค่ไหน แต่อยากรู้ว่าจัดการกับปัญหายังไงต่างหาก
ลองตอบว่า “เคยค่ะ ตอนนั้นมีบั๊กเรื่อง payment หลุดออกไป หลังจาก release แล้วลูกค้าจ่ายผ่านบางช่องทางไม่ได้ ก็รีบช่วยกันกับ dev หาปัญหา พอไปดู log ใน backend ก็เลยเจอว่ามีการส่งค่าบางอย่างไปที่ payment gateway ผิด พอเจอแล้วก็ทำ hotfix ขึ้นไปแก้ หลังจากแก้ปัญหาให้ลูกค้าได้แล้วก็กลับมาดู test case พบว่าขาดเทสเคสของการจ่ายด้วยบัตรเครดิตไป ก็เลยกลับเข้าไปเพิ่มใน test case และเขียน automate เพิ่มเข้าไปด้วยค่ะ”
เท่านี้ก็ครบ!
.
คำถามอื่นๆ ก็เหมือนกันค่ะ ลองใช้วิธีเดียวกัน
❓ “เล่า process การเทสให้ฟังหน่อย”
👉 บางคนอาจจะตอบแค่ว่า “เทสตาม ticket ใน sprint พอได้ assign มาก็เขียน test case แล้วก็ execution ถ้าไม่ผ่านก็เปิด bug ticket ถ้าผ่านก็ปิด ticket ค่ะ”
👉 แล้วถ้ามีคนที่สองที่ เล่าให้ฟังตั้งแต่ เข้าไปคุย requirement กับทีมตั้งแต่ grooming และเริ่มถามคำถามเกี่ยวกับการ test และพูดคุยส่วนที่ยังไม่เคลียร์กับทั้ง PO และ Dev แล้วเอามาเตรียมเขียน High Level Scenario รอไว้ เพื่อที่จะได้ให้ PO/Dev ช่วยรีวิวก่อนว่าจะเทสอะไรบ้าง ไปจนถึงว่าทำเทสยังไง แทร็คบั๊กที่เจอ กับ test progress ยังไง และสรุปผลยังไง
คิดว่าคนไหนน่าสนใจกว่ากันคะ?
คนแรก แค่เล่าว่าทำอะไรบ้าง อาจจะถูกต้องทุกอย่าง แต่คนฟังอาจจะจำอะไรไม่ได้เลย
คนที่สอง อาจจะไม่ได้ตอบได้ “ถูก” ที่สุด แต่มันมีเรื่องราวที่ฟังแล้วจำได้
ไม่ใช่ว่าต้องตอบยาวๆ นะคะ แต่คำตอบที่ดีคือคำตอบที่มาจากความเข้าใจว่าแต่ละอย่างที่ทำ ทำไปทำไม และต้องทำอะไร คุยกับใคร ณ จุดไหนบ้าง นี่คือคนที่เข้าใจ process งาน และรู้วิธีการรับมือหน้างานจริงๆ
.
ลองดูอีกซักตัวอย่าง
❓ “บั๊กที่ยากที่สุดที่เคยเจอคืออะไร”
❌ QA ทั่วไป: “เคยเจอบั๊กเรื่อง payment ไม่ผ่านค่ะ แก้อยู่นานเลย” แล้วก็จบแค่นั้น
✅ QA ร่างทอง: “เคยเจอบั๊กเรื่อง payment ค่ะ ตอนแรกดูเหมือนง่ายๆ แต่พอลงไปดูปัญหาที่เกิด ก็เจอว่ามันเกิดแค่ edge case บางแบบเท่านั้น เลยต้องไปไล่ดูกับ Dev ค่อยๆ หาวิธี reproduce ไปทีละสเต็ป จนเจอว่าเป็นเรื่อง race condition ก็เลยต้องเขียน script jmeter ช่วย dev reproduce ด้วยค่ะ สุดท้ายก็หาวิธีแก้กันจนเจอ”
จุดต่างไม่ใช่ว่าบั๊กใครยากกว่ากัน แต่คนแรกเล่าแค่ “ผลลัพธ์” ส่วนคนที่สองเล่า “กระบวนการ” การรับมือกับปัญหาที่เจอด้วย ซึ่งแบบนี้จะแสดงให้เห็นเลยว่าเราเข้าใจปัญหา และสามารถรับมือสถานการณ์ที่ซับซ้อนได้
.
😰 แล้วถ้าเจอคำถามที่ตอบไม่ได้จะทำยังไง
❌ ห้ามเด็ดขาด: กลัวจะเว้นช่วงเงียบ พยายามยำคำตอบ เอานู่นนี่มาพูด ทั้งๆ ที่ไม่เคยทำจริง
✅ QA ร่างทอง: ตอบตรงๆ ได้เลย “อันนี้ไม่เคยทำค่ะ” “เคยอ่านมาแต่ยังไม่เคยลองทำจริง” หรือถ้ายังนึกไม่ออก จะขอเวลาคิด ก็ได้นะคะ การเงียบในตอนสัมภาษณ์ไม่ใช่เรื่องแปลกเลยค่ะ ปกติมากๆ ถ้าจะต้องหยุดคิด
สิ่งที่คนสัมภาษณ์อยากเช็ค บางครั้งก็ไม่ใช่แค่ “รู้หรือไม่รู้” แต่เป็นการรับมือกับปัญหา การจัดการสิ่งต่างๆ หรือถ้าต้องทำสิ่งที่ไม่เคยทำ จะทำยังไง เพราะในงานจริง เราก็ไม่ได้รู้ทุกอย่างตั้งแต่แรกอยู่แล้วค่ะ ยังไงก็ต้องเรียนรู้อะไรใหม่ๆ กันทุกวันอยู่แล้ว
.
สิ่งที่สำคัญที่สุดคือ “รู้จักตัวเองดีพอ”
หลายๆ คนกลัวการสัมภาษณ์ เพราะคิดว่าต้องท่องคำตอบที่เป๊ะเตรียมเอาไว้
แต่ความจริงแล้วสิ่งที่ควรทำคือ ทบทวนเรื่องราวของตัวเอง ว่าทำอะไรมาบ้าง เจอปัญหาอะไรมาบ้าง แก้ยังไง เรียนรู้อะไรจากมัน
หรือสิ่งที่เราทำได้ดีคืออะไร และสิ่งนั้นจะช่วยทีมได้ยังไง แล้วลองเอาเรื่องนี้มาเล่าตั้งแต่ตอนแนะนำตัวเลย แทนที่จะไล่ยาวว่าเคยทำงานที่ไหนมากี่ปีอย่างเดียว เท่านี้ก็ช่วยได้เยอะแล้วค่ะ
พอเรารู้จักเรื่องราวของตัวเองดีพอ ตอนตอบสัมภาษณ์ก็ไม่ต้องกลัวว่าจะตอบไม่ได้ เราแค่นำเสนอตัวเราให้ดีที่สุดเท่านั้นเอง เพราะการที่เราจะได้งานหรือไม่ได้งาน ก็มีปัจจัยอื่นอีกเยอะที่เราก็ควบคุมไม่ได้ค่ะ
.
จริงๆ มี framework นึงที่พี่กิ่งใช้ประจำ เวลาต้องเตรียมคำตอบไว้ เพื่อให้คำตอบของเราครบถ้วนและมี structure ที่ดี แต่ถ้าเล่าในนี้เดี๋ยวจะยาวเกินไปหน่อย เอาไว้จะมาเล่าให้ฟังในโพสต่อไปนะคะ