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

ในโลกอุดมคติ Software Engineer ทุกคนถูกปลูกฝังมาว่า "ระบบที่ดีต้องมีการทำ Testing" ไม่ว่าจะเป็น Unit Test, Integration Test หรือ E2E Test ที่เปรียบเสมือนเป็นกล้องวงจรปิดที่คอยตรวจสอบว่าระบบทำงานอย่างถูกต้อง

แต่ในโลกความเป็นจริง ตั้งแต่ผมเริ่มทำงานมาตั้งแต่ปี 2015 ผมเจอบริษัทน้อยมากที่สามารถทำ Test ได้ครอบคลุมและมีคุณภาพจริงๆ

คำถามคือ... ทำไม? ทำไมในเมื่อเรารู้ว่ามันดี แต่เรากลับไม่มีเวลาทำมัน?

บทความนี้เราจะไม่พูดถึง วิธีการเขียน Test แต่เราจะมาคุยกันถึง วิธีการบริหารจัดการ เมื่อต้องเผชิญหน้ากับแรงกดดันทางธุรกิจ และเปลี่ยนสถานการณ์จาก "ผู้ทำตามคำสั่ง" ให้กลายเป็น "ผู้นำที่ช่วยหาทางออก" ครับ

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

เราต้องตอบตัวเองให้ชัดก่อนว่าเราทำไปเพื่ออะไร? คำตอบไม่ใช่ "เพราะตำราเขาบอกมา" แต่คือ:

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

แต่ถ้าเราเข้าใจประโยชน์พวกนี้ดีอยู่แล้ว ทำไม Business ถึงยังไม่ซื้อไอเดียเรา?

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

Software Engineer มักมองว่า Business คือตัวร้ายที่คอยเร่งงาน แต่ถ้าเราลองสวมหมวกของเขาดู เราจะเห็นแรงกดดันอีกแบบครับ

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

ปัญหาจึงไม่ใช่ "เขาไม่เห็นความสำคัญ" แต่คือ "Goal ของสองทีมมันไม่ตรงกัน"

• Business: เน้น Speed & Outcome (เสร็จเร็ว ขายได้)
• Engineer: เน้น Quality & Stability (ระบบดี ไม่พัง)

หน้าที่ของเราคือการเป็นสะพานเชื่อม 2 สิ่งนี้เข้าด้วยกันครับ

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

เมื่อเวลาเป็นทรัพยากรที่จำกัด เราไม่สามารถ "Test ทุกอย่าง" ได้ การดันทุรังจะเขียน Unit Test ให้ครบ 100% Coverage ในโปรเจกต์ที่ Requirement เปลี่ยนบ่อย คือการเผาเวลาโดยใช่เหตุ

Tech Lead ที่ดีต้องรู้จักบริหาร ROI (Return on Investment) ของการเขียน Test ครับ

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

Key Takeaway: อย่าเขียน Test เพื่อเอา Coverage แต่จงเขียนเพื่อป้องกันความเสี่ยงที่อาจจะเกิดขึ้น

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

มาถึงจุดที่ยากที่สุด คือการคุยกับ Product Owner (PO) หรือ Project Manager (PM)

สมมติสถานการณ์: PO โดน CEO กดดันมาว่าต้องปล่อยฟีเจอร์ Export Report ภายใน 3 วันเพื่อดึงลูกค้า

❌ วิธีแบบ Developer ทั่วไป (Reactive): "3 วันไม่ทันหรอกพี่ ต้องเขียน Test ด้วย ถ้าไม่เขียนเดี๋ยวบั๊กบานนะ พี่รับผิดชอบไหวเหรอ?"

ผลลัพธ์: PO มองว่าคุณเรื่องมาก ไม่ช่วยแก้ปัญหา และอาจเกิดการเมืองในทีม

✅ วิธีแบบ Tech Lead (Strategic & Proactive): เราจะใช้หลักการ Risk Assessment และ Option Offering เข้ามาช่วยครับ

Step 1: Empathy (แสดงความเข้าใจ) "ผมเข้าใจครับพี่ว่าฟีเจอร์นี้ CEO เร่งมาจริงๆ เพราะลูกค้าเจ้านั้นสำคัญมาก ถ้าเราปล่อยช้าเราเสียลูกค้าแน่ๆ" (ทำให้เขารู้สึกว่าเราอยู่ทีมเดียวกับเขา)

Step 2: Explain the Risk (บอกความเสี่ยงในมุม Business) "แต่ผมกังวลนิดนึงครับพี่ ด้วยความรีบระดับนี้ ถ้าเราลุยทำเลยโดยไม่มี Test ดักไว้เลย ความเสี่ยงคือตอน Export ข้อมูลจริง ตัวเลขการเงินอาจจะผิด หรือระบบอาจจะล่มตอนลูกค้ากดพร้อมกัน ซึ่งถ้าเกิดแบบนั้น ลูกค้าอาจจะเสียความเชื่อมั่นหนักกว่าเดิมครับ"

Step 3: Offer Options (เสนอทางเลือก) "เพื่อให้ทัน Deadline 3 วัน ผมมีทางเลือกให้พี่ครับ:

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

ผลลัพธ์: PO จะรู้สึกว่าคุณคือ Partner ที่ช่วยคิด ไม่ใช่คนที่สร้างปัญหา และเขาจะเป็นคนเลือกความเสี่ยงนั้นเอง

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

ความเก่งของ Software Engineer ไม่ได้วัดกันแค่ที่ Technical Skill ครับ แต่วัดกันที่ 3 ระดับนี้:

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

การที่ Business ไม่ให้เวลาเขียน Test ไม่ใช่ทางตัน แต่เป็น "โอกาส" ให้คุณได้ฝึกทักษะระดับที่ 3 ครับ

เริ่มจากการเปลี่ยนมุมมอง แล้วเดินเข้าไปคุยด้วยภาษาของเขา นั่นคือก้าวแรกของการเป็น Engineering Leader ตัวจริงครับ

ลองนำเทคนิคการเจรจา (Step 1-2-3) ไปปรับใช้ใน Meeting ครั้งถัดไปดูครับ ได้ผลลัพธ์อย่างไร แวะมาแชร์ให้ฟังกันได้ครับ