Tag Archives: bug

ฆ่า Bug หนึ่งตัวต้องใช้เงินกี่บาท?

how-much-to-pay-to-kill-bug

สวัสดีเช้าวันพุธที่ 23 กันยายน พ.ศ. 2558 เช้าวันนี้ขอมาพล่ามเรื่องของ สิ่งเล็กๆ ที่เรียกว่า Bug กันหน่อย อันสืบเนื่องจากว่าช่วงที่ผ่านมาหนูเริ่มขายแนวคิด การทำงานเชิงป้องกันไม่ให้เกิด Bug มากกว่า การทำงานแบบตั้งรับ Bug และก็ได้เจอกับคำถามว่า “เราต้องใช้คนมากขึ้น ใช้เงินมากขึ้น ใช่ไหม?” และ แลดูแพงกว่าการทำงานแบบตั้งรับ Bug

เช้าวันนี้ก็เลยมานั่งพล่ามนิดนึงละกันเกี่ยวกับเรื่องนี้ว่าจริงๆ แล้วการทำงานแบบเชิงป้องกันไม่ให้เกิด Bug นั้น แพงกว่า การทำงานแบบตั้งรับ Bug จริงๆ หรือเปล่า

คำออกตัวก่อนเริ่มพล่าม: ทั้งหมดที่หนูจะพล่ามให้เพื่อนพ้องน้องพี่ได้เสพ มาจากประสบการณ์ของตัวหนูเองนะจ๊ะ

Continue reading ฆ่า Bug หนึ่งตัวต้องใช้เงินกี่บาท?

เพิ่มสีสันให้กับการกำหนดความรุนแรงของ 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

You can’t stop the waves, but you can learn how to surf

waves-surf

กราบสวัสดีบ่ายวันอังคารที่ 3 กันยายน พ.ศ. 2556  (-/\-) สืบเนื่องจากเช้าวันนี้เจอภาพนี้บน Timeline ของเพื่อนใน Facebook ผมนั่งมองนิ่งๆ อยู่ 10 วินาที พร้อมกับมีรอยยิ้มบนใบหน้าปลวกๆ ของตัวเอง 555 พร้อมกับ Post ขึ้นไปทั้ง Timeline ของตัวเอง Facebook Group WeLoveBug และ FanPage WeLoveBug (เข้าขั้นบ้า) ดูจากรูปภาพแล้วน่าจะเป็นหน้าบริษัทอะไรสักอย่าง แต่ข้อความบนกระจกมันโดนใจผม 10 วินาทีที่มองอย่างนิ่งๆ ทุกๆ เหตุการณ์ที่เกิดขึ้นระหว่างทางของการตั้งทีม Test กระบวนการการทดสอบ (Test Process) รวมทั้งทั้งผลักทั้งดันให้เรื่องของคุณภาพ (Quality) เกิดขึ้นในองค์กรที่ผมเองเคยอยู่ มันวิ่งกลับเข้ามาในสมองทันทีกับประโยค “You can’t stop the waves, but you can learn how to surf

Continue reading You can’t stop the waves, but you can learn how to surf

A Little Bug Problem

สวัสดีบ่ายแก่แก่ วันอาทิตย์ที่ 12 กันยายน 2553 ครับเพื่อนพ้องน้องพี่ ห่างหายไปนานพอสมควรเลยที่ไม่ได้มาแบ่งปันความรู้บน Welovebug มิได้หายไปไหนนะครับ อยากจะมาแบ่งปันใจจะขาด แต่เนื่องด้วยภาระหน้าที่การงานใหม่ ช่างรุมเร้า เสียกระไร ( ข้ออ้างแน่ๆ ) จริงๆ แล้วมีหลายเรื่องที่อยากจะมาแบ่งปันให้กับเพื่อนพ้องน้องพี่รวมทั้ง รอการแบ่งปันจากเพื่อนพ้องน้องพี่ด้วยเช่นกันครับ

บ่ายแก่ๆ วันนี้นั่งอ่าน blog ไปเรื่อยๆ จนไปเจอการ์ตูนที่เกี่ยวกับ Bug เลยหยิบมาฝากเพื่อนพ้องน้องพี่ดูกันขำๆ ครับ

A Little Bug Problem

ที่มา: http://www.webdesignerdepot.com/2010/09/comics-of-the-week-42/

24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

