Software Testing Software Tester Blog - WeLoveBug.Com

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

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

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

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

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

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

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

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

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

อย่างแรกที่เราต้องทำความเข้าใจให้ได้ก่อนคือ Tester ไม่ใช่คนที่สามารถ improve quality ของ software ได้ เราเป็นแค่ส่วนหนึ่งในกระบวนการเท่านั้น คิดง่ายๆ ก็คือ เราไม่สามารถ Fix Bug ที่เราเจอได้ด้วยตัวเอง แค่นี้ก้อเห็นชัดแล้วว่า จริงๆแล้วเราเป็นแค่ส่วนหนึ่งของกระบวนการ Improve Quality แล้วหน้าที่ของเราจริงๆคือ อะไรหล่ะ?

จริงๆ แล้วหน้าที่หลักของ Tester คือการ Access Quality ของ Software นั่นเอง เรามีหน้าที่

1. หาให้เจอว่า Software ที่เรารับผิดชอบอยู่นั้น มี Bug อะไรบ้าง

2. มี Level of Confident สำหรับ Software ก่อนที่จะ Release มากหรือน้อยแค่ไหน

ถ้าพูดกันง่ายๆก็คือ หลักๆแล้วมีหน้าที่ ค้นหา และ Report Bug ของ Software นั่นเอง

ส่วนอีกหน้าที่หลักคือ การให้มุมมองในมุมของ User หรือผู้ใช้งานโปรแกรมนั่นเองว่า ถ้ามองจากมุมลูกค้าแล้วเนี่ย Behavior ของโปรแกรมแบบนี้จะมีผลกระทบอย่างไรกับเค้าบ้าง

ถ้าเริ่มเข้าใจบทบาทและหน้าที่ของตัวเองแล้ว ความหงุดหงิดใจจะหมดไป สรุปง่ายๆ ว่า พยายามมองในมุมของลูกค้า แล้วถ้าเจออะไรที่แปลกๆ ผิดปกติจากมุมนั้นหล่ะก็ เราก็ Report เป็น Bug ไปให้หมด

ขอเน้นว่าให้ทำแบบ Formal ด้วยนะครับ คือ Record/Log Bug ใส่ไว้ใน Bug Reporting/Logging Tool นั่นเอง (อันนี้แล้วแต่ แต่ละบริษัท แต่ละองกรค์นะครับ ว่าจะใช้ Tool แบบไหน บางที่แค่ Report ลงใน MS Excel ก็ใช้ได้แล้วหล่ะ)

ทีนี้ หน้าที่ของการตัดสินใจว่า สิ่งที่เรา Report (จริงๆแล้วสิ่งที่เรา Report เนี่ยเรียกว่า Failure นะ คือ เป็นสิ่งที่ไม่ตรงกับ Expected Result ที่เราคิดไว้นั่นเอง แต่ Failure แต่ละตัวอาจจะเป็น Bug หรือไม่เป็นก็ได้หลังจากผ่านการทำ Bug Analysis แล้ว) ไปเนี่ยเป็น Bug รึเปล่า เป็นหน้าที่ของทั้งทีม (โดยทั่วไป ทีมในที่นี้ ก็คือ Dev, Test, Product Manager)

หน้าที่ของเราคือการนำเสนอมุมมองของลูกค้าให้ได้มากที่สุด แต่สุดท้ายแล้วให้เป็นหน้าที่ของทั้งทีม ว่าจะตัดสินใจให้สิ่งที่เรา Report ไปเป็น Bug รึไม่ ถ้าผลสรุปออกมาแล้วขัดกับความคิดของเรา ไม่ต้องหงุดหงิดนะครับ ให้คิดซะว่า เราทำหน้าที่ของเราแล้ว ที่สำคัญ คือให้บันทึกข้อมูลไว้ใน Record ของ Bug ตัวนั้นด้วยว่า สุดท้ายแล้วทีมตัดสินใจไม่ให้มันเป็น Bug ด้วยเหตุผลอะไร

