Confirmation Bias ของ Dev กับ QA
ก่อนที่จะเข้าเรื่องอาจจะต้องบอกก่อนว่า มันเป็นเรื่องปกติที่ทั่วไปอาจจะมี Confirmation Bias อยู่ มันไม่สามารถที่จะทำให้หายไปได้อย่างสมบูรณ์ตราบใดที่เรายังเป็นคนอยู่ แต่ตรงนี้เราจะมาคุยกันให้มีความรู้ตัวว่า ตอนนี้มันจะมีไหม
Confirmation Bias กล่าวโดยสรุปคือ การที่เราพยายามหาข้อมูลหรือหลักฐานเพื่อสนับสนุนแนวความคิดของตัวเอง ตัวอย่างเช่นปัญหา 2–4–6 ที่เขียนไว้เมื่อครั้งก่อน
แล้ว Confirmation Bias ของ Dev กับ QA จะต่างกันยังไงบ้าง
มันก็ต้องเริ่มจากที่มาของมันก่อน
ในการพัฒนาซอฟท์แวร์หนึ่งระบบนั้นมีเรื่องราวรายละเอียดต่างๆ มากมาย ซึ่งไม่สามารถจะควบคุมได้หมดโดยใช้คนๆ เดียว จึงต้องมีการแบ่งทีมงานออกมาเพื่อที่จะโฟกัสในภารกิจบางอย่าง
อย่าง Developer ก็จะ ทำหน้าที่ พัฒนาซอฟท์แวร์ไป QA ก็จะทำหน้าที่ตรวจสอบไป
พอประสบการณ์เริ่มเยอะ และทำบ่อยๆ แนวความคิดหรือแนวปฎิบัติก็จะทำให้เรา โฟกัสกับสิ่งที่เราทำบ่อยๆ นั้น
Dev ก็จะมองว่า Software ต้องเสร็จ ถ้ามีอะไรที่แสดงให้เห็นว่างานเสร็จก็จะหมายถึงเราเดินไปข้างหน้าอยู่ และจะพยายามหาข้อมูลเพื่อบอกว่างานฉัน work และกำลังเดินหน้าอยู่
QA เมื่อถูกให้คิดแต่เรื่องของบั๊กไปเรื่อยๆ ก็จะทำให้ มุมมองโฟกัสปัญหามากกว่าสิ่งที่ใช้ได้
ดังนั้นถ้ายกตัวอย่างที่น่าจะเจอกันบ่อยๆ ซึ่งเป็นตัวอย่างหนึ่งก็คือ
It’s worked on my machine
มันเป็นอะไรที่แปลกมากทั้งๆที่ เราทราบว่า ซอฟท์แวร์สุดท้ายไม่ได้ใช้งาน Production ในเครื่องตัวเอง แต่เราก็มักจะได้ยินประโยคนี้มาบ่อยๆ
มุมมองหนึ่งอาจจะเป็นการยืนยันว่ามันใช้งานได้ แต่อีกมุมหนึ่งก็อาจจะบอกว่าตอนนี้มัน work ที่เครื่อง อันที่ไม่ work เป็น next progress
หรือแม้กระทั่งการเขียนเทส เอง Dev ก็จะเขียนเทส ที่เป็น Good path มากกว่า Bad path บางคนถ้าโหดหน่อย ก็จะเขียนแค่ Good path แค่ common อันเดียว เลวร้ายสุดคือ ฉันสุดยอดไม่มีบั๊กหรอก ไม่เทส (พวกนี้ควรเอาออกก่อนไม่งั้นมีภัย)
ขณะที่ QA ก็จะมีปัญหาอีกแบบนึง ตัวอย่างที่มักจะเจอก็จะเป็นเรื่องของ Extreme case เช่น ส่วนตัวก็เคยโดนรุ่นพี่เตือนเรื่อง dataset ที่เทสระบบมันมากเกินไป ถ้าใครสงสัยว่ามันมากยังไง เอาง่ายๆ ว่า ระบบเอา 100 ก็เทสที่ 1000000 ซึ่ง การทำระบบรองรับข้อมูล 100 กับ 1000000 เป็นงานที่มีความยากง่ายไม่เท่ากัน ซึ่งในหัวตอนนั้นจะบอกว่ารันเพื่อหา defect จริงๆ ตอนนั้นถ้าพี่เขาไม่เตือนก็น่าจะเสียเวลาทำระบบกันใหม่อีกรอบ เสียเวลาและ resource มากมาย
มันมีประโยคที่จะช่วยจัดการเรื่อง Confirmation Bias ดังนี้ครับ
The only way to show you’re right, is to try and show you’re wrong.
อย่างแรกคือ ถ้าเราเป็น Dev เราลองคิดว่า “ปัญหานี้อาจจะมาจากเราก็ได้นะ” แล้วลองหาข้อมูลเพื่อสนับสนุน เรื่องนี้ดู ถ้าหาเจอก็แก้ไข ถ้าไม่เจอก็ยินดีด้วย
ในขณะที่ถ้าเราเป็น QA เราอาจจะต้องคิดเพิ่มนิดนึงว่า สิ่งนี้อาจจะถูกอยู่แล้วก็ได้ แล้วหาข้อมูลสนับสนุนดู เช่น context มันเป็นแบบนี้ input มันได้แค่นี้
ตรงนี้บอกก่อนว่า เราแค่ Challenge ตัวเองไม่ใช่การหลอกตัวเองว่า “ฉันเป็น Dev ที่โง่มากๆ มันเลยมีอะไรที่เป็นปัญหาของฉันทั้งนั้น” ไม่ต้องทิ้งความภูมิใจของตัวเองนะ
แต่ถ้าวิธีแรกดู Subjective เกินไป แนะนำให้ใช้โพยครับ ก็อาจจะเป็น Checklist หรือ กำหนด Definition of Done ให้ชัดเจน ว่าแต่ละงาน จะมีอะไรจะเทสอะไร
และสิ่งที่สำคัญอีกเรื่องคือ รับคำแนะนำจากผู้อื่น โดยเฉพาะคนละทีม อันนี้คือแทนที่จะคิดเรื่อง challenge ด้วยตัวเอง ก็ให้อีกฝ่ายซึ่งจะมีความเชี่ยวชาญอยู่แล้ว คิดแทนให้เลย เราจะได้เข้าใจมิติการคิดด้วย และมันจะเสริมให้เราคิดให้รอบได้มากขึ้น
สุดท้ายเรื่อง Bias ตัวนี้มันจะไม่ได้หายไป การจะสู้กับมันได้ คือต้องยอมรับว่ามันมีแล้ว ให้ความคิด ความชัดเจน และเพื่อนร่วมทีม ช่วยเสริมให้มันผ่านไปครับ
อ้างอิง
https://dev.to/techelevator/confirmation-bias-how-your-brain-wants-to-wreck-your-code-337h
http://www.devpsy.org/teaching/method/confirmation_bias.html