กรณีศึกษา: ทดสอบ 430 เคส ใช้เวลา 4 วัน ช้าหรือเร็ว?

fast-or-slow-testing

สวัสดีเช้าวันอังคารที่ 24 พฤศจิกายน พ.ศ. 2558 เช้าวันนี้ขอนำคำถามที่มีน้อง Software Tester ถามมาและส่วนตัวคิดว่าเป็นคำถามที่น่าสนใจก็เลยขอเจ้าของคำถามว่าจะขอนำมาเป็นกรณีศึกษาให้กับเพื่อนพ้องน้องพี่ได้หรือไม่ เมื่อน้องเจ้าของคำถามตอบตกลงและยินดีที่จะนำมาเป็นกรณีศึกษาให้กับเพื่อนพ้องน้องพี่นั้นผมก็จัดเลยครับ

ขอตั้งชื่อน้อง Software Tester เจ้าของคำถามว่า น้องแอ๋ว และมีทักษะของการทำ Automate Testing ในระดับของ Acceptance Testing ด้วย Robotframework อยู่ระดับหนึ่ง

ความมีอยู่ว่า น้องแอ๋ว เป็น Software Tester ได้รับมอบหมายให้เข้าไปทดสอบซอฟต์แวร์ที่ทีมพัฒนาดำเนินการพัฒนามาเป็นระยเวลาแรมปีแล้ว น้องแอ๋วเป็นคนใหม่ในทีมที่จะต้องเข้าไปทำการทดสอบซอฟต์แวร์ตัวนี้ ในระยะเวลา 4 วันที่น้องแอ๋วดำเนินการทดสอบไปนั้นเธอทดสอบและเก็บผลการทดสอบไปทั้งสิ้น 430 กรณีการทดสอบ (Test Case) เธอได้ฉุกคิดขึ้นมาว่า 430 ใน 4 วัน มันช้าไปไหม?

จากการสนทนากันผ่าน Facebook Message ได้ความว่า

น้องแอ๋วดำเนินการทดสอบไปโดยมีทั้งแบบที่ทดสอบด้วย Automate Testing โดยใช้ Robotframework จำนวนหนึ่งและทดสอบแบบ Manual Testing โดยส่วนใหญ่

สิ่งที่ผมได้ตอบกลับไปที่น้องแอ๋ว คือ

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

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

หลายต่อหลายครั้งผู้คนคิดว่าการนำ Automate Testing เข้ามาใช้นั้นจะลดภาระลงไปได้ในการทดสอบซ้ำๆ รวมทั้งการสร้าง Automate Testing เสียตั้งแต่แรกพร้อมกับตอนรวบรวมความต้องการ (Requirement Gathering) หาก Software Tester หรือ Business Analyst หรือ  Developer หรือ Programmer รู้จักซอฟต์แวร์ตัวนั้นในมุมธุรกิจไม่ใช่เพียงแค่มุมมมองฝั่งเทคโนโลยีเพียงอย่างเดียวเท่านั้น

ในกรณีศึกษานี้สิ่งที่เรายังไม่มีข้อมูลนั้นคือ

  • ได้มีการคุยเพื่อกำหนดขอบเขตของการทดสอบ
  • แผนการทดสอบเป็นเช่นไร
  • กำหนดระดับของการทดสอบไว้อย่างไรบ้าง

ดังนั้นการจะตอบว่าช้าหรือเร็วนั้น ยังค่อนข้างอันตรายและถึงขั้นบั่นทอนกำลังใจกันเลยทีเดียว

ในกรณีนี้ น้องแอ๋ว ควรจะค่อยๆ สร้าง Automate Testing ในระดับของการทดสอบ Acceptance Testing ไปเรื่อยๆ ทีละเล็กทีละน้อยโดยแบ่งออกเป็น 2 กลุ่ม

  • กรณีการทดสอบเดิมแบบ Manual Testing ที่มีอยู่นั้น กรณีใดบ้างที่สามารถแปลงร่างมาเป็น Automate Testing ได้ โดยมองที่ความสำคัญว่าถ้าต้องทดสอบเพื่อให้รู้ผลว่าการเปลี่ยนแปลงที่เกิดขึ้น เน้นที่ระดับผลกระทบต่อการใช้งานของลูกค้าเป็นอันดับแรก
  • Features/Functions ใหม่ๆ ที่ถูกเพิ่มเข้ามานั้นควรจะคิดและวิเคราะห์ว่าสามารถจะนำ Automate Testing ในระดับของ Acceptacen Testing เข้าไปใส่ได้มากน้อยเพียงใด แบบลงทุนน้อยๆ ได้ผลกำไรกลับมาเยอะๆ

ส่วนตัวผมมองว่าเป็นเรื่องที่ดีที่เมื่อเราสงสัย เราก็หันไปถามใครสักคนที่คิดว่าช่วยเราได้ ไม่ว่าจะเป็นเพื่อน เป็นหัวหน้า เป็นคนที่เรารู้สึกว่าน่าจะตอบคำถามเราได้

ขอบคุณน้องแอ๋วที่อนุญาตให้นำเรื่องราวมาเป็นกรณีศึกษาเล็กๆ สำหรับเพื่อนพ้องน้องพี่ WeLoveBug ครับ กราบ -/\-

วันอังคารที่ 24 พฤศจิกายน พ.ศ. 2558 เวลา 7:30น.
หลักสี่ กรุงเทพมหานคร

Leave a Reply

Your email address will not be published. Required fields are marked *