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

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

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

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

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

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

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

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

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

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

Read the rest of this entry »

The First Computer Bug

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

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

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

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

Read the rest of this entry »

จุดประกาย : ทำไม 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 เดือน พ.ค นี้ครับ

Read the rest of this entry »

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

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

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

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

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

Read the rest of this entry »

ถ้าเวลามีจำกัดจะ Test อย่างไงดีให้ครอบคลุม

“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 จะทำไงได้ เมื่อเบื้องบนฟันธงลงมาแล้วแบบนั้น?

Read the rest of this entry »

คำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบเมื่อพบ Bug

ขอเปิดประเดิมเปิด We love Bug ด้วยบทความที่น้องในทีมผมไปเจอมาครับ อ่านแล้ว บอกได้คำเดียวว่า “โด๊น…โดน”
น้องทีมผมเค้าบอกว่า ตอนเจอบทความนี้ หยิบเอามาเลย อ่านแล้วมันใช่เลย โดนเลย กับชีวิตจริง ที่เป็นอยู่ตอนนี้
ผมก็เลยถือวิสาสะหยิบมาเป็นเรื่องเปิดของ We Love Bug ก่อนเลยครับ

ถ้าพร้อมก็มานับอันดับถอยหลังจาก จาก 20…19…18…17… จนถึง 1 สำหรับคำตอบ 20 อันดับแรก ที่เหล่า Programmer มักจะตอบ Tester เมื่อพบ Bugs …

Read the rest of this entry »