10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ ตอน เน้นความเรียบง่าย อย่าเริ่มด้วยท่ายาก

keep-it-simple

กลับมาอีกครั้งสำหรับตอนที่ 6 ของ 10 หลักปฏิบัติของ Agile Tester ที่ไม่ใช้ Agile ก็นำไปทำได้ ค่ำคืนนี้ขอว่าด้วยเรื่องของ Keep it Simple โดยหนูขอแปลเป็นภาษาไทยว่า เน้นความเรียบง่าย อย่าเริ่มด้วยท่ายาก

เอาจริงๆ พอทำงานในสายงานของการพัฒนาซอฟต์แวร์หนูว่าเราเริ่มอะไรหลายๆ สิ่งด้วย ท่ายาก เสมอ นับตั้งแต่บอกให้ลูกค้าเขียนและบอกความต้องการทั้งหมดอย่างละเอียด ต่อด้วยวิเคราะห์แล้วก็ออกแบบใหญ่ๆ ละเอียดๆ ส่งต่อมาที่เขียนโค้ดก็ใช้ท่ายากเสมอๆ ไม่เว้นแม้กระทั่งส่วนของการทดสอบเองก็ตาม Software Tester เองก็เล่นท่ายากอยู่เป็นประจำ

ท่ายาก ในความหมายของหนูนั้นคือ มอง คิด วิเคราะห์ และลงมือทำเรื่องต่างๆ แบบใหญ่ๆ เผื่อๆ น่าจะใช้นะ แต่ไม่รู้จะได้ใช้หรือเปล่า

สำหรับเรื่องของการทดสอบซอฟต์แวร์ในการพัฒนาแบบแอจไจล์ (Agile) นั้น ได้พูดถึงเรื่องของความเรียบง่ายๆ ไว้น่าสนใจมากๆ เพื่อกระตุกแนวคิดและความคิดของเราๆ ทุกๆ คน

ผู้เขียนหนังสือ Agile Testing หยิบยกคำพูดของลุง Kent Back ที่ว่า

to do the simplest thing that could possibly work, don’t mean first thing you try will actually work but it ought to be simple

หนูขอแปลเป็นภาษาไทยว่า

เริ่มต้นทำด้วย สิ่งที่ง่ายที่สุดที่ก่อนอาจจะใช้งานได้ แต่ก็ไม่ได้หมายความว่า มันจะจะทำงานจริงๆ ก็ได้ แต่ก็ควรจะเป็นสิ่งเรียบง่าย

ทีมพัฒนาซอฟต์แวร์ทั้งทีมรวมทั้ง Softeware Tester เองด้วยให้เน้นเรื่องของการส่งมอบซอฟต์แวร์ที่ทำงานได้จริงที่ใกล้เคียงกับความต้องการของผู้ใช้หรือลูกค้าพร้อมกับคุณภาพ ที่น่าสนใจตอนตรงนี้คือ ทีมพัฒนาซอฟต์แวร์จะต้องตกลงกับผู้ใช้งานหรือลูกค้า ว่า คำว่าคุณภาพของซอฟต์แวร์นั้น จะต้องทดสอบทั้งหมดกี่ระดับ (Test Level) ทั้ง Functional และ Non-Functional โดย ทีมพัฒนาซอฟต์แวร์จะต้องให้ข้อมูลประกอบการตัดสินใจของผู้ใช้หรือลูกค้า

ข้อมูลประกอบการตัดสินใจ คืออะไร?

ข้อมูลประกอบการตัดสินใจ นั้นคือ การแนะนำเรื่องคุณภาพและการทดสอบซอฟต์แวร์ (Software Quality and Software Testing) ซึ่ง ผมถือว่าหากในทีมพัฒนาซอฟต์แวร์มีสมาชิกที่ทำหน้าที่เป็น Software Tester อยู่หรือหากว่าไม่มีแต่มีทีม Test อยู่ในองค์กร เป็นหน้าที่ของ Software Tester หรือ สมาชิกของทีม Test ที่จะต้องเป็นผู้อธิบายและยกตัวอย่างประกอบแบบง่ายๆ เพื่อให้ทั้งผู้ใช้งานหรือลูกค้ารวมทั้งสมาชิกของทีมพัฒนาซอฟต์แวร์ได้รับทราบความหมายของการทดสอบแต่ละระดับทั้ง Functional และ Non-Functional อย่างถูกต้องเพื่อปรับให้ทุกๆ คนมีข้อมูลเท่าๆ กันก่อนที่จะไปสู่ข้อตกลงร่วมกันถึงคำว่า คุณภาพของซอฟต์แวร์ที่จะส่งมอบกันนั้นประกอบไปด้วยอะไรบ้าง

สิ่งสำคัญหนึ่งเรื่องที่ทุกๆ คนที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ต้องรับทราบว่า

ไม่มีของคุณภาพดีและราคาถูก ซอฟต์แวร์เองก็เช่นกัน

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

Doing Simplest Test Possible

เรื่องหลักๆ ของการควบคุมคุณภาพและทดสอบซอฟต์แวร์นั้นสำหรับหนูคือ

การตรวจสอบว่าการทำงานของซอฟต์แวร์ใกล้เคียงกันกับความต้องการของผู้ใช้หรือลูกค้าหรือไม่?

ดังนั้นการควบคุมคุณภาพและการทดสอบซอฟต์แวร์นั้นควรจะต้องมองเรื่องของการดำเนินการให้เร็วที่สุดและเริ่มต้นจากเรียบง่ายก่อนซึ่ง Software Tester และสมาชิกของทีมพัฒนาซอฟต์แวร์จะต้องสนใจเรื่องของการทดสอบเพื่อ

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