ทีนี้ ถ้าเราทำงานกับทีมที่ไม่ค่อยจะยอมรับ Bug แล้วก็พยายามจะ Reject อยู่เป็นประจำเนี่ย สุดท้ายแล้ว ลูกค้าจะ Report ปัญหาเหล่านั้นกลับมาเอง

สิ่งที่ Test Leader หรือ Test Manager ต้องทำต่อไปก็คือ ทำสรุปไว้ว่า Bug ที่ลูกค้า Report เข้ามานั้นมันตรงกับสิ่งที่เราเคยเจอ แต่ถูก Reject ว่าไม่ใช่ Bug มากหรือน้อยขนาดไหน รวบรวมไว้ซักพัก แล้วทำ Presentation หรือ จัด Meeting สรุปให้ทีมดูว่าจริงๆแล้ว Bug พวกนี้เราเคยเจอแล้วแต่ว่าโดน Reject ไปตอน System Testing สิ่งที่ เราต้องพยายามทำคือ Convince ทีมให้เห็นว่าเราควรจะเปลี่ยน Strategy หรือ แนวคิดในการ Accept หรือ Reject Bug กันใหม่มั๊ย

ถ้าเราได้ทำตามวิธีข้างต้นแล้วทุกคนในทีมจะเริ่มเปลี่ยนมุมมองในการ Reject Bug เนื่องจากมี Lesson Learn จาก Bug ที่ลูกค้าเจอหลัง Release ดังนั้นต้องพยายาม Record สิ่งที่เราเจอทั้งหมดไว้ครับ (เน้นว่า Record ทั้งหมด จะโดน Reject ไปเยอะแค่ไหนก็ไม่เป็นไร สุดท้ายแล้วจะสามารถใช้เป็นหลักฐานได้ว่าปัญหาพวกนี้ Tester เคยหาเจอหมดแล้ว)

หลายๆครั้ง Tester จะท้อใจ แล้วก้อไม่กล้า Record Bug กลัวจะโดน Dev ตำหนิว่า Report อะไรมาไม่รู้ ไม่มีสาระ อันนี้ Test Leader ต้องช่วยนะครับ ต้อง Communicate ไปเลยว่า Tester จะ Record สิ่งที่เราเห็นว่าน่าจะเป็นปัญหาทั้งหมด แต่ถ้าจะ Reject ก็ให้ Analyze แล้วใส่เหตุผลในการ Reject มา

จากที่เคยใช้วิธีนี้กับทีมตัวเอง และแนะนำให้น้องๆ พี่ๆ ใน Class ที่เคยสอนได้ลองใช้ หลายๆคนกลับมาเล่าให้ฟังว่า ได้ผลดีมากครับ ช่วยแก้ปัญหาด้านความรู้สึกของ Tester เองได้ดีมาก อีกทั้งไม่ทำให้ทีมต้องรู้สึกไม่ดีต่อกันด้วย สุดท้ายแล้วทั้งทีมจะได้ Learning และ เติบโตไปพร้อมๆกัน

มีทริค อีกอย่างนึงในการ Convince ให้ทีมเห็นว่าสิ่งที่เราเจอสมควรจะเป็น Bug ในตอนทำ Bug Analysis ครับ ทำได้โดยการถามคำถามง่ายๆไปว่า ถ้าลูกค้า Report เข้ามาแบบนี้ เราสามารถบอกลูกค้าได้มั๊ยว่านี่คือ Expect Behavior?” ทีนี้คนที่เป็น Product Support หรือ Product Manager เค้าจะเริ่มคิด แล้วส่วนใหญ่จะบอกมาเองครับ ว่าไม่ได้ ยังไงก้อคงต้องยอมรับว่าเป็น Bug (ในกรณีที่มันควรจะเป็นจริงๆนะ)

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

written by Nutdanai \\ tags: bug, defect, Software Testing