สวัสดียามสายวันอังคารที่สองของเดือนกันยายนนะครับ เผลอนิดเดียวก็เกือบจะสิ้นปี 2552 อีกแล้ว เวลาเดินทางไวจริงๆ เลยนะครับนี่ ห่้างหายไปนานเลยที่ไม่ได้เขียนเรื่องลงบน welovebug วันนี้ก็เลยเข้ามาเขียนเรื่องลงซะหน่อยดีกว่า เก็บๆ ข้อมูลไว้เยอะเลย แต่ต้อง build อารมรณ์ตัวเองให้ได้ถึงจะเขียนได้ครับ

bug1

หลังจากที่เคยได้นำเสนอเรื่องขำๆ แอบเสียดสี Developer และ Programmer ไป กับเรื่อง คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug และต่อยอดคัด 10 คำตอบเด็ดๆ ไป นำเสนอในงาน Barcamp Bangkok ครั้งที่ 3 โดยใช้ชื่อ Session ที่ไปพูดในวันนั้นว่า Top 10 programmer’s answer when tester find bugs วันนี้กลับมาอีกครั้งด้วยบทความหยิกแกมหยอก สำหรับเหล่า Developer และ Programmer อีกครั้ง กับ 24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

ที่มาที่ไป ผู้เขียนได้ทำการค้นหาบน Google เพื่อจะหาชื่องานกิจกรรมพบปะพูดคุยของเหล่า Tester และผู้ที่เกี่ยวข้องกับเรื่องของ Software Testing ก็บังเอิญไปเจอบทความหนึ่งเข้า ด้วยคำค้นว่า Tester Day พอเข้าไปอ่าน อ้าว…ไม่ใช่ แต่ดันเขียนชื่อเรื่องว่า tester’s day! ซะงั้น แต่ในบทความเป็นเรื่องของ Top 24 replies by programmers when their programs don’t work

ผู้เขียนก็เลยหยิบมานำเสนอแก่เหล่าเพื่อนพ้องน้องพี่ไม่ว่าจะเป็น Tester หรือ Programmer หรือ Developer หรือ ผู้ที่สนใจ ได้อ่านกันแบบ ขำ ขำ ครับ 🙂
Continue reading 24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา

