Category Archives: Defect Management

เพิ่มสีสันให้กับการกำหนดความรุนแรงของ Bug

colorful-butterfly
รูปจาก http://www.jachestudio.com

กราบสวัสดีเย็นย่ำวันจันทร์ที่ 11 สิงหาคม พ.ศ. 2557 วันที่หลายๆ คนหยุดพักอยู่บ้าน ขณะที่หลายๆ คนนั่งทำงานอยู่ พอดีนั่งอ่าน tweet ไปเรื่อยๆ จนมาเจอกับ Blog ของ Tester ฝรั่งท่านหนึ่งในนามปากกาว่า TestSheepNZ จั่วหัวเรื่องว่า A new defect severity hierarchy … พอเข้าไปนั่งอ่านดู เฮ้ย!!! เขาคิดได้ไงเนี่ย ชอบๆ เลยขอหยิบมาเขียนเป็นภาษาไทย สำหรับคนที่อยากอ่านต้นฉบับก็ Click ที่ นามปากกา หรือ ที่หัวเรื่องด้านบนได้เลยนะจ๊ะ

พออ่าน Blog นี้ A new defect severity hierachy แล้วก็ทำให้หยุดคิดว่า เออ…เวลาอธิบายถึงเรื่องระดับความรุนแรงของ Defect ผมก็มักจะยกตัวอย่างโดยอ้างอิงถึงการทำงานที่ผิดพลาดของ Software เสมอๆ แต่ถ้าไม่ใช่คนแบบ IT จ๋า จ๋า จ๋า และจ๋า เลยล่ะ จะอธิบายยังไง?

Continue reading เพิ่มสีสันให้กับการกำหนดความรุนแรงของ Bug

เมื่อไรควรใช้ และไม่ควรใช้ Defect Tracking System

เมื่อหลายๆๆๆ ปีก่อนสมัยยังละอ่อน นั่งทดสอบงาน และเขียน Defect ที่พบลงไปในระบบ Defect Tracking System (DTS) หรือ Bug Tracking ก็แล้วแต่สะดวกจะเรียกกัน ผมใช้เวลาพอสมควรในการเขียน Defect แต่ละตัวที่พบลงใน DTS ซึ่งกว่าจะจบได้แต่ละตัวก็นะ ใช้เวลาพอสมควร จนหลายๆ ครั้งมีการนั่งคุยในทีมว่า ทำไมเราจะต้องนั่งเขียน Defect เก็บไว้? ซึ่งคำถามนี้ได้หายไปจากแกนสมองนานพอสมควรจนกระทั่งมาอ่านหนังสือ Agile Testing: A Practical Guide for Testers and Agile Teams ของ Lisa Crispin และ Janet Gregory มาสะดุดกับตอนหนึ่งของหนังสือนี้

agile-testing-dts

ซึ่งทำให้ผมได้รับรู้ว่า เฮ้ย!!! นี่มันข้อสงสัยระดับโลกเลยนี่!!! 🙂 ก็เลยมานั่งจรดปลายนิ้วลงบนแป้นพิมพ์เพื่อเขียน Blog วันนี้โดยจะผสมผสานกันระหว่างหนังสือ Agile Testing และประสบการณ์ของตัวเอง

Continue reading เมื่อไรควรใช้ และไม่ควรใช้ Defect Tracking System

อยากถามพี่หนุ่มเกี่ยวกับเรื่อง Severity ของ Bug นะครับ?

Severity and Priority differences

มีคำถามมาจากน้องจากเชียงใหม่ครับส่งมาทาง email ใจความดังนี้
รบกวนพี่หนุ่มเกี่ยวกับเรื่อง Severity ของ Bug นะครับ

เกริ่นก่อนนะครับ ตอนนี้ผมกำลังศึกษาในส่วนการประเมินคะแนนของTCที่ใช้ในเกมครับ
คือ อยากให้ TC ที่ป้อนไปในแต่ละครั้งมีคะแนนด้วย
ผมไม่รู้ว่าจะใช้วิธีไหน เลยมาสะดุดที่ Severity และ Priority

