Automated Testing … มันโง่

ยุคนี้สมัยนี้ใครยังทำงานด้วยมือ (Manual) ถือว่าเชย เป็นพวกไดโนเสาร์เต่าล้านปี มันต้องอัตโนมัติ (Automation) ซิถึงจะเท่ — Automated Testing, Automated Build, Automated Deployment, Automated Monitoring, Automated Everything

อาฮะๆ ผมเห็นด้วยนะว่า Automation ช่วยงานเราได้มากในแทบทุกส่วน แต่มุมมองที่ผมมีต่อคำว่าคำนี้คือ “Automation มันโง่” … ทำไมหละ? ลองคิดดูสิครับว่าทำไมเราต้องทำ Automation? เราทำเพราะต้องการทุ่นแรงในการทำงานเดิมๆซ้ำหลายรอบ จนถึงจุดหนึ่งเราก็จะเริ่มตั้งคำถามกับตัวเอง “โง่ป่าววะ นั่งทำงานซ้ำๆอยู่ได้” ว่าแล้วก็เลยสร้างอะไรบางอย่างโง่ๆมาทำงานโง่ๆแทน ฮ่าๆ

อีกสาเหตุหนึ่งที่ผมคิดว่า Automation มันโง่ก็เพราะมันคิดเองไม่ได้ สร้างตัวเองไม่ได้ ทุกอย่างเกิดขึ้นจากสมองของคนเขียนมันขึ้นมาทั้งนั้น … Automation จะไม่มีทางฉลาดไปกว่าคนที่สร้างมันขึ้นมา ขอยกตัวอย่างเรื่องจริงจากบริษัทยักษ์ใหญ่อย่างไมโครซอฟท์

คุณจอห์น (นามสมมติ) เดินมาถึงโต๊ะทำงาน วางกระเป๋า เปิดคอมพิวเตอร์ส่วนตัว รอจนวินโดว์บูทเรียบร้อย โปรแกรมแรกที่เค้าเปิดคือ Microsoft Outlook … สิ่งที่ทำให้คุณจอห์นตกตะลึงคือรูปนี้

Outlook Full Of Junk Emails: https://www.youtube.com/watch?v=fNkYz1hB7r0

เมล์บ๊อกของเค้าโดนถล่มด้วยอีเมล์แปลกๆซ้ำๆเป็นพันๆฉบับ หันซ้ายไปเจอคุณพอล โดนเหมือนกัน หันหลังไปเจอคุณเจนก็ไม่รอด … สรุปโดนกันทั้งบริษัท เล่นเอา Exchange Server แทบล่ม

สาเหตุ: มีคนส่งอีเมล์ด้วยนามสมมติ (Alias) หาผู้รับที่เป็นนามสมมติเช่นกันแล้วกด Recall … แค่นี้เอง

ไมโครซอฟท์มี Automated Test Cases เป็นหมื่นเป็นแสนข้อ แล้วไงอะ มันช่วยจับบั๊กตัวนี้ได้มั้ย บั๊กง่ายๆแค่นี้ บอกแล้วว่า Automation มันไม่ฉลาดไปกว่าคนที่สร้างมันขึ้นมาหรอก

อีกตัวอย่าง — ย้อนกลับไปหลายปีมาแล้ว มีบั๊กที่น่าสนใจหนึ่งตัวในปฏิทินของวินโดว์ บั๊กที่ว่านั้นทำให้เกิดรูปข้างล่างนี้ ทั้งๆที่เดือนกุมภาพันธ์ของปีนั้นมีแค่ 28 วัน

Bug in Windows Calendar: https://www.youtube.com/watch?v=fNkYz1hB7r0

สาเหตุ: มีคนค้นพบภายหลังว่าเมื่อเราเปลี่ยนเดือนไปเรื่อยๆ เคอร์เซอร์บนปฏิทินจะอยู่ที่ตำแหน่งของวันที่เดิมเสมอ นั่นทำให้ถ้าเราเอาเคอร์เซอร์วางไว้ที่วันที่ 30 มกราคมแล้วเลื่อนไปเดือนถัดไป มันจะทำให้เดือนกุมภาพันธ์ของเรามี 30 วันทันที บั๊กนี้มีผลกระทบรุนแรงอยู่นะเพราะมันทำให้การสูตรการคำนวณเกี่ยวกับวันที่ใน Microsoft Excel ผิดพลาดหมดเลย