[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

We Love Bug in Barcamp Bangkok 2009

วันเสาร์ที่ 23 พฤษภาคม 2552 ผู้เขียนได้มีโอกาสไปร่วมงาน Barcamp Bangkok ครั้งที่ 3 โดยปีนี้จัดงานที่ มหาวิทยาลัยศรีปทุม ครับ ต้องขอโทษที่ไม่ได้มาเขียนเรื่องลงใน welovebug เกี่ยวกับงานนี้ครับ เดินทางไปถึง Barcamp Bangkok 3 ตอนเวลาประมาณเกือบๆ 8:00 น. ก็เจอเพื่อนๆ ที่รู้จักกันใน Twitter อยู่หลายๆ คน

img_0081

ไหน ไหน ก็ไปร่วมงาน barcampbangkok แล้วก็เลยเตรียมเรื่อง และ Presentation ไปร่วมงานนี้ด้วยเช่นกัน ก็เลยนั่งคิดไปคิดมาว่าจะพูดเรื่องอะไรดี กลับมาเปิดดูบทความต่างๆ บน welovebug ก็เจออยู่ 3 เรื่องที่น่าจะนำไปพูด

หลังจากนั่งพิจารณาดูรายชื่อของผู้เข้าร่วมงานส่วนใหญ่เป็น Developer หรือ Programmer แน่ๆ เลย ซึ่งจากหัวข้อทั้ง 3 เข้าข่ายอาจจะโดนยำได้ทั้งสิ้น ^ ^!

Continue reading We Love Bug in Barcamp Bangkok 2009

ทำยังไงดี Bug โดน Reject อีกแล้ว

สวัสดีครับ หลังจากที่คราวที่แล้วเล่าเรื่อง Test Efficiency & Effectiveness ให้ฟังกันไปแล้ว คราวนี้มาลองคุยกันเรื่องเบาๆ (แต่อาจจะเป็นเรื่องที่ทำให้หลายๆคนเกิดอาการเซ็งกันได้บ่อยๆ) กันหน่อยดีกว่าครับ

คำพูดที่หลายๆคนคุ้นหู

“ตัวนี้มันไม่ใช่ Bug นะครับคุณTester นี่มัน Expect Behavior มันต้องเป็นอย่างนี้แหล่ะ เชื่อผมๆ”

มีใครเคยได้ยินประโยคคลาสสิคแนวๆนี้มั่งมั๊ยครับ แล้วลองคิดดูนะครับ ว่าที่ผ่านมาเรามี reaction อย่างไรกับคำพูดนี้ เท่าที่ผมเคยเห็น หรือเคยได้ฟังคนมาบ่นบ่อยๆ ก็จะมีสองกรณีหลักๆ

1. “เอ่อออ เหรอ จริงเหรอ มันต้องเป็นอย่างนี้จริงๆเหรอ… อ่า แต่มันดูแปลกๆนะ อ่า…. เหรอ ไม่ใช่จริงๆ หรอ… อืมๆๆ ไม่ใช่ก็ได้แหล่ะมั้ง เดี๋ยวไป reject ให้ละกันนะ”

หรือแบบที่สอง (หลังจากที่โดน Reject มาสิบตัว อารมณ์กำลังคุกรุ่น อาจจะเป็นแบบนี้)

2. “อะไรนะ ไม่ใช่อีกแล้วเหรอ ทำไม Report มาสิบตัว มันไม่ใช่ Bug หมดเลยเนี่ย มั่วป่าว ทำไมไม่ยอมรับอะไรเลยเนี่ย….(ตูม ตาม ตูม ตาม)

คือ สรุปว่า ถ้าไม่ยอมให้ Reject (แบบไม่เต็มใจ) ก้อจะออกแนว หงุดหงิด โมโห น้อยใจในโชคชะตากันไปเลย หรือถ้าแย่กว่านั้นคือ ต่อไป Tester คนนั้นก็จะเลิก Record Bug ที่เจอ หรือไม่ก็เวลาเจออะไรที่คิดว่าเป็น Bug ก็จะวิ่งไปถาม Developer ก่อน แล้วก้อจะโดนบอกมาว่าไม่ใช่ Bug แล้วก้อจะปล่อยมันผ่านไปไม่ Record อะไรใดๆทั้งสิ้น

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

Continue reading ทำยังไงดี Bug โดน Reject อีกแล้ว

The First Computer Bug

สวัสดียามค่ำ สำหรับวันที่ฝนตกลงมาเหมือนฟ้ารั่ว ขณะที่นั่งเขียนเรื่องนี้ก็เวลาประมาณ 18:35 น. จบสิ้นภารกิจการงานประจำวันไป แต่ก็นั่งรอเวลาสัมภาษณ์ผู้สมัครเข้ามาตำแหน่ง Tester ของที่ทำงาน ไม่รู้ว่าจะติดฝนอยู่แถวไหน

ระหว่างที่นั่งรอก็เลยนั่งค้นหาความหมายของคำว่า Error, Fail และ Failure เพื่อจะเอามาเขียนบทความซะหน่อย แต่ หาไป หามา กลับไปเจอเรื่องของ The First Computer Bug เข้า อ่านดูแล้วก็น่าสนใจดี

เลยหยิบยกเรื่องนี้มาเขียนให้เหล่า Tester ทั้งหลาย ที่มีชีวิตผูกพันอยู่กับเจ้าแมลงน้อย หรือ Bug ได้รู้ว่าที่มาของคำว่า Bug ที่เราๆ ท่านๆ ในแวดวง IT และ Computer พูดติดปากกันอยู่ตลอดเวลา ไม่ว่าจะเจอปัญหาการใช้งาน Hardware หรือ Software เราก็จะบอกกันว่ามันมี Bug

ลองมาดูกันหน่อยว่า Bug นี้ มันถูกพบครั้งแรก เมื่อไรบนโลกใบนี้…

Log Book With Computer Bug

Continue reading The First Computer Bug

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

– การพัฒนาระบบอย่างต่อเนื่องเพื่อไล่ตาม requirement

จุดประสงค์ของ software ที่ใช้ในธุรกิจส่วนใหญ่ ทำออกมาเพื่อตอบรับความต้องการของธุรกิจหลักขององค์กรที่ใช้ระบบนั้นๆ เพื่อให้ธุรกิจเป็นไปอย่างแข่งขัน (low cost + high efficiency) กลยุทธ์ของธุรกิจจึงมีการเปลี่ยนแปลงตลอดเวลา ส่งผลให้ระบบ software requirement ต่างๆจำเป็นจะต้องมีการปรับเปลี่ยนอยู่บ่อยๆ หากแต่การปรับเปลี่ยนโครงสร้างของระบบให้สอดคล้องกับความเปลี่ยนแปลงที่เกิดขึ้นเรื่อยๆนั้น นับมีความท้าทายอยู่อย่างมาก โดยเฉพาะอย่างยิ่ง เมื่อเวลาผ่านไปจนบุคคลกรที่พัฒนา software เกิดการหมุนเวียน บางคนถูกย้ายไปทำงาน project อื่น บางคนลาออกจากบริษัท หรือบริษัท/ตัว product ถูกซื้อไป การรับช่วงต่อเปลี่ยนมือคนทำ software ที่ไม่ได้มีการดำเนินการที่ดี โดยเฉพาะเอกสารที่ไม่ครบถ้วนหรือ update ก็เป็นการเปิดโอกาสที่ทำให้เกิดbug ได้เช่นเดียวกัน

– การ test ทุกอย่างที่เป็นไปไม่ได้
ลองนึกถึง web application ตัวนึงที่มี 5 use case แต่ละ use case มี 20 test cases เท่ากับว่าเรามีทั้งหมด 100 test cases หากในตลาดมี browser เป็น ie, firefox, safari ก็คูณไปอีก 3 = 300 แต่ว่าแต่ละ browser ก็ยังมีการ settings/addon (javascript, flash, security options) ต่างๆกัน และมี major/minor version ก็ทวีคูณกันขึ้นไปอีก (นี่ยังไม่รวม version ของ OS, screen resolution และลำัดับการกรอกข้อมุลและอื่นๆ) การ test ทุกอย่างในทุก environment จึงเป็นไปไม่ได้ที่จะทำให้เกิดขึ้นใน timelineของprojectและคุ้มค่ากับต้นทุนการ testได้ ดังนั้นการออกแบบกลยุทธ์ในการ test (test strategy)ที่ทำให้เกิด Smart Testing โดยไม่testทุกอย่างแต่ยังได้ testสิ่งที่ควรจะถูกtest และให้ได้coverage ที่ดีที่สุดจึงเป็นหัวใจสำคัญและเป็นความท้าทายที่ถูกถกเถียงกันในวงการ testing มานาน อย่างไรก็ตาม แม้ว่า test strategy จะถูกคัดสรรค์มาดีแค่ไหน การที่ไม่ได้ test ทุกอย่างและเว้นไปในแค่รายละเอียดย่อยเล็กน้อยล้วนก็เป็นการเปิดช่องให้มีโอกาสให้มี software bug เกิดขึ้นได้ หากแต่ว่าผลกระทบของการมี bug เหล่านั้นน่าจะส่งผลที่น้อยที่สุดต่อผู้ใช้และธุรกิจของผู้ใช้ระบบนั่นเอง พบกับการบรรยายหลากหลายมุม เรื่อง Smart Testing ได้ในงาน SPIN Day เดือน พ.ค นี้ครับ

Continue reading จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)