เลยอยากขอคำปรึกษาพี่หนุ่มครับว่า..
1.ระดับSeverity ของแต่ละ Req ใครเป็นคนกำหนดครับ มีวิธีกำหนดอย่างไรหรอครับ
2.เรื่องนี้สามารถนำมาเป็นวัดประสิทธิภาพของ Test case ได้หรือเเปล่าครับ
ตัวอย่างเช่น
Test case ครั้งที่1 สามารถพบ Bug ที่มี Severity สูง
Test case ครั้งที่2 สามารถพบ Bug ที่มี Severity ต่ำ
เราจะนำมาสรุปได้หรือเปล่าครับว่า TC1 ประสิทธิภาพมากกว่า TC2
3.Severity และ Priority มันต่างกันอย่างไรหรอครับ พี่พบจะมีแหล่งศึกษาเกี่ยวกับเรื่องพวกนี้บ้างหรือเปล่าครับ (ไว้ใช้เป็นแหล่งอ้างอิงในงาน)
ขอบคุณมากครับ

Defect Management Video on BugDay Bangkok 2009 (Part 3/3)

VDO บันทึกการแบ่งปันความรู้เรื่อง Defect Management งาน BugDay Bangkok 2009 ที่จัดขึ้นไปเมื่อวันเสาร์ที่ 19 ธันวาคม พ.ศ. 2552 ณ มหาวิทยาลัยศรีปทุม ตอนที่ 3 (จบ)

Defect Management Video Part 3

BugDay Bangkok 2009: Defect Management 3/3 from Prathan D. on Vimeo.

ร่วมแบ่งปันโดย อาจารย์ เมสินี นาคมณี
บันทึก vdo โดย  @zKanCS

Defect Management Video on BugDay Bangkok 2009 (Part 2/3)

VDO บันทึกการแบ่งปันความรู้เรื่อง Defect Management งาน BugDay Bangkok 2009 ที่จัดขึ้นไปเมื่อวันเสาร์ที่ 19 ธันวาคม พ.ศ. 2552 ณ มหาวิทยาลัยศรีปทุม ตอนที่ 2

Defect Management Video Part 2

BugDay Bangkok 2009: Defect Management 2/3 from Prathan D. on Vimeo.

ร่วมแบ่งปันโดย อาจารย์ เมสินี นาคมณี
บันทึก vdo โดย  @zKanCS

Defect Management Video on BugDay Bangkok 2009 (Part 1/3)

VDO บันทึกการแบ่งปันความรู้เรื่อง Defect Management งาน BugDay Bangkok 2009 ที่จัดขึ้นไปเมื่อวันเสาร์ที่ 19 ธันวาคม พ.ศ. 2552 ณ มหาวิทยาลัยศรีปทุม ตอนที่ 1

Defect Management Video Part 1

BugDay Bangkok 2009: Defect Management 1/3 from Prathan D. on Vimeo.

ร่วมแบ่งปันโดย อาจารย์ เมสินี นาคมณี
บันทึก vdo โดย  @zKanCS

Defect Management Presentation on BugDay Bangkok 2009

ครบ 1 เดือนพอดิบพอดีสำหรับงาน BugDay Bangkok 2009 ที่จัดขึ้นไปเมื่อวันเสาร์ที่ 19 ธันวาคม พ.ศ. 2552 ณ มหาวิทยาลัยศรีปทุม หลังจากได้รวบรวม Presentation จากผู้ร่วมแบ่งปันในเรื่องต่างๆ รวมทั้งไฟล์ VDO ที่เพื่อนพ้องน้องพี่ที่มาร่วมงานได้ถ่ายเก็บไว้ มาเกือบครบ ก็ได้เวลาปล่อยของแล้วครับ 🙂  วันนี้ขอประเดิมด้วยเรื่อง Defect Management

Defect Management Presentation

Defect Management on BugDay Bangkok 2009View more documents from Prathan D..ร่วมแบ่งปันโดย อาจารย์ เมสินี นาคมณี

2 Open Source Bug Tracking Systems ของฉัน ตอนที่ 1

