บาปร้ายแรง 7 ประการ จากการทดสอบ Software แบบอัตโนมัติ

สวัสดีครับ พอดีพี่หนุ่มได้แชร์ลิงค์บทความนี้มาให้ เลยเอามาสรุปไว้ครับ

ต้นฉบับ 7 Deadly Sins of Automated Software Testing

ตัวบทความก็เป็นการเอา Anti-pattern (แปลว่าอะไรดี… สิ่งที่ไม่ควรทำ ละกัน) 7 อย่าง (แน่นอนว่ามีมากกว่านี้) มาเทียบกับบาป 7 ประการในหลักศาสนาคริสต์ ครับ

คนทั่วๆไปจะเข้าใจว่าการทำ Automated test คือ ของวิเศษที่สามารถลดเวลาและแรงงานที่ใช้ในการทดสอบได้ ซึ่งก็จริงส่วนหนึ่ง แต่มันก็ไม่ได้วิเศษอะไรขนาดนั้นนะครับ วิธีการนำไปใช้บางวิธีกลับควรจะหลีกเลี่ยงมากกว่า

1. Envy (ความอิจฉา)
   การคาดหวังว่า เมื่อมีการทำ Automated test แล้วจะไม่ต้องมีการทำ Manual test อีกต่อไป ซึ่งผิดมาก การทดสอบนั้นรูปแบบ, ช่วงเวลา, ระดับ และ วิธีการที่แตกต่างกันมากมาย ซึ่งต้องการการปฏิบัติที่เหมาะสม การทดสอบไม่ใช่อะไรที่สามารถนำมาทำซ้ำๆ ได้ทั้งหมด การทดสอบแบบที่ใช้คนทำการทดสอบนั้นยังคงต้องมีอยู่ครับ
2. Gluttony (ความตะกละ)
   อันนี้คือการพึ่งพาเครื่องมือที่เป็น Commercial มากเกินไป เครื่องมือเหล่านี้จะใช้งานได้ง่ายในช่วงแรกๆ เน้นไปที่การ Record & replay ที่ระดับ UI จริงๆ ซึ่งมอบความสะดวกให้ในช่วงแรกๆของการทำงาน แต่เมื่อเวลาผ่านไป ชุดการทดสอบนั้นจะเริ่มดูแลรักษายาก จะเอาไปเก็บไว้ใน source control ก็ไม่ได้ จำกัดสิทธิ์การเข้าถึงอีกตะหาก อย่างงี้จะให้ทีมช่วยกันดูแลรักษาได้ยังไง
3. Lust (ความปรารถนา … นี่เลือกคำแปลที่อีโรติคน้อยสุดละครับ)
   ก็คือการทดสอบทั้งหมด เอาไว้ที่ระดับ UI หมดเลย! ตอนแรกๆผมก็มีอาการนี้นะครับ ก็มันง่ายดี เวลาทดสอบก็เห็นเลยว่ามันทำอะไรบ้าง เอาไปโชว์ก็มีแต่คนชอบ ใครๆก็อยากเป็นที่รักของทุกคน จริงแมะ
   แต่การทดสอบที่ระดับ UI มันมีค่าใช้จ่ายที่สูงครับ เพราะมันต้องใช้เวลาพอสมควรในการเปิดโปรแกรมขึ้นมาทดสอบ แล้วก็ต้องเสียทรัพยากรส่วนหนึ่งให้กับการทดสอบด้วย การทดสอบระดับ UI หลายๆอันพร้อมๆกันนั้นจึงสิ้นเปลืองเวลาและทรัพยากรเอามากๆ ทางออกคือเอาการทดสอบที่ไม่จำเป็นสำหรับการทดสอบระดับ UI ออกไป ให้มันอยู่ในที่ของมัน ทำ unit test ให้มากที่สุดแล้วค่อยๆไล่ระดับขึ้นมาจะดีกว่าครับ
4. Pride (ความทะนงตน)
   เขียนอยู่คนเดียว รันอยู่คนเดียว ภูมิใจในชุดการทดสอบที่ตัวเองเขียนอยู่คนเดียว (หรือกลุ่มเดียว) แบบนี้ก็ไม่ได้ต่างจากการทดสอบแบบปกติสักเท่าไหร่นะครับ คนที่สร้างของพวกนี้เค้าพยายามจะผลักดันให้ การทดสอบ กับ การออกแบบ นั้นเป็นเรื่องเดียวกัน เกิดขึ้นพร้อมๆกัน เพื่อให้เกิดการแบ่งปันความรู้ความเข้าใจกันในทีม ถ้าทำอยู่คนเดียวมันจะไปมีประโยชน์อะไรล่ะ
5. Sloth (ความเกียจคร้าน)
   จุดเด่นของ Automated test คือมันรันได้บ่อยๆ รันได้ตลอดเวลา ในขณะที่กำลังทำงานก็สามารถรู้ได้เร็วมากว่าโค้ดที่เขียนทำให้มีอะไรพังหรือเปล่า พอเจอว่าพังก็รีบซ่อม แต่กลับกัน เมื่อเจอว่ามีอะไรพัง ก็มักจะปล่อยๆไปก่อน งานกำลังยุ่งมากๆ หรือไม่ก็ขี้เกียจซ่อมจริงๆ เดี๋ยวก็มีคนมาจัดการเองนั่นแหละ
   การปล่อยของที่พังเอาไว้ มันก็จะยิ่งมีของที่พังมากขึ้นเรื่อยๆ เรื่อยๆ จนถึงวันที่เกิดอยากจะซ่อมหรือจำเป็นต้องซ่อมขึ้นมา ก็อาจจะสายไปแล้ว
6. Rage (ความเดือดดาล)
   Test ที่ช้า, พังง่าย หรือ ไม่น่าเชื่อถือ พอนานๆเข้ามันก็ทำให้คุณค่าในการดูแลรักษามันลดลง ถ้าต้องมาซ่อมมันบ่อยๆ ใครๆก็หงุดหงิดใช่มั้ยล่ะครับ ถ้าปล่อยไว้แบบนั้น สักวันหนึ่งก็อาจจะมีใครสักคนพูดขึ้นมา “เลิกเหอะ”
7. Avarice/Greed (ความโลภ)
   ในที่นี้คือการที่เอา Automated test มาใช้โดยสนใจแต่เรื่อง ROI (Return of investment) ในแง่มุมของการลดการใช้แรงงานคนเพียงอย่างเดียว อย่าลืมว่าลดค่าใช้จ่ายตอนต้องจ้างคนมานั่งทดสอบได้ แต่ก็มีค่าใช้จ่ายอื่นๆ อย่างเช่นการ นำมาใช้งานก็ต้องมีการ Training แล้วก็ต้องปล่อยให้คนทำงานที่เป็นคนสร้างชุดการทดสอบลองผิดลองถูกกันก่อน หรือ คำใช้จ่ายสำหรับบำรุงรักษาชุดการทดสอบในระยะยาวด้วยนะครับ

สรุป

Anti-pattern (แปลว่าอะไร ลืมยัง?) มันยังมีอีกมาก มากกว่า 7 ประการนี้แน่นอน แต่แค่ 7 ตัวนี้ก็สามารถพาเราตกนรกหมกไหม้ได้แล้วนะครับ เพราะฉะนั้นจะใช้ Automated test ก็ใช้อย่างมีสติกันนะครับ

ป.ล. อย่าลืมไปอ่านบทความต้นฉบับกันด้วยนะครับ