Bug Bash คืออะไร

ถ้าหากคุณเดินเข้าไปหาทีมแล้วบอกว่า เฮ้~ พวกนาย เราจะเอาของชิ้นนี้ไปใช้งานจริงแล้วนะ ทันใดนั้น คุณก็เหลือบไปเห็นความเงียบ กับสายตาที่มองลงพื้น ของเหล่าสมาชิกในทีม นั่นเป็นสัญญาณบ่งบอกให้คุณรู้ว่า บางสิ่งบางอย่างมันไม่ถูกต้องละ และสิ่งที่ว่า มันอาจจะเป็น “ความมั่นใจ” ว่าของที่เราทำ มันเวิร์คจริงเปล่าว้า

ต่อให้เราปึก เขียนโปรแกรมเป๊ะเวอร์ ยัดของดีเข้ามาเต็มไปหมด Automated Test ก็รันทุกรอบ แต่บางครั้ง ต่อให้เราเตรียมตัวดีที่สุด ถึงวันที่จะต้องปล่อยจรวด มันก็เป็นเรื่องปกติที่ความตื่นเต้นก็ยังเกิดขึ้นได้ใช่มั้ยละ ถ้าอย่างนั้นแล้ว เราจะทำยังไง เพื่อเพิ่มความมั่นใจของทีมดี

Bug Bash เป็นกิจกรรมที่หยิบเอาทุกคนมาร่วมกันทดสอบงานที่เราทำ โดยอาศัยความเชี่ยวชาญของแต่ละคนที่แตกต่างกัน ซึ่งในกิจกรรม รวมตั้งแต่ Product Owner, Business Analyst, Developer, Tester, Support, หรือแม้กระทั่งการเข้ามาร่วมกิจกรรมของ Marketing, Customer Service จะช่วยเพิ่มความเข้มข้นในกิจกรรม

Bug Bash ทำเฉพาะ QA ได้มั้ย?

ตอบ : ไม่ได้ Bug Bash เป็นการอาศัยความเป็นผู้เชี่ยวชาญที่แตกต่างกัน เพื่อให้คนตาบอดมองเห็นช้างทั้งตัวได้เหมือนกัน ดังนั้น การทดสอบร่วมกันโดยกลุ่มคนที่เชี่ยวชาญคนละด้าน เป็นเรื่องจำเป็น (a must)

Bug Bash นั้นควรเป็นกิจกรรมที่ใช้ในการทดสอบเพิ่มเติม นอกเหนือจากการทดสอบปกติที่ทำโดย Tester, Automation Test, และเทสอื่นๆ ที่ทำกันเป็นปกติอยู่แล้ว ดังนั้น การมี Bug Bash ไม่ได้หมายถึงว่า เราสามารถหย่อนยานกิจกรรมอื่นลงไปได้

เป้าหมาย

เป้าหมายสามารถมีได้แตกต่างกันออกไปคือ

ว่าง – ไม่มีอะไรทำ ( – -‘)

ต้องการอะไรที่ดีกว่าจุดธูปขอพรสิ่งศักดิ์สิทธิ์ ว่าสิ่งที่ทำมันจะไม่พัง ( + _ + ” )

ไม่ใช่ๆๆ …. เอาใหม่ๆ

เป้าหมายของ Bug Bash นั้นจะแตกต่างกันออกไปตามโอกาสความเหมาะสม เช่น ทำเพื่อเสริมความมั่นใจของทีม ทำเพื่อค้นหาบักที่มีความอันตราย ทำเพื่อให้ทีมเรียนรู้ และเข้าใจงานที่ตัวเองได้สร้างสรรค์ขึ้นมา ตอบคำถาม ข้อสงสัย ทั้งจากฝั่ง Business / Tech บางทีก็มีฟังก์ชั่นที่ฝั่ง Tech คิดเองเออเอง ฝั่ง Business ก็ไม่เข้าใจว่าเออ เค้าคิดอะไร ทำไมถึงทำแบบนี้ออกมานะ ก็ช่วยได้เหมือนกัน

Triggers

สิ่งสำคัญของการทำ Bug Bash คือ ของมันจะต้องอยู่ในสถานะพร้อม สมบูรณ์ที่สุดแล้ว คือหมายถึง ผ่านกระบวนการทั้งหมดมาแล้ว พัฒนาและทำการทดสอบเสร็จเรียบร้อย ของเอามารวมกันสมบูรณ์ พร้อมจะใช้งานจริงๆ ละ ไม่ใช่ขาดชิ้นนั้น รอทำ ขาดชิ้นนี้รอทำอยู่

ช่วงเวลา ถ้าเป็นกิจกรรมที่เราทำก่อน Deploy นั่นคือ เราต้องการสร้างความมั่นใจให้กับทีม บางครั้ง เราไม่ได้ปล่อยของชิ้นเล็กๆ ไปเรื่อยๆ แต่มันมีจุดเปลี่ยนหลักๆ ที่สำคัญ เช่น เปลี่ยนระบบที่ใช้ เปลี่ยนวิธีการ เปลี่ยนรูปแบบการทำงานไปเลย บางที คนที่มั่นใจที่สุด อาจจะเป็น Developer ในขณะที่ Customer service อาจจะขาสั่น เข่าอ่อน ว่า Deploy รอบนี้ งานจะเข้ามั้ย

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