ผมขอเริ่มต้นการจุดประกายครั้งแรก ด้วยหัวข้อ “ทำไม Softwareต้องมี bug” ด้วยเหตุผลสองประการครับ

หนึ่งการมีตัวตนของ software bug เป็นต้นกำเนิดของอาชีพ software tester (สงสัยนี่ก็อาจเป็นส่วนนึงที่ทำให้ชื่อ webนี้เป็น welovebug กระมังครับ 555)

สอง เคยมีคน(นอกวงการ IT)ถามผมว่า ทำไมคนในวงการ ITก็มีแต่เก่งๆทั้งนั้น projectแต่ละอันก็ราคาหลายแสนหลายล้านแต่ก็ยังทำระบบที่ไม่มีbugออกมากันไม่ได้ แม้กระทั่งบริษัทชื่อดังและรวยที่สุดอย่าง Microsoftก็ตาม (ตอนโดนถามก็จุกใช่เล่นครับ)

ก่อนที่จะไปไล่ดูสาเหตุของ software bug/defect กัน เรามาลองทำความเข้าใจให้ตรงกันก่อนดีมั๊ยครับ ว่า bug คืออะไรผมได้ไปรวบรวมมาจาก 3 แหล่งซึ่งความหมายค่อนข้างใกล้เคียงกันครับ

Continue reading จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)