หลายต่อหลายคั้งเราไม่สามารถส่งมอบซอฟต์แวร์ออกไปได้รวดเร็วตามความต้องการของฝั่ง Business เพราะมาติดหล่มอยู่ตรงช่วงของการทดสอบซอฟต์แวร์ไม่ว่าจะเป็นเพราะ

  • Software Tester ทดสอบไม่ทันเพราะจำนวนกรณีการทดสอบ (Test Cases) มีมากกว่า เวลาที่ได้มาเพื่อทดสอบ
  • Software Tester สนใจและทดสอบกรณีการทดสอบที่นาน นาน นาน และนานๆ จะเกิดขึ้นที
  • จำนวน Bug ที่ตรวจสอบมากมายก่ายกอง
  • ต้องมานั่งไล่แก้ Bug ที่ Software Tester สนใจและทดสอบกรณีการทดสอบที่นาน นาน นาน และนานๆ จะเกิดขึ้นที
  • การทดสอบซ้ำไปซ้ำมาทั้งส่วนของ Re-Test และ Regression Testing แบบใช้แรงงาน (Manual Testing)

ดังนั้นจากประสบการณ์ของหนูที่เคยทำสิ่งที่กล่าวมาข้างต้นมาแล้วนั้นขอแนะนำว่า

  • Software Tester แบ่งแยกกรณีการทดสอบ (Test Case) ออกเป็น 2 ส่วน คือ
  • Test to Pass ทดสอบเพื่อตรวจสอบว่าซอฟตแวร์ทำงานได้ถูกต้องตรงหรือใกล้เคียงกับความต้องการ
  • Test to Fail ทดสอบแบบยำให้เละเพื่อหาข้อผิดพลาดอื่นๆ ที่จะเกิดขึ้น
  • ให้น้ำหนักกับ Test to Pass ก่อนเสมอ เพราะหากทดสอบครบและแก้ไข Bug ที่เกิดขึ้นในส่วนนี้ได้ก่อน เราสามารถส่งมอบซอฟต์แวร์และเปิดใ้บริการได้
  • Test to Fail ทำเท่าที่เพียงพอและเหมาะสมกับเวลาก่อน แล้วค่อยทำเพิ่มเติมทีหลังหากมีเวลาเหลือพอ โดยทุกๆ คนในทีมพัฒนาซอฟต์แวร์ต้องร่วมด้วยช่วยกันเพื่อประเมิน พิจารณา วิเคราะห์และสรุปว่ามีความเสี่ยงอะไรบ้างอันดับต้นๆ ที่จะทำให้เกิดปัญหาได้เมื่อเราเปิดให้บริการซอฟต์แวร์นั้น แล้วก็หยิบความเสี่ยงนั้นๆ มาออกแบบและสร้างเป็นกรณีการทดสอบ (Test Case)
  • ลดปริมาณการใช้แรงงานเพื่อทดสอบ (Manual Testing) และเพิ่มการทดสอบแบบอัตโนมัติ (Automate Testing) ให้ได้มากที่สุด
  • Automate Testing อย่าตั้งต้นจากเครื่องมือเป็นอันขาด
  • Automate Testing ตั้งต้นจาก
  • ความต้องการที่จะทดสอบ
  • นำไปสู่การออกแบบการทดสอบให้ได้ก่อนว่าจะทดสอบอย่างไร
  • แล้วต่อด้วยวิเคราะห์และออกแบบการสร้างซอฟต์แวร์ในฟังก์ชันการทำงานนั้นๆ ตามกรณีการทดสอบที่ออกแบบมา
  • พิจารณาว่าจากกรณีการทดสอบที่ออกแบบมานั้นสามารถทำให้เป็น Automate Testing ได้กี่กรณี
  • เลือกเครื่องมือสำหรับ Automate Testing ที่เรียบง่าย เน้นว่า เรียบง่าย ในแต่ละระดับของการทดสอบ (Test Level) ที่ทุกๆ คนในทีมพัฒนาซอฟต์แวร์ส่วนใหญ่สามารถใช้งานได้

สรุป

ความเรียบง่ายในการทำงานนั้น ไม่ใช่ ง่าย ดังนั้นสำหรับการควบคุมคุณภาพและทดสอบซอฟต์แวร์นั้นขอให้เน้นเรื่องของความเรียบง่ายด้วยเช่นกัน วิเคราะห์ความต้องการของซอฟต์แวร์ออกเป็นฟังก์ชันการทำงานแบบเรียบง่ายเน้น Buiness Process เป็นหลัก แล้วทำการคิดก่อนว่าจะทดสอบอย่างไรโดยเน้นเรื่องของทดสอบให้ครบตามความต้องการของฟังก์ชันก่อน โดยแต่ละความต้องการต้องถูกทดสอบอย่างน้อยหนึ่งครั้งและอย่าทดสอบหลาย หลาย และหลายกรณีการทดสอบเพื่อหา Bug เพียงตัวเดียว แล้วไปมองที่การทดสอบเพื่อลดความเสี่ยงที่ก่อให้เกิด Bug และปัญหาเมื่อเราเปิดให้บริการซอฟต์แวร์นั้นๆ และอย่าฝากผีฝากไข้ไว้กับแค่คนที่ถูกอุปโลกน์ขึ้นมาเป็น Software Tester ทุกๆ คนที่เกี่ยวข้องกับกระบวนการพัมนาซอฟต์แวร์จะต้องร่วมด้วยช่วยกันรับผิดชอบเรื่องของคุณภาพและการทดสอบซอฟต์แวร์นะจ๊ะ

วันจันทร์ที่ 1 มิถุนายน พ.ศ. 2558 เวลา 22:01น.
หลักสี่ กรุงเทพมหานคร
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.