Jaynarol Blog

บันทึกย่อ ความรู้ที่ได้รับใน [Give’n Take] Software Testing mode Preventive วันที่ 1

วันนี้มีโอกาสได้เข้า [Give’n Take] Software Testing mode Preventive ที่แบ่งปันโดยพี่หนุ่ม @ สยามชำนาญกิจ

ได้มุมมองใหม่ๆมาหลายเรื่อง เยอะมาก สนุกและเข้าใจหมด แต่ปัญหาคือเรียงลำดับไม่ค่อยเก่ง T-T

ดังนั้นจะขอบันทึกเก็บลง Blog ไว้แบบย่อๆเท่าที่พอเรียงลำดับได้เผื่อตัวเอาเข้ามาอ่านทบทวนในอนาคต

 

SDLC และ Tester

  • ในลำดับของ SDLC ตามต้นฉบับเราจะเห็นว่า Test อยู่หลังการ Code ทำให้เกิดความเชื่อผิดๆว่างาน Test เป็นหน้าที่ของ Tester เท่านั้น Programmer จึงมักปัดงานด้านการทดสอบทั้งหมดไปให้ Tester และทำให้เกิดปัญหาต่างๆตามมามากมาย
  • สิ่งที่เราต้องทดสอบ แบ่งเป็น 2 ส่วน คือ Function Requirements และ Non-Function Requirements
  • Requirements ที่คลุมเครือส่งผลให้การออกแบบผิดพลาด  ตามไปด้วยการเดพผิดพลาด กว่าจะรู้ตัวว่าผิดพลาดก็ตอนทดสอบในขั้นตอนที่ 4
  • การคิด Test Case และทดสอบในขั้นตอนที่ 4 อาจเรียกได้ว่าสายเกินไป
  • จึงควรเปลี่ยนให้ Tester มาช่วยออกแบบ Test Case ตั้งแต่ขั้นตอนแรก (เมื่อได้รับ Req)
  • หาก Case ไหนคลุมเครื่อแสดงว่า Requirements ยังไม่ดีพอ ต้องไปเก็บข้อมูลเพิ่ม
  • เมื่อได้ Test Case ครอบคลุมแล้วจึงส่งเอกสารให้ Programmer เพื่อแปลงให้อยู่ในรูปแบบ Code ต่อไป
  • นี่คือแนวคิดที่แท้จริงของ TDD – Test First!

 

Test Cast มาจากไหน?

  • Test Case = Business Rule + Test Data
  • Business Rule ก็มาจาก Requirements คือ เงื่อนไขหรือความต้องการทางธุรกิจ
  • Test Data คือ ชุดข้อมูลจริงที่เป็นไปได้ในการใช้งาน สำหรับทดสอบ
  • เราสามารถเขียน Test Case ให้อยู่ในรูปแบบตารางเพื่อให้ง่ายต่อการเข้าใจและเป็นเอกสารอ้างอิงชั้นดี
  • Test Case ที่ดีช่วยให้ Programmer เขียนโปรแกรมได้ง่ายขึ้น เร็วขึ้น และบั๊กน้อยลง
  • การทดสอบควรเน้นที่ Unit Test ให้ได้มากที่สุดเพราะทำการทดสอบได้เร็วและมีโอกาสเปลี่ยนแปลงน้อย
  • การทดสอบแบบ End to End มีความเสี่ยงสูงที่จะเปลี่ยนแปลงได้ง่ายและทดสอบได้ช้ากว่ามาก

Test เท่าไรถึงจะพอ?

  • Business Rule = ลูกค้าที่สามารถทำประกันได้ต้องมีอายุระหว่าง 20 ถึง 60 ปี
  • แบ่งเป็นกี่เคส?
  • แนวคิดแบบ EP (Equivalence partitioning) บอกว่าแบ่งเป็น 3 ส่วน
  •  [ก่อน 20]  [ระหว่าง 20 ถึง 60] และ [หลัง 60] นั่นหมายถึง Test Data 3 ชุด
  • แล้วถ้าลูกค้าอายุ 20 หรือ 60 เป๊ะๆละ
  • แนวคิดแบบ BVA (Boundary value analysis) บอกว่าแบ่ง 6 ส่วน
  • [ก่อน 20] [20] [หลัง 20] [ก่อน 60] [60] และ [หลัง 60] นั่นหมายถึง Test Data 6 ชุด
  • สรุปคือต้องมี อย่างน้อย 6 Test Case นี้เพื่อครอบคลุม Business Rule ดังกล่าว
  • มีคำถามต่อ… แล้ว [หลัง 20] กับ [ก่อน 60] มัน Logic เดียวกัน ยุบรวมกันได้ไหม
  • ตอบ… ได้ แต่ถ้าลูกค้าหรือหัวหน้าเข้มงวด อาจจะต้องเสียเวลาอธิบายเพิ่มนะ
  • มีคำถามอีก… Test Case แค่นี้เพียงพอแล้วจริงหรือ
  • ตอบ… ถ้าคิดว่ายัง ก็เพิ่มไปเท่าที่เรามั่นใจ

 

ปิดท้าย

ข้อมูลในนี้เป็นแค่ส่วนเล็กๆ ถ้าคิดอัตราส่วนคงได้ประมาณ 1 ใน 20 ขององค์ความรู้ที่ได้ทั้งหมดในวันนี้

แต่ด้วยความไม่ไม่รู้จะแกะ แงะ ออกมาอธิบายยังไงให้เข้าใจง่ายๆ และที่สำคัญคือกลัวปล่อยไก่ด้วย 555+

จึงขอบันทึกไว้เพียงเท่านี้ ให้พอเป็นสะพานความคิดเพื่อย้อนกลับไปยังเรื่องอื่นๆที่เกี่ยวข้องได้

หากใครหลงเข้ามาอ่านแล้วงงตรงไหนก็ขออภัยมา ณ ที่นี้ด้วย เพราะตัวผมเองก็ยังต้องศึกษาอีกมาก

หากใครมีคำถาม…แนะนำให้ติดต่อเจ้าของคอร์สโดยตรงได้เลยนะครับ บริษัท สยามชำนาญกิจ จำกัด