Blog

Code qualityCommunication

ทำอย่างไรเมื่อบริษัทไม่ให้เวลาเขียน Test (Strategic Testing for Tech Leads)

Ratchata Nuanchan

By Ratchata Nuanchan

27 ธันวาคม 2568

ทำอย่างไรเมื่อบริษัทไม่ให้เวลาเขียน Test (Strategic Testing for Tech Leads)

1. ทำไมเราถึง (อยาก) เขียน Test?

  • Confidence: เพื่อให้เรามั่นใจว่า Feature ใหม่จะไม่ไปพัง Feature เก่า (Regression)
  • Speed (Long-term): ช่วงแรกอาจจะช้า แต่เมื่อโปรเจกต์ซับซ้อนขึ้น การมี Test จะทำให้เรากล้า Refactor และพัฒนาต่อได้เร็วกว่าเดิม
  • Documentation: Test Case คือเอกสารชั้นดีที่บอกว่าระบบควรทำงานอย่างไร

2. Empathy: เข้าใจ "ความเจ็บปวด" ฝั่ง Business

  • Time-to-Market is King: ในหลายอุตสาหกรรม การปล่อย Feature ช้าไป 1 สัปดาห์ อาจหมายถึงการเสีย Market Share ให้คู่แข่งมหาศาล
  • Opportunity Cost: ทุกวันที่เราใช้เวลาไปกับการเขียน Test (ที่เราบอกว่าดี) คือวันที่เขาเสียโอกาสในการเทสว่า Product นี้ขายได้จริงไหมกับตลาด
  • Budget & Runway: เวลามีจำกัด เงินทุนมีวันหมด เขาต้องการ "กระสุน" (Feature) ไปยิงให้โดนเป้า (Customer) ให้เร็วที่สุด
  • Business: เน้น Speed & Outcome (เสร็จเร็ว ขายได้)
  • Engineer: เน้น Quality & Stability (ระบบดี ไม่พัง)

3. The Strategy: เขียน Test ให้ฉลาด (ROI of Testing)

  • E2E Test (High Value): เน้นเทสที่ "ผลลัพธ์หน้าบ้าน" ที่ User ใช้งานจริง เช่น Login ได้ไหม? จ่ายเงินแล้วยอดตัดไหม? ถ้าตรงนี้ผ่าน แปลว่าระบบใช้งานได้จริง (แนะนำให้ทำส่วนนี้ก่อนถ้าเวลาน้อย)
  • Integration Test: เน้นจุดเชื่อมต่อสำคัญ เช่น API คุยกับ Database ถูกไหม?
  • Unit Test: ทำกับ Logic ที่ซับซ้อนและมีความเสี่ยงสูง เช่น สูตรคำนวณภาษี, Regex (ส่วน Function ทั่วไปที่ไม่มี Logic ซับซ้อน ข้ามไปก่อนได้)

4. Negotiation: ศิลปะการต่อรอง

  1. Option A (Speed): เราปล่อยฟีเจอร์ตามกำหนด แต่ผมขอเขียน E2E Test ดักไว้แค่เคสสำคัญที่สุด (Happy Path) ส่วนเคสย่อยๆ เรายอมรับความเสี่ยงร่วมกัน (Tech Debt) แล้วสปรินต์หน้าผมขอเวลา 1 วันมาเก็บงานนี้คืน
  2. Option B (Quality): ถ้าตัวเลขนี้ห้ามผิดเด็ดขาด ผมขอเวลาเพิ่มอีก 1 วัน เป็น 4 วัน เพื่อทำ Test ส่วนคำนวณเงินให้เป๊ะครับ พี่คิดว่าทางไหนตอบโจทย์ Business ตอนนี้มากกว่าครับ?"

ความเก่งของ Engineer วัดจากอะไร

  1. Technical: เขียนโค้ดเก่ง รู้จัก Clean Code, Design Pattern
  2. Ownership: รับผิดชอบงาน เข้าใจบริบทธุรกิจ ปรับเปลี่ยนเครื่องมือตามสถานการณ์
  3. Influence: โน้มน้าวคนเป็น สื่อสารความเสี่ยงทางเทคนิคให้เป็นภาษาธุรกิจ และสร้างความเชื่อใจให้กับทีม

เรื่องอื่นๆ ที่คุณอาจจะสนใจ

People Skill for dev

Subscribe to our Email & Follow us on Social Media

อัปเดตความรู้เกี่ยวกับ People, Product, Process และ Tech ได้ก่อนใคร!

Subscribe