Bug หรือ Defect หรือ Issue เป็นคำที่คุ้นเคยกับเหล่า Software Tester และ Software Developer ทั้งหลาย เหมือนเป็นเนื้อคู่ ทำบุญร่วมกันมาตั้งแต่ชาติปางก่อน 😛 ผู้เขียนเองก็ประสบพบเจอกับ Bug/Defect/Issue มาตั้งแต่สมัยเป็น Developer จนกระทั่งมาทำงานเป็น Tester ตลอดระยะเวลาเกือบ 4 ปีในชีวิตการทำงานเป็น Tester ก็เริ่มการบันทึก Bug ที่พบลงใน Microsoft Word แล้วขยับมาเป็น Microsoft Excel จนกระทั่งได้รู้จักกับ Bug Tracking System ชีวิตก็ดีขึ้นในบัดดล 🙂

a Bug Tracking System is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. คำจำกัดความของ Bug Tracking System จาก Wikipedia, the free encyclopedia

Bug Tracking System ในท้องตลาดมีให้เลือกใช้อย่างมากมายหลายเจ้า ทั้งแบบเสียเงิน และแบบ Open Source ผู้เขียนเองเป็นคนที่ฝักใฝ่ในฝั่งของ Open Source จึงได้เสาะแสวงหา Bug Tracking System มาเพื่อใช้งาน และได้พบปะกับ 2 Bug Tracking Systems ในระยะเวลาเกือบ 4 ปีในการทำงานเป็น Tester คือ

Continue reading 2 Open Source Bug Tracking Systems ของฉัน ตอนที่ 1

[Forum] มักจะได้คำตอบจาก Developer ว่า Out of Scopes ทำไงดีค่ะ!!!

สวัสดียามค่ำคืนวันจันทร์ที่ฝนตกโปรยปรายครับ อากาศเย็นสบาย แต่ก็ระมัดระวังที่จะไม่สบายกันด้วยนะครับ เข้าเรื่องเลยละกันนะครับ ได้มีเพื่อนพ้องน้องพี่ของเราได้ไปถามไว้ที่ Software Testing Forum ไว้ ดังนี้ครับ

ตอนนี้กำลังสับสนว่า เวลา Log Issue ไป มักจะได้คำตอบจาก Developer ว่า Out of Scopes.

ในมุมมอง QA ที่ถ้าเจอ Issue ก็จะ Log เพราะ Concern ในเรื่อง Quality
แต่ ในมุมมอง Developer หรือ Project Team ถ้าเรื่องที่เจออยู่นอกเหนือ Scopes งานที่ต้องแก้ไข ในโปรเจคที่มีเรื่อง Budget และ เวลาเป็นเงื่อนไข ที่เขาต้องใช้ไปในการ Investigate งานที่นอกเหนือ Scopes

เราจะมีวิธีการจัดการกับปัญหานี้อย่างไรดี รบกวนช่วยแนะนำด้วยคะ

ยกตัวอย่างเคส เช่น ลูกค้าทำการ Upgrade ระบบจาก Version 1.0 เป็น 2.0

ปัญหาหนึ่ง
Tester แจ้ง Bug ที่ Developer ตรวจสอบแล้วพบว่าเป็น Bug ที่เกิดจาก Core Product ไม่ได้เกิดจากการ Customization ซึ่งนโยบายของบริษัทจะไม่ทำการแก้ไข Bug ที่เกิดจาก Core Product

เนื่องด้วยเวลาที่จำกัด ทำให้ Tester ไม่สามารถพิสูจน์ว่า Issue ที่เจอเป็น Issue จาก Core Product หรือไม่
Developer ก็ต้องเสียเวลาในการพิสูจน์ Issue ที่หากเป็น Issue ที่เกิดจาก Core Product ก็จะไม่ Fix ซึ่ง 60% ของ Issue ที่ทำการรายงาน เกิดจาก Core Product ทั้งนั้น

เราจะมีวิธีการอย่างไรที่จะทำให้ Tester สามารถเรียนรู้ว่า Issue ที่เจอ เกิดจาก Core Product ของแต่ละเวอร์ชั่น ซึ่งแน่นอนว่าจะมีการรายงาน Bug ใหม่ๆ อยู่เสมอ

