My Defect Management ตอนที่1 Overview

สวัดดีค่ะ สำหรับตอน My Defect Management ที่เขียนเรื่องนี่ เนื่องจากมีโอกาศได้รับมอบหมายให้เขียนลง Wiki ของทีมเลยอยากเอาแชให้พี่น้องชาว WeLoveBug ดูค่ะ แต่จะเขียนเป็น My Defect Management นะค่ะ เนื่องจากแต่ละองค์กร อาจมีวิธีการจัดการกับ Defect ที่พบต่างกันและใช้ตัวช่วยที่ต่างกัน ค่ะ

Defect Management คือ การจัดการ Defect ที่พบในช่วงของ Phase Testing โดย Tool ที่ผู้เขียนใช้คือ Mantis การนำ Tool เข้ามาใช้ใน Project นั้นๆ เพื่อใช้ Report Defect ที่พบเพื่อแจ้งทีมที่เกียวข้อง และเพื่อใช้ข้อมูลสรุปปัญหาของโปรเจ็คนั้นๆ ว่าจะสามารถ Launch ได้ตาม Plan หรือไม่

Defect คือ ปัญหาที่พบในการทดสอบระบบ ซึ่งปัญหาเหล่านี้อาจกระทบต่อ Function การทำงานของระบบ เช่น ระบบแสดง Error ต่างๆ หรือ Defect ที่พบอาจจะไม่กระทบกับ Function การทำงาน เช่น การแสดงผลที่อาจเกิดจาก Design หรือ การแสดงผลของข้อความ ซึ่งปัญหาเหล่านี้จะไม่ส่งผลกระทบกับระบบ

Defect Life Cycle คือ วงจรการทำงานของ Defect ที่เริ่มตั้งแต่เมื่อพบ Defect แล้ว Assign ให้ทางทีม Developer แก้ไข จนกระทั่ง Developer แก้ไขเสร็จ ซึ่งมีรายละเอียด ดังนี้

[ad#adsense-468x60]

Defect Status เป็นการบอกถึงสถานะของ Defect ที่พบ Status ที่ใช้ปัจจุบันจะมีอยู่ 5 status ดังนี้

• Assign : เมื่อพบ defect จะ Assign ไปให้ทาง Team Develop ที่รับผิดชอบ
• Resolve : เมื่อ Developer แก้ไข Defect ที่พบ และ upload Code ขึ้น Test Environment
• Feedback : ไม่แก้ไข Defect ที่พบเนื่องจากสาเหตุใดๆ
• Acknownledged : การแก้ไขโปรเจ็ค ต้องรอข้อสรุป หรือ solution จากผู้ที่เกี่ยวข้องกับโปรเจ็ค
• Closed : Defect ได้รับการแก้ไขถูกต้อง

Defect Type เป็นการแบ่งประเภทของ Defect ที่พบ ว่าเกิดจากส่วนใดในการทำงาน สามารถแบ่งออกได้เป็น 6 ประเภท

• Requirement : เป็น Defect ที่เกิดจากการแก้ไข Requirement ของทาง Business โดยไม่แจ้งทีมที่เกี่ยวข้อง ( Design,Developer,Tester )
• Coding : เป็น Defect ที่เกิดจากการ Coding ของทาง Developer ที่ไม่ตรวจสอบในส่วนนั้นๆ
• Graphic Design : เป็น Defect ที่เกิดจากการ Design ที่ไม่ลองรับกับ Browser ต่างๆ หรือ เมื่อ developer นำ Design มาประกอบกับ Code แล้วทำให้การแสดงผลไม่ถูกต้อง
• Tester : เป็น Defect ที่เกิดจากความเข้าใจผิด หรือเกิดจากความผิดพลาดของ Tester
• Data Test : เป็น Defect ที่เกิดจาก Test data อาจไม่มีใน Environment หรือระบบอาจไม่ Support data ส่วนนี่
• Other : ข้อจำกัดของระบบ, ข้อจำกัดของ Environment

Defect Severity เป็นการระบุความรุนแรงของ Defect ที่พบใน Test Phase โดยยึดตาม Standard Severity Code แบ่งออกเป็น 4 ระดับ ดังนี้

• Critical : Defect ที่ไม่สามารถทดสอบโปรแกรมในส่วนของ Function นั้นต่อได้เลย
• High : Defect ที่เกิดจากการใส่ข้อมูลถูกต้อง แต่ระบบแสดงผลผิดพลาด เช่น Error ต่างๆ
• Medium : ระบบจะแสดงผลถูกต้องเมื่อใส่ข้อมูลถูกต้อง แต่เมื่อใส่ข้อมูลไม่ถูกต้อง ระบบจะแสดงผลผิดพลาด เช่น Filed ที่มีการ Validate ผล เมื่อใส่ ค่าว่าง,อักขระพิเศษ ( ‘,”,%,& ) และ Script ที่มีผลต่อการแสดงผลของระบบ ๆ จะแสดงผลผิดพลาด
• Low : Defect ที่เกิดจากการแสดงผลของข้อความ หรือ เรื่องของการ Design ซึ่ง Defect เหล่านี้จะไม่มีผลกระทบกับการทำงานของระบบ

Defect Tracking สำหรับ Tool ที่ใช้เป็นตัวช่วยในการจัดการกับ Defect ที่พบ คือ Mantis ใช้ในการ log Defect ที่พบ เพื่อแจ้งทีมที่เกียวข้องให้เข้าไปดูรายละเอียดของ Defect และแก้ไขในส่วนที่รับผิดชอบ ข้อมูล Defect เหล่านี้จะใช้ในการสรุปปัญหาของระบบว่าจะสามารถ Launch ได้ตาม Plan หรือไม่

รายละเอียดการ Report Defect ที่พบขอยกไปเขียนในตอนหน้า นะค่ะ
[ad#adsense-468x60]