Posts tagged bug
24 คำตอบสุดฮิตของ Programmer เมื่อ Software มีปัญหา
Sep 8th
สวัสดียามสายวันอังคารที่สองของเดือนกันยายนนะครับ เผลอนิดเดียวก็เกือบจะสิ้นปี 2552 อีกแล้ว เวลาเดินทางไวจริงๆ เลยนะครับนี่ ห่้างหายไปนานเลยที่ไม่ได้เขียนเรื่องลงบน welovebug วันนี้ก็เลยเข้ามาเขียนเรื่องลงซะหน่อยดีกว่า เก็บๆ ข้อมูลไว้เยอะเลย แต่ต้อง build อารมรณ์ตัวเองให้ได้ถึงจะเขียนได้ครับ
หลังจากที่เคยได้นำเสนอเรื่องขำๆ แอบเสียดสี 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 หรือ ผู้ที่สนใจ ได้อ่านกันแบบ ขำ ขำ ครับ 
More >
[Forum] มักจะได้คำตอบจาก Developer ว่า Out of Scopes ทำไงดีค่ะ!!!
Jun 29th
สวัสดียามค่ำคืนวันจันทร์ที่ฝนตกโปรยปรายครับ อากาศเย็นสบาย แต่ก็ระมัดระวังที่จะไม่สบายกันด้วยนะครับ เข้าเรื่องเลยละกันนะครับ ได้มีเพื่อนพ้องน้องพี่ของเราได้ไปถามไว้ที่ 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
May 24th
วันเสาร์ที่ 23 พฤษภาคม 2552 ผู้เขียนได้มีโอกาสไปร่วมงาน Barcamp Bangkok ครั้งที่ 3 โดยปีนี้จัดงานที่ มหาวิทยาลัยศรีปทุม ครับ ต้องขอโทษที่ไม่ได้มาเขียนเรื่องลงใน welovebug เกี่ยวกับงานนี้ครับ เดินทางไปถึง Barcamp Bangkok 3 ตอนเวลาประมาณเกือบๆ 8:00 น. ก็เจอเพื่อนๆ ที่รู้จักกันใน Twitter อยู่หลายๆ คน
ไหน ไหน ก็ไปร่วมงาน barcampbangkok แล้วก็เลยเตรียมเรื่อง และ Presentation ไปร่วมงานนี้ด้วยเช่นกัน ก็เลยนั่งคิดไปคิดมาว่าจะพูดเรื่องอะไรดี กลับมาเปิดดูบทความต่างๆ บน welovebug ก็เจออยู่ 3 เรื่องที่น่าจะนำไปพูด
- คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug
- Living life as a Software Tester!
- 8 ข้อดีที่เป็น Tester ดีกว่าเป็น Developer
หลังจากนั่งพิจารณาดูรายชื่อของผู้เข้าร่วมงานส่วนใหญ่เป็น Developer หรือ Programmer แน่ๆ เลย ซึ่งจากหัวข้อทั้ง 3 เข้าข่ายอาจจะโดนยำได้ทั้งสิ้น ^ ^!
ทำยังไงดี Bug โดน Reject อีกแล้ว
Oct 28th
สวัสดีครับ หลังจากที่คราวที่แล้วเล่าเรื่อง Test Efficiency & Effectiveness ให้ฟังกันไปแล้ว คราวนี้มาลองคุยกันเรื่องเบาๆ (แต่อาจจะเป็นเรื่องที่ทำให้หลายๆคนเกิดอาการเซ็งกันได้บ่อยๆ) กันหน่อยดีกว่าครับ
คำพูดที่หลายๆคนคุ้นหู
“ตัวนี้มันไม่ใช่ Bug นะครับคุณTester นี่มัน Expect Behavior มันต้องเป็นอย่างนี้แหล่ะ เชื่อผมๆ”
มีใครเคยได้ยินประโยคคลาสสิคแนวๆนี้มั่งมั๊ยครับ แล้วลองคิดดูนะครับ ว่าที่ผ่านมาเรามี reaction อย่างไรกับคำพูดนี้ เท่าที่ผมเคยเห็น หรือเคยได้ฟังคนมาบ่นบ่อยๆ ก็จะมีสองกรณีหลักๆ
1. “เอ่อออ เหรอ จริงเหรอ มันต้องเป็นอย่างนี้จริงๆเหรอ… อ่า แต่มันดูแปลกๆนะ อ่า…. เหรอ ไม่ใช่จริงๆ หรอ… อืมๆๆ ไม่ใช่ก็ได้แหล่ะมั้ง เดี๋ยวไป reject ให้ละกันนะ”
หรือแบบที่สอง (หลังจากที่โดน Reject มาสิบตัว อารมณ์กำลังคุกรุ่น อาจจะเป็นแบบนี้)
2. “อะไรนะ ไม่ใช่อีกแล้วเหรอ ทำไม Report มาสิบตัว มันไม่ใช่ Bug หมดเลยเนี่ย มั่วป่าว ทำไมไม่ยอมรับอะไรเลยเนี่ย….(ตูม ตาม ตูม ตาม)
คือ สรุปว่า ถ้าไม่ยอมให้ Reject (แบบไม่เต็มใจ) ก้อจะออกแนว หงุดหงิด โมโห น้อยใจในโชคชะตากันไปเลย หรือถ้าแย่กว่านั้นคือ ต่อไป Tester คนนั้นก็จะเลิก Record Bug ที่เจอ หรือไม่ก็เวลาเจออะไรที่คิดว่าเป็น Bug ก็จะวิ่งไปถาม Developer ก่อน แล้วก้อจะโดนบอกมาว่าไม่ใช่ Bug แล้วก้อจะปล่อยมันผ่านไปไม่ Record อะไรใดๆทั้งสิ้น
จริงๆแล้ว วิธีรับมือกับปัญหาประเภทนี้ ทำได้ไม่ยากหรอกครับ
The First Computer Bug
Apr 29th
สวัสดียามค่ำ สำหรับวันที่ฝนตกลงมาเหมือนฟ้ารั่ว ขณะที่นั่งเขียนเรื่องนี้ก็เวลาประมาณ 18:35 น. จบสิ้นภารกิจการงานประจำวันไป แต่ก็นั่งรอเวลาสัมภาษณ์ผู้สมัครเข้ามาตำแหน่ง Tester ของที่ทำงาน ไม่รู้ว่าจะติดฝนอยู่แถวไหน
ระหว่างที่นั่งรอก็เลยนั่งค้นหาความหมายของคำว่า Error, Fail และ Failure เพื่อจะเอามาเขียนบทความซะหน่อย แต่ หาไป หามา กลับไปเจอเรื่องของ The First Computer Bug เข้า อ่านดูแล้วก็น่าสนใจดี
เลยหยิบยกเรื่องนี้มาเขียนให้เหล่า Tester ทั้งหลาย ที่มีชีวิตผูกพันอยู่กับเจ้าแมลงน้อย หรือ Bug ได้รู้ว่าที่มาของคำว่า Bug ที่เราๆ ท่านๆ ในแวดวง IT และ Computer พูดติดปากกันอยู่ตลอดเวลา ไม่ว่าจะเจอปัญหาการใช้งาน Hardware หรือ Software เราก็จะบอกกันว่ามันมี Bug
ลองมาดูกันหน่อยว่า Bug นี้ มันถูกพบครั้งแรก เมื่อไรบนโลกใบนี้…
จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)
Apr 27th
จุดประกาย : ทำไม 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 เดือน พ.ค นี้ครับ
จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 1)
Apr 16th
ผมขอเริ่มต้นการจุดประกายครั้งแรก ด้วยหัวข้อ “ทำไม Softwareต้องมี bug” ด้วยเหตุผลสองประการครับ
หนึ่ง – การมีตัวตนของ software bug เป็นต้นกำเนิดของอาชีพ software tester (สงสัยนี่ก็อาจเป็นส่วนนึงที่ทำให้ชื่อ webนี้เป็น welovebug กระมังครับ 555)
สอง - เคยมีคน(นอกวงการ IT)ถามผมว่า ทำไมคนในวงการ ITก็มีแต่เก่งๆทั้งนั้น projectแต่ละอันก็ราคาหลายแสนหลายล้านแต่ก็ยังทำระบบที่ไม่มีbugออกมากันไม่ได้ แม้กระทั่งบริษัทชื่อดังและรวยที่สุดอย่าง Microsoftก็ตาม (ตอนโดนถามก็จุกใช่เล่นครับ)
ก่อนที่จะไปไล่ดูสาเหตุของ software bug/defect กัน เรามาลองทำความเข้าใจให้ตรงกันก่อนดีมั๊ยครับ ว่า bug คืออะไรผมได้ไปรวบรวมมาจาก 3 แหล่งซึ่งความหมายค่อนข้างใกล้เคียงกันครับ
ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม
Feb 2nd
“Test อย่างไรให้ครอบคลุม?” ถ้าสำหรับผมละก็เป็นคำถามสุดฮิตแทบจะว่าได้ ไม่ว่า Project Plan จะทำออกมาสวยหรูขนาดไหน แต่ระหว่างการพัฒนา Software ไปเรื่อยๆ ก็จะมี Revise กันอย่างน้อยก็ 3 รอบ เกิดอะไรขึ้นหลังจากนั้นบ้าง
“วัน Launch Project ขยับไม่ได้จริงๆ”
“Scope กับ Requirement มันเพิ่ม เลยต้องขยับ Plan ของ Development Team ออก”
“ทีม Test ลดวันลงหน่อยได้ไหม ช่วยๆ กันนะ”
โอวววว…แม่เจ้า…พูดกันเหมือนยังกับขายของเลย แต่สุดท้ายถ้า Project Owner หรือ Project sponsor ฟันธงลงมาแล้วว่าห้ามขยับวัน Launch Project เท่าที่ประสบพบเจอมา หวยจะมาออกที่ขั้นตอนของ Software Testing Phase
หัวอกของ Tester, Test Lead หรือแม้แต่ Test Manager จะทำไงได้ เมื่อเบื้องบนฟันธงลงมาแล้วแบบนั้น?
คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug
Jan 14th
ขอเปิดประเดิมเปิด We love Bug ด้วยบทความที่น้องในทีมผมไปเจอมาครับ อ่านแล้ว บอกได้คำเดียวว่า “โด๊น…โดน”
น้องทีมผมเค้าบอกว่า ตอนเจอบทความนี้ หยิบเอามาเลย อ่านแล้วมันใช่เลย โดนเลย กับชีวิตจริง ที่เป็นอยู่ตอนนี้
ผมก็เลยถือวิสาสะหยิบมาเป็นเรื่องเปิดของ We Love Bug ก่อนเลยครับ
ถ้าพร้อมก็มานับอันดับถอยหลังจาก จาก 20…19…18…17… จนถึง 1 สำหรับคำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบ Tester เมื่อพบ Bugs …