ปัญหาสอง
ด้วย เวลาที่จำกัด Tester จึงถูกจำกัดให้เน้นเทสในส่วนที่เป็น Customization แทนที่จะทำการทดสอบระบบโดยรวม เช่นนี้แล้วเราจะรับประกันคุณภาพของ Software นี้ได้อย่างไร

เลยหยิบยกมาให้เพื่อนพ้องน้องพี่ของเราได้ร่วมด้วยช่วยกันแสดงความคิดเห็น และคำแนะนำดีๆ ครับ 🙂

ที่มา: http://forum.sanook.com/forum/2848317_Out_of_Scopes.html

Testing and Recording Defect with Video Clip

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

computer bug

photo by Blacknight Solution

ค่ำคืนนี้ก็ขอเล่าสู่กันฟังถึงประสบการณ์ในส่วนของ Defect Management ที่เคยผ่านมาในการทำ Software Testing ซึ่ง Tester หลายๆ ท่านอาจจะประสบปัญหาอยู่ ณ ตอนนี้ และในเวลาเดียวกัน Tester หลายๆ ท่านก็น่าจะใช้วิธีการเดียวกันกับที่ผู้เขียนใช้ด้วยเช่นกัน

Defect หรือ Bug เหมือนเป็นเพื่อนสนิทมิตรสหายกับ Tester ทั้งหลาย ที่จะต้องประสบพบเจอกันอยู่ในทุกๆ ครั้งที่ลงไม้ลงมือทดสอบ Software หรือ Application ต่างๆ  ซึ่งเมื่อเราได้เจอะเจอกับเจ้า Defect หรือ Bug ในระหว่างดำเนินการ Test เราก็จะทำการ Log รายละเอียดของ Defect ที่พบลงในระบบ Defect Management ที่แต่ละ Tester นั้นใช้งาน โดย Tester ก็จะบอกรายละเอียดต่างๆ ที่เกี่ยวข้องกับ Defect นั้นๆ ซึ่งโดยทั่วๆ ไป Tester ทั้งหลาย ก็จะแจ้งรายละเอียดเบื้องต้น ดังนี้
[ad#adsense-468×60]
Continue reading Testing and Recording Defect with Video Clip

My Defect Management ตอนที่ 2 Defect Writing Guideline

สวัสดีค่ะ พี่น้องชาว WeLoveBug ทุกท่าน ก่อนอื่นขอขอบคุณผู้ที่สนใจเข้ามาอ่าน และให้ความรู้เพิ่มเติมในตอนที่ 1 ในส่วนของ Defect type และ defect response turnaround time ซึ่ง 2 ส่วนนี้น่าสนใจมากค่ะ

ขอเข้าเรื่องเลยละกัน ผู้เขียนขอเล่าเพิ่มในส่วนของ Tool นิดค่ะ ว่า Mantis เป็น Tool ที่ทาง Test Team จัดการเองซึ่ง เมื่อมีโปรเจ็คที่ส่งเข้ามา Test ทางทีมจะมีขั้นตอนการทำงานในส่วนของการจัดการ Mantis ดังนี้ค่ะ

defect-writing-guideline

  1. สร้าง Project ที่ส่งเข้ามา Test ใน Mantis และสร้าง Category  เพื่อแบ่ง function การทำงานออกเป็นส่วนๆ
  2. สร้าง Account ให้กับทางทีม Developer หรือทีมที่จะต้องการใช้ Tool ตัวนี้ในการ log defect
  3. เมื่อเข้าสู่ช่วง Test Execution หรือ System Testing ก็จะถึงขั้นตอนการเขียน Report เพื่อแจ้ง defect ที่พบให้ทาง Developer ทราบ และระบุวิธีการทดสอบว่ามีวิธีการทดสอบอย่างไร เพื่อให้ทาง Developer เข้าใจ และรู้สาเหตุของปัญหา ทำให้สามารถแก้ไขระบบได้ตรงจุด โดยมีวิธีการกรอกรายละเอียดของปัญหาที่พบ ดังนี้

[ad#adsense-468×60]

Continue reading My Defect Management ตอนที่ 2 Defect Writing Guideline