QA/SDET Interview Prep — คำถามที่พบบ่อย
1. อธิบายความแตกต่างระหว่าง Severity กับ Priority พร้อมตัวอย่าง
Severity คือความรุนแรงทางเทคนิค ของบั๊ก (กระทบระบบมากแค่ไหน) กำหนดโดย QA/Dev ส่วน Priority คือความเร่งด่วนทางธุรกิจ ที่ต้องแก้ กำหนดโดยทีม/PO โดยอิง severity ร่วมกับผลกระทบ ธุรกิจ (ดู Severity vs Priority)
จำว่า "Severity = พังแค่ไหน, Priority = ต้องรีบแค่ไหน" — Beyond: ตัวอย่างที่แสดงความเข้าใจ ลึกคือบั๊ก severity สูงแต่ priority ต่ำ (เช่น data corruption ที่ trigger condition ไม่มีทางเกิด จริงในระบบปัจจุบัน) และบั๊ก severity ต่ำแต่ priority สูง (เช่น ตัวอักษรผิดบนหน้าที่ CEO จะ demo พรุ่งนี้) การยกตัวอย่างทั้งสองทิศทางแสดงว่าเข้าใจว่าสองแกนนี้ independent กัน ไม่ใช่แกนเดียว
2. ถ้าเจอบั๊กใกล้ deadline release มาก จะตัดสินใจยังไงว่าควร block release หรือไม่
คำตอบที่ดีไม่ใช่ "แก้ให้เสร็จก่อนเสมอ" หรือ "ปล่อยไปก่อนเสมอ" แต่คือกระบวนการประเมินความเสี่ยง (ดู Risk-Based Testing): ประเมิน impact ต่อ user/ธุรกิจ, มี workaround ชั่วคราวไหม (เช่น feature flag ปิดเฉพาะส่วนที่พัง), และต้นทุนของการ delay release เทียบกับ ต้นทุนของการปล่อยบั๊กไป
จำกรอบคำตอบ "Impact → Workaround → Trade-off" — Beyond: คำตอบระดับ senior ควรพูดถึง "blast radius" ด้วย คือถ้าบั๊กกระทบ user ทุกคนทันที (เช่น login ทั้งระบบพัง) ควร block release แทบไม่มีข้อยกเว้น แต่ถ้ากระทบ edge case เล็กๆ ที่มี feature flag ปิดได้ การปล่อย release พร้อมปิด flag ชั่วคราวแล้วแก้ทีหลังมักเป็นตัวเลือกที่สมดุลกว่าการ delay release ทั้งหมดเพื่อรอ แก้จุดเล็กๆ จุดเดียว — แสดงว่าเข้าใจว่าการตัดสินใจนี้ไม่ใช่ binary (block/ไม่ block) แต่มีตัวเลือก กลางๆ อย่าง partial rollout หรือ flag-off ด้วย
3. Automate ทุกอย่างได้ไหม ทำไมบางทีมยังต้องมี manual testing
Automate ได้ดีกับสิ่งที่ คาดเดาผลลัพธ์ล่วงหน้าได้แน่นอนและทำซ้ำบ่อย (regression, API contract) แต่ automate ไม่ดีกับสิ่งที่ต้องใช้ สัญชาตญาณ/การตัดสินใจเชิงอัตวิสัย เช่น usability ("UI นี้ใช้งานง่ายจริงไหม"), exploratory testing (หาบั๊กที่ไม่มีใครคาดคิด), หรือ feature ที่ยังเปลี่ยนบ่อยจนต้นทุนเขียน/maintain automation สูงกว่าประโยชน์ที่ได้
จำว่า "Automation ตอบ 'เหมือนเดิมไหม' เก่งมาก แต่ตอบ 'ดีจริงไหม' ไม่ได้เลย" — Beyond: คำตอบที่ลึกกว่านี้ควรพูดถึง ROI ของการ automate: ถ้า test case รันแค่ครั้งเดียว (เช่น exploratory session ของ feature ที่ยังไม่ stable) ต้นทุนเขียน automation (เขียน + maintain ทุกครั้งที่ UI เปลี่ยน) อาจแพงกว่าประโยชน์ที่ได้เทียบกับการทำ manual testing ไปเลย สูตรคร่าวๆ ที่ใช้ตัดสินใจคือ เทียบ (ต้นทุนเขียน + ต้นทุน maintain × จำนวนครั้งที่คาดว่าจะรันซ้ำ) กับ (ต้นทุน manual testing × จำนวนครั้งที่ต้องทำซ้ำเท่ากัน) — feature ที่ stable และต้องเทสต์ซ้ำบ่อย (regression) คุ้มกับ automation มาก ส่วน feature ที่ทำครั้งเดียวจบหรือยังเปลี่ยนทิศทางบ่อยมักไม่คุ้ม
4. ถ้า API test ผ่านหมดแต่ user รายงานว่าฟีเจอร์พังจริงบน production จะวิเคราะห์ยังไง
เริ่มจากตั้งคำถามว่าช่องว่างอยู่ที่ไหนในบรรดาสิ่งที่ API test ไม่ได้ครอบ: (1) frontend map/render response ผิด (API ถูกแต่ UI แสดงผิด), (2) environment ต่างกัน (staging data/config ต่างจาก production จริงจนไม่ trigger บั๊ก), (3) edge case ที่ test data ไม่ครอบ (เช่น user จริง มี data shape ที่ test ไม่เคยลอง), หรือ (4) timing/concurrency issue ที่เทสต์แบบ isolated ไม่ เจอ (ดู API Testing → Beyond)
จำว่า "API test พิสูจน์ backend logic ไม่พิสูจน์ว่า UI ใช้ผลลัพธ์นั้นถูก" — Beyond: คำตอบที่ เป็นระบบที่สุดคือเสนอ "escape rate analysis" (ดู Best Practices): จัดกลุ่มบั๊กที่หลุดแบบนี้ตาม root cause category แล้วดูว่าเกิดจากช่องว่างประเภทไหนซ้ำๆ ถ้าเป็น "frontend map ผิด" ซ้ำหลายครั้ง แปลว่าทีมต้องเพิ่ม contract/schema validation ระหว่าง frontend- backend (ดู Contract Testing) ถ้าเป็น "staging ไม่เหมือน production" ซ้ำๆ แปลว่าต้องลงทุนทำ staging ให้ representative มากขึ้น — การวิเคราะห์เป็นระบบแบบนี้ดีกว่าการ สรุปเร็วๆ ว่า "ต้องเขียนเทสต์เพิ่ม" โดยไม่รู้ว่าควรเพิ่มที่ layer ไหน
Severity and priority are independent axes set by different stakeholders — strong answers give examples in both mismatched directions. Release-blocking decisions should weigh impact, available workarounds (like feature flags), and the trade-off cost rather than being binary, considering blast radius. Automation excels at predictable, frequently-repeated checks but poorly suits subjective judgment (usability) or fast-churning features, where write/maintain cost can exceed the payoff versus manual testing. When API tests pass but production fails, the gap usually lies outside what API tests can cover — frontend data mapping, unrepresentative staging environments, uncovered edge cases, or concurrency — and systematic escape-rate root-cause analysis identifies which layer actually needs more coverage.