I Just Found 61 Bugs in Three Hours.

Piyorot
Product Craftsmanship
1 min readMar 9, 2016

เมื่อวานเป็นครั้งแรกที่มีโอกาสได้รีวิวพร้อมทั้งทดสอบงานอีกชิ้นที่ทีมผมปั้นกันอยู่ ใช้เวลาเซ็ตอัพอยู่ครึ่งชั่วโมง จากนั้นใช้เวลาประมาณสามชั่วโมงในการรีวิว

ผลลัพธ์? ผมเรคคอร์ดบั๊กและจุดที่ควรปรับปรุงไปทั้งหมด 61 ตัว!!!

นึกย้อนกลับไปสมัยเด็กๆ จินตนาการไปว่าถ้าตัวเองเป็นเทสเตอร์จริงๆ รันโปรแกรมสามชั่วโมงเจอบั๊กไปเกิน 50 ตัวแบบนี้จะรู้สึกยังไง

“แม่ม … นี่มันทำยูนิตเทสมาก่อนแล้วหรอวะ โคตรกากเลย”

ใครบ้างไม่เคยหงุดหงิด ใครบ้างไม่หัวเสีย เมื่อเจอบั๊กในปริมาณมหาศาลแบบนี้ … ใครบ้างหยุดเทสตั้งแต่ชั่วโมงแรก ใครบ้างตีงานกลับไปหาทีมเดฟด้วยเหตุผลที่ว่า “คุณภาพไม่ได้ตามมาตรฐาน”

แต่นี่คือความจริงที่ผมบอกตัวเองระหว่างและหลังการรีวิวงานครั้งนี้

“แม่ม นี่น้องมันทำคนเดียวนะเว้ย พาร์ทไทม์อีกต่างหาก — ได้ขนาดนี้ก็เก่งแล้วปะ?”

“แถมเจอหน้ากันแค่สองสามครั้ง บรีฟงาน เล่าสโคปงานคร่าวๆโคตรๆ ส่งสกรีนดีไซน์ให้ทางเมล์ คุยปัญหาและตอบคำถามกันทางสแลค นานๆจะโทรคุยกันสักที — มึงจะเอาอะไรอีก?”

“อ่อ แล้วยังกะมึงคิดโฟลมาซะสมบูรณ์แบบเลยนะ สัด หน้าจอก็อยู่ในพาวเวอร์พ้อยต์ สัดส่วนไม่ได้ เลย์เอ้าท์ผิดๆถูกๆ แล้วรีไควเม้นต์นะตัวมึงเองยังไม่ชัวร์เลย เปลี่ยนไปเปลี่ยนมา ลืมนั่นลืมนี่ — ความผิดใครวะ?

ความผิดใครวะ? — มึงนั่นแหละ … ความผิดผมเองครับ ผมไม่ใช่ในฐานะเทสเตอร์แต่ในฐานะโปรดักท์ โอนเนอร์ (หรือจะเรียกอะไรก็ตามแต่) ผมในฐานะคนที่เข้าใจสิ่งที่ตัวเองต้องการมากที่สุด ผมในฐานะคนที่สั่งให้แก้ให้เปลี่ยนทุกสิ่งอย่างได้ตามใจ และผมทำหน้าที่ได้ไม่ดีพอในการถ่ายทอดความเข้าใจทั้งหมดนั้นไปให้น้องเดฟคนนั้น

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

อาจารย์ผมเคยบอกไว้ว่า “ไม่มีซอฟต์แวร์ตัวไหนในโลกที่ไม่มีบั๊ก”

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

มีบั๊กเยอะแล้วไง?

การเทสก็ไม่ใช่กระบวนการที่จะทำให้ซอฟต์แวร์ไม่มีบั๊ก มันไม่เกี่ยวกัน การคาดหวังว่างานที่ส่งมาจากทีมเดฟคืองานที่คลีนและเคลียร์เป็นความคิดที่ผิดมหันต์ ถ้าเดฟทำได้แบบนั้น ทีมเทสเตอร์ก็ตกงานกันหมดแล้ว

การเทสมีไว้เพื่อค้นหาข้อพกพร่องของซอฟต์แวร์ก่อนการส่งมอบให้ลูกค้า เราควรจะดีใจที่เจอบั๊ก (จำไว้) การเทสมีไว้เพื่อครั้งหน้าเราจะไม่เจอบั๊กตัวนี้ซ้ำอีกครั้ง เราควรจะดีใจที่เจอบั๊ก ยิ่งมากยิ่งดี (จำไว้)

มีบั๊กเยอะแล้วไง?

เดฟก็เป็นแค่มนุษย์คนหนึ่งที่ผิดพลาด เหน็ดเหนื่อย หลงลืม หละหลวม สะเพร่าได้ตามธรรมชาติ การโยนความผิดทั้งหมดไปหาเดฟเป็นเรื่องไม่เข้าท่า มันมีเหตุผลเป็นร้อยเป็นพันที่ทำให้ซอฟต์แวร์ของเรามีจุดพกพร่อง อย่ามองว่าเค้ากาก เค้าทำงานห่วย เค้าไม่รับผิดชอบ … โชว์ความเห็นอกเห็นใจให้พวกเค้าเห็นหน่อย พยายามทำความเข้าใจจากมุมมองของพวกเค้าบ้าง สุดท้ายแล้วพวกเราก็ทีมเดียวกันทั้งนั้น

มีบั๊กเยอะแล้วไง?

มีบั๊กเยอะ โอกาสแก้บั๊กก็เยอะ โอกาสที่จะปรับปรุงคุณภาพของซอฟต์แวร์ก็เยอะตามไปด้วย และนี่คือประเด็นที่สำคัญที่สุดของการรีวิวและทดสอบงานครั้งนี้ของผม

คิดและเขียนคือสิ่งที่ผมชอบ แบ่งปันคือสิ่งที่ผมรัก เพราะแบบนี้ทุกวันผมเขียนเพื่อถ่ายทอดเรื่องราวจากชีวิตจริง จากประสบการณ์ จากแนวคิด จากอนาคตที่ดีผมมองเห็น และทุกอย่างที่ผมประยุกต์ใช้เพื่อสร้างให้อินเท็นติกเป็นบ้านที่น่าอยู่ บ้านที่เป็นจุดเริ่มต้นของการเปลี่ยนแปลงเล็กๆที่สร้างความแตกต่างในสังคมได้ — มันน่าภูมิใจที่ผมรู้ว่า … ไม่ใช่มีแค่ผมคนเดียวที่อยากเห็นการพัฒนา :)

Inthentic On Facebook | Inthentic On Twitter | Inthentic On Instagram

--

--

Piyorot
Product Craftsmanship

A member of Mutrack and Inthentic. I lead, learn, and build with vision, love and care. https://piyorot.com