สิ่งเล็ก ๆ ที่เรียกว่า “การทดสอบ“

ในการพัฒนา software นั้น เรื่องของการทดสอบ หรือ testing มันมีเยอะมาก ๆ
โดยการทดสอบแต่ละอย่าง ล้วนมีเป้าหมายที่แตกต่างกันไป
ดังนั้นเรามาดูกันหน่อยว่า
เราควรจะทำการทดสอบอะไรบ้าง เป็นอย่างน้อย

1. Acceptance Test หรือ Customer Test

ช่วยทำให้เราเข้าใจพฤติกรรมการทำงาน
และการใช้งานของแต่ละ feature
ที่สำคัญช่วยทำให้นักพัฒนาเข้าใจด้วยว่า
feature แต่ละตัวมันมีการทำงาน และ ใช้งานจริง ๆ อย่างไร
ไม่ใช่มานั่ง มโน หรือ คิดเอง เออเอง
สุดท้ายก็มานั่งแก้ไข หรือ รื้อใหม่หมด !!

โดยในแต่ละ feature นั้นต้องมีชุดการทดสอบที่ประกอบไปด้วย

• Business rule และ ขั้นตอนการทำงาน หรือ ใช้งาน
• ข้อมูลตัวอย่างของการทดสอบในแต่ละ flow

สิ่งเหล่านี้เรียกรวม ๆ กันว่า Acceptance criteria
เพื่อทำให้เรารู้ว่า เมื่อไรจึงหยุดพัฒนา
เพื่อทำให้เรารู้ว่า เมื่อไรจึงถึงบอกได้ เสร็จ (Done)

เนื่องจากนักพัฒนาทุกคน ประสบกับปัญหานี้อย่างมาก
ทำให้ทุกคนมักจะสร้างเผื่อไว้หมด
ซึ่งมันสิ้นเปลืองอย่างมากทั้ง เวลา และ ค่าใช้จ่าย

ดังนั้นนักพัฒนาที่มี Acceptance Test มักจะพูด หรือ คิดว่า

• เราทำการพัฒนา feature นี้ สำหรับกรณี 1, 2 ,3 … หรือยังนะ ?
• เราทำการพัฒนา feature ให้มันทำงานได้อย่างถูกต้อง และ น่าเชื่อถือหรือยังนะ ?
• หยุดการ เผื่อ เพื่ออนาคตสักที !!

สุดท้ายเราสามารถนำมาเขียน และ สร้างชุดการทดสอบแบบอัตโนมัติได้
มักจะเรียกว่า Automated Acceptance Testing นั่นเอง

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

ดังนั้น ลด ละ เลิก สิ่งเหล่านี้ซะ

• เข้ารหัส
• ใช้คำย่อ
• ใช้คำเฉพาะ
• ใช้คำทาง technical

2. Unit Test หรือ Developer Test

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

ซึ่งในส่วนนี้ทางนักพัฒนาจะเริ่มจากการเขียน Unit Test
ก่อนที่จะเขียน production code หรือ code ของระบบงานนั่นเอง
เรียกแนวคิดนี้ว่า Test-First หรือ Test-Driven Development (TDD)

โดยที่ Unit Test มันคือ internal document
ไว้สำหรับอธิบายส่วนการทำงานย่อย ๆ ของระบบงาน

3. Other Test หรือ Quality Assurance Test

ในการพัฒนา software ยังมีการทดสอบอีกเยอะมาก ๆ
แน่นอนว่า ต้องเน้นไปที่เรื่องของคุณภาพ
ตัวอย่างเช่น
Integration test เพื่อทำให้มั่นใจว่าแต่ละ component ทำงานร่วมกันได้หรือไม่
ซึ่งเป็นการทำงานร่วมกันจริง ๆ
ไม่ใช่ทำการทดสอบด้วยการ mock นะ
แต่ข้อเสียของมันคือ

• การทดสอบช้ามาก
• การทดสอบผิดพลาดได้ง่าย

ยิ่งถ้าเป็นขั้นตอนการทำงานที่ซับซ้อนด้วยแล้ว
ยิ่งทำงานช้าไปกันใหญ่

ดังนั้นขอแนะนำให้ทำการทดสอบ
ในระดับ Unit Test ให้ได้มากที่สุดเท่าที่จะทำได้
เพราะว่า จะทำให้เราทดสอบได้ง่าย และ เร็วนั่นเอง

หรือจะทำการทดสอบแบบ Manual ก็ได้นะ
แต่คุณก็รู้กันใช่ไหมว่า cost-to-release มันสูงมาก ๆ
แล้วยังจะทำเยอะกันอีกหรือไง ?

สุดท้ายแล้ว เราพยายามสร้างการทดสอบแบบอัตโนมัติขึ้นมา

เพื่อลดขั้นตอนการทำงานที่ต้องใช้คนให้มากที่สุด
มีเป้าหมายเพื่อ

• ทำการทดสอบ และ ตรวจสอบระบบงานได้ตลอดเวลา
• เพิ่มความมั่นใจต่อระบบทั้งทีมพัฒนา และ ลูกค้า
• สามารถ deploy และ release ระบบได้ตลอดเวลา

แต่ไม่ใช่ว่า จะไม่มีคนมาเกี่ยวข้องกับการทดสอบเลยนะครับ !!

โดยรวมแล้ว

นี่แหละคือสิ่งเล็ก ๆ ที่เรียกว่า การทดสอบ
แต่มันสำคัญอย่างมหาศาล

จำไว้ว่า
ก่อนที่คุณจะสร้าง หรือ พัฒนาอะไรขึ้นมา
สิ่งที่ต้องคุณต้องรู้ และ เข้าใจ คือ

• มันคืออะไร มีประโยชน์อะไร ต่อใครบ้าง ?
• ที่สำคัญคือ คุณจะทดสอบอย่างไร ? ด้วยข้อมูลอะไร ?

การมารู้วิธีทดสอบหลังจากพัฒนาเสร็จแล้ว
มันไม่เคยให้ประโยชน์แก่ใครเลย
ซึ่งเราทุกคนก็น่าจะรู้ และ ประสบพบเจอมาด้วยกันทั้งนั้น
ดังนั้น ลด ละ เลิก เถอะครับ