How

สั้นๆ ก็คือ แค่เอาคนมากองแล้วทำการเล่นกับ Product ที่สร้างขึ้นมาแล้วดูว่า เอ ตรงไหนมันดูขัดต่อความรู้สึกแล้วก็โน๊ตกองรวมกัน จากนั้นก็ค่อยมาไล่ดูด้วยกันเท่านั้นแล

ถ้าแบบเป็นขั้นตอนขึ้นมาหน่อยก็

1. หลังจากนัดแนะเรียบร้อย ก็จัดแจงเอาทีมมากองรวมกันที่เดียว
2. สร้างสภาพแวดล้อมที่ปลอดภัย — การหาบักเจอในงานนี้ มีเพื่อประโยชน์ร่วมกันทุกคน ดังนั้น ไม่ควรจะมีใครที่จะถูกต่อว่า ไม่งั้น Bug ก็อาจจะถูกซ่อนเก็บเงียบไว้ต่อไป ถ้ารู้สึกว่า สภาพแวดล้อม ยังไม่ปลอดภัย จุดเริ่มต้น อาจจะไม่ใช่การทำ Bug Bash แต่เป็นการทำความเข้าใจในทีม รวมถึงการ Set Intention ร่วมกันก่อน ว่าเป้าหมายของการทำ Bug Bash คืออะไร ทีมรู้สึก Safe หรือไม่
3. เป้าหมายที่ทำ Bug Bash — อาจจะประกาศหรือไม่ประกาศเป้าหมายตอนแรกก็ได้ ว่าปลายทางเราต้องการผลเพื่ออะไร ถ้าไม่ประกาศ เราจะเห็นภาพของการเทสสุ่มๆ เพิ่มขึ้น ซึ่งเพิ่มโอกาสในการเจอข้อมูลบางจุดที่เราไม่ได้คาดคิดมาก่อน
4. เขียน Guideline คร่าวๆ ถึงสิ่งที่ทีมควรทำ เช่น Version ที่จะใช้ร่วมกัน, วิธีการ Report Bug, ขอบเขตระยะเวลา, การแบ่งบทบาท ใครจะลองเล่นอะไรตรงไหน
5. ก็เริ่มให้เทส และ จบการทดสอบเป็นช่วงเวลา
6. นำผลทั้งหมด มาคุยกัน ซึ่งถ้าสรุปเลยก็จะดีมาก ไม่งั้นช้าไป นอกจากจะลืม แล้วยัง งง ดังนั้น การเตรียมระยะเวลาสำหรับ Bug Bash ควรเผื่อ 50/50 คือ 50% สำหรับไล่ล่า และอีก 50% สำหรับ Discussion ตัวเลขไม่ได้มีตายตัว ลองปรับเอาตามความเหมาะสม

ในขั้นตอนการนำผลมาคุยกัน ก็ประกาศให้ชัดเจนว่าเราทำ Bug Bash แล้วตอนนี้เราต้องการตอบคำถามในเรื่องอะไรบ้าง เพื่อที่จะได้แยกชิ้นส่วน ระหว่าง ของที่สามารถเอาไปจัดการในภายหลังได้ กับ ของที่ต้องมีคนรับไปดูแลในทันที เช่นว่า ถ้าไม่แน่ว่าว่า การเปลี่ยนแปลงครั้งสำคัญ จะมีผลต่อการ Deploy หรือไม่ ก็ให้โฟกัสกับรายงาน ที่มีความเกี่ยวข้องนี้ก่อน ส่วนพวก Feedback / Enhancement ก็เก็บไว้ค่อยพูดคุยกันเพิ่มเติมในภายหลัง สิ่งสำคัญคือ เราจะต้อง

1. รู้ว่าทีม Confident พอที่จะบอกว่า เอาหละ อยากให้คนอื่นเอาไปเล่นละ
2. เหลืองานอะไรที่ต้องเก็บตก ที่จะทำให้ทีม Confident มากขึ้นบ้าง และ ใครมีหน้าที่ไปจัดการของเหล่านั้น และระยะเวลาในการติดตามผลอีกครั้งเมื่อไหร่

ส่งท้าย

Bug Bash มีมานาน คนคิดเป็นใครก็ไม่แน่ใจนัก ถ้าใครสนใจ ลองหาคำว่า Bug Bash น่าจะมีบทความดีๆ ให้อ่านอีกเพียบ สำหรับเนื้อหาข้างบน มิได้มาจากทฤษฏี แต่มาจากการลองทำดู แล้วสรุปตามความเข้าใจของผู้เขียน ดังนั้น หลายจุดน่าจะสามารถลองปรับแก้ ลองเล่น เพื่อให้ดีขึ้นได้อีก สุดท้าย ท้ายสุด Bug Bash เป็นกิจกรรมสำหรับมนุษย์ มิใช่สำหรับ Automation อันนั้นลองดู Chaos Engineering ดู ซึ่งเป้าหมายมันก็จะไม่เหมือนกันละนะ

อ่านเพิ่มเติม

REA Engineering Blog – Bug Bash — The Game