เปิดโพย 3 คำถามกันตายตอน Refinement
เคยมั้ย ที่เรานั่งอยู่ในประชุม Refinement (หรือ Grooming) เพื่อพูดคุยเกี่ยวกับ Requirement กัน
Dev ก็คุยกันเรื่อง Logic วุ่นวาย PO ก็อธิบาย Flow งานมารัวๆ
ส่วนเราที่เป็น QA ก็ได้แต่นั่งฟัง แล้วก็จด Requirement ตามเงียบๆ
“เดี๋ยว Dev โค้ดเสร็จส่งของมาให้แล้วค่อยเอามาเทสแล้วกัน”
ตัดภาพมาที่อีก 1 อาทิตย์… Dev ส่งของมาให้และเราก็กำลังจะเริ่มเทส
“อ้าว ถ้า User กดปุ่ม Back ตอนจะจ่ายเงินล่ะ”
“แล้วถ้ากรอกตัวเลขติดลบตรงนี้ จะพังมั้ย”
“ทำไมตรงนี้ไม่ได้ทำ ไม่มี Requirement บอกไว้เหรอ”
แล้วยังไงต่อล่ะทีนี้…
สุดท้ายเราก็จะเดินไปบอกทีมว่า “ยัง Deploy ไม่ได้นะคะ ยังมีบั๊กที่ต้องแก้เต็มเลย” 🛑
แต่มาลองคิดดู จริงๆเราสามารถช่วยทีมได้ตั้งแต่ก่อนจะเริ่มเขียนโค้ดอีกนะ!
ถ้าเราอยากจะเป็น QA ร่างทอง ที่ใครๆก็ต้องการตัว
เราต้องเปลี่ยนจากคน “รอเช็ค” เป็นคน “ช่วยไกด์” ค่ะ
ลองเอา 3 คำถามนี้ไปใช้ดูก็ได้ เพื่อที่จะช่วยอุดรอยรั่วมันตั้งแต่ตอนคุย Requirement ไปเลย
เราอาจจะไม่ได้คำตอบทันทีหรอก แต่บางทีคำถามพวกนี้ จะช่วยนำทางให้เกิด “Conversation”
บทสนทนาของทีมที่จะช่วยเคลียร์ปัญหาบางอย่างตั้งแต่แรก
- คำถาม What If (แล้วถ้า…)
คิดง่ายๆว่าเป็นคำถามที่เราคุยกันเพื่อหา Edge Cases นั่นแหละ- ตัวอย่างสถานการณ์: กำลังคุยเรื่องฟีเจอร์ “โอนเงิน”
- คำถาม What if: ถ้า User เน็ตช้า แล้วกดโอนเงินซ้ำๆ จะโดนตัดเงินซ้ำ 2 รอบมั้ย
- ผลลัพธ์: แทนที่จะรอให้ Dev โค้ดเสร็จแล้วเริ่มเทส เราอาจจะได้คุยกันเรื่อง Idempotency และเพิ่ม requirement ให้ล็อคปุ่มตั้งแต่ตอนดีไซน์เลย ใช้เวลาคุยกันแค่ 5 นาที
แต่ถ้ารอโค้ดเสร็จแล้วไปเทสเจอ ซึ่งเคสนี้อาจจะไม่เจอในการเทสปกติ ถ้าไม่มีใครนึกถึง แล้วไปเจอตอนทำ Performance test ถึงตอนนั้นก็อาจจะต้องรื้อ Logic กันเป็นวัน
- Definition of Success (แล้วเราจะรู้ได้ไงว่ามันสำเร็จ)
คำถามนี้จะเป็นคำถามที่ช่วยเราเคลียร์ Requirement ให้ชัดเจนขึ้น- ตัวอย่างสถานการณ์: PO บอกว่า “อยากให้หน้าจอโหลดเร็วๆ”
- คำถาม: คำว่าเร็วคือเท่าไหร่ วัดยังไง 2 วินาที หรือ 5 วินาที แล้วถ้าคนใช้พร้อมกัน 10,000 คน จะยังต้องเร็วเท่านี้มั้ย
- ผลลัพธ์: พอมีคำถามนี้มา จาก Requirement แบบลอยๆ (Vague) ก็กลายเป็นตัวเลขที่เทสได้จริง และวัดผลได้จริง (Measurable) ทำให้ Dev ทำงานได้อย่างมีเป้าหมาย เราเองก็มีเกณฑ์ที่ชัดเจนว่า ผ่านหรือไม่ผ่าน ถ้าไม่ได้คุยกัน อาจจะต้องมาเถียงกันทีหลังว่า “แบบนี้เร็วพอหรือยัง”
- Is it testable? (แล้วเราจะเทสสิ่งนี้ยังไง)
คำถามนี้กาดาวเลยนะ เป็นอีกหนึ่งคำถามที่สำคัญสุดๆ ที่จะช่วยเตรียมความพร้อมของระบบ- ตัวอย่างสถานการณ์: Requirement บอกว่าจะเชื่อมต่อกับ Third-party เจ้าใหม่
- คำถาม: เรามี Sandbox ให้เทสมั้ย หรือต้องเตรียม Mock API เอง แล้วถ้า Data ฝั่งนั้นไม่ส่งมา เราจะโชว์ error ยังไง
- ผลลัพธ์: นี่คือหัวใจของ Shift-Left เลย ถ้าเราไม่ถาม เราอาจจะต้องมางมอีกเป็นวันตอนที่ Dev ส่งมาให้เทส ก่อนที่จะพบว่ามันเทสไม่ได้ เพราะ Dev ไม่ได้เตรียมโค้ดให้ต่อ Mock API ได้ และ Third-party เจ้านี้ก็ไม่มี sandbox ให้เราใช้ แต่ถ้าเราคุยคำถามนี้ ก็จะช่วยไกด์ให้ทุกคนคิดเรื่อง “วิธีการเทส” ตั้งแต่วันแรก
ได้ 3 คำถามไปแล้ว แต่ทีนี้อาจจะมีบางคนที่ไม่กล้าถาม
เพราะกลัวว่าทีมจะมองว่าเราเรื่องมาก
หรือกลัวว่าจะถามอะไรโง่ๆออกไปแล้วทำให้ดูไม่ดี
ถ้าใครที่กลัวจนไม่กล้าถาม เรามาลองปรับ Mindset กันแบบนี้ดู
- เราถามเพื่อช่วยทีม ไม่ใช่จับผิด: ลองเปลี่ยนคำพูดนิดหน่อย จาก “ทำไมไม่ทำแบบนี้” เป็น “ถ้าเกิดเคสแบบนี้ เราจะจัดการแบบไหนดีคะ”
- ใช้ความเงียบให้เป็นประโยชน์: ถ้าคุยกันแล้วเรายังนึกคำตอบไม่ออก ให้ลองหยุดคิดซักแป๊บ แล้วถามต่อว่า “Worst Case ที่แย่ที่สุดที่อาจจะเกิดขึ้น คือแบบไหนคะ” ประโยคนี้มักจะช่วยให้เห็นบั๊กที่ซ่อนอยู่เสมอ แต่ถ้ายังไม่มีใครตอบ เราอาจจะให้เวลาทุกคนไปคิดก่อนแล้วค่อยกลับมาคุยกันใน session หน้าก็ได้ค่ะ
- คำถามบางคำถามอาจจะไม่ได้เพื่อหาคำตอบเดี๋ยวนั้น: แต่เพื่อทำให้เกิดบทสนทนาในทีม ที่จะช่วยนำไปสู่ Solution ต่อไป หรือบางทีอาจจะช่วยเปิดเผยสิ่งที่ทีมไม่เคยคิดถึงมาก่อน หรือช่องโหว่ใน Requirement ที่เรามีอยู่ แค่เราทำให้ทีมได้คุยกัน ก็ถือว่าช่วยให้งานมีคุณภาพดีขึ้นแล้วค่ะ
ขอย้ำคำเดิมอีกครั้ง “Quality starts with how you think”
คำถามบางอย่างอาจจะดู “ง่าย” หรือ “โง่” แต่ไม่เป็นไร
ให้เราคิดไว้ว่า ถามวันนี้ ดีกว่าปล่อยบั๊กแปลกๆไปโผล่ให้ลูกค้าเห็นในวัน Release
แล้วเราก็ต้องมาเร่งแก้กันข้ามคืน (แถมอาจจะโดนลูกค้าด่าอีก)
ถ้าการแก้บั๊กบนกระดาษ (Requirement) ราคา 1 บาท
การแก้บั๊กบน Production อาจจะมีราคาสูงถึง 1,000 บาท บวกกับความเครียดที่ไม่รู้ราคาเท่าไหร่
เราสามารถช่วยทีมให้แก้บั๊กไปตั้งแต่บนกระดาษให้มากที่สุด ด้วยการถามคำถามเหล่านี้ค่ะ
ใครกำลังจะประชุมคุย Requirement กับทีม ก็ลองหยิบคำถามพวกนี้ไปใช้ดูนะคะ
แล้วอย่าลืมมาเล่าให้ฟังว่าได้ผลยังไงบ้าง Reaction ของทีมเป็นยังไงบ้าง
ส่วนถ้าใครที่ทำอยู่แล้วก็มาแชร์กันได้ค่ะว่ามีอะไรดีๆที่เกิดขึ้นบ้าง หลังจากเราเริ่มถามคำถามไป