ไมโครซอฟท์มี Automated Test Cases เป็นแสนเป็นล้านข้อ แล้วไงอะ มันช่วยจับบั๊กตัวนี้ได้มั้ย บั๊กง่ายๆแค่นี้ บอกแล้วว่า Automation มันไม่ฉลาดไปกว่าคนที่สร้างมันขึ้นมาหรอก


ผมเข้าใจนะว่ามันดูดี ดูทันสมัย ถ้าแผนกเราทีมเราคนของเรามี Automation เป็นของตัวเอง แต่อย่างที่พูดหลายรอบแล้วว่า Automation มันไม่ฉลาดไปกว่าคนที่สร้างมันและมันก็ไม่ใช่ทางออกของทุกปัญหาที่เราเจอ

  • เทสไม่ทัน … Automate ซิ
  • เทสไม่ครอบคลุม … Automate ซิ
  • เทสแล้วบั๊กหลุด … Automate ซิ
  • ไม่มีคนเทส … Automate ซิ
  • ไม่รู้จะทำอะไร … Automate ซิ

ถามตรงนี้ว่า Automation จะช่วยอะไรได้ถ้าคนที่สร้างมันขึ้นมาไม่มีความรู้เพียงพอว่าฉันควรจะ Automate อะไรบ้าง? การมองว่า Automation เป็นจุดเริ่มต้นและจุดหมายสุดท้ายเป็นเรื่องอันตรายเพราะเรากำลังถูกฟีเจอร์ (Feature) บดบังคุณค่า (Value) …

แท้จริงแล้วเราไม่ได้ต้องการ Automated Test Cases เป็นหมื่นข้อแสนข้อ แต่เราต้องการซอฟต์แวร์ที่มีคุณภาพ และถ้าเราคิดว่าคุณภาพของซอฟต์แวร์วัดกันที่ Number of Test Cases นั่นยิ่งเป็นการขุดหลุมฝังตัวเองอย่างสมบูรณ์แบบ — คุณภาพของซอฟต์แวร์วัดกันที่คุณภาพของคนที่สร้างมันต่างหาก

ทำไมไม่มี Automated Test Case ไหนที่จำลองสถานการณ์การส่งอีเมล์จากนามสมมติหานามสมมติแล้ว Recall? คำถามที่น่าสนใจกว่านั้นคือ ทำไมไม่มีใครในทีมคิดถึงสถานการณ์นี้? ก่อนจะลงมือหลับหูหลับตาเขียน Automated Test Case เราเอาเวลามาทำความเข้าใจก่อนดีมั้ยว่าขอบเขตของการเทสที่ครอบคลุมของการส่ง รับ และเรียกคืนอีเมล์มีอะไรบ้าง

  • ส่งจากอีเมล์ปกติ
  • ส่งจากอีเมล์ที่เป็นนามสมมติ — *
  • ส่งจาก Distribution List
  • ส่งหาอีเมล์ปกติ
  • ส่งหาอีเมล์ที่เป็นนามสมมติ — *
  • ส่งหา Distribution List
  • เรียกคืนจากอีเมล์ปกติ
  • เรียกคืนจากอีเมล์ที่เป็นนามสมมติ — *
  • เรียกคืนจาก Distribution List

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


ป.ล.1: ตัวอย่างบั๊กที่เล่าข้างบนมาจากเจมส์ วิทเทเกอร์ (James Whittaker — Engineering Director ที่เคยทำงานให้ทั้งไมโครซอฟท์และกูเกิ้ล) ลองดูนะครับ สนุกดี

ป.ล.2: อยากรู้มั้ยว่าไมโครซอฟท์แก้บั๊กเรื่องปฏิทินยังไง? ลองเทสดูจากเครื่องของคุณสิ ☺


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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ

Show your support

Clapping shows how much you appreciated Piyorot’s story.