เคยนั่งประชุมใน sprint planning แล้วรู้สึกว่าเราไม่ได้มีอะไรจะไป contribute ให้ทีมเลยมั้ยคะ
Dev ก็ estimate งานกัน ให้ story point กันไป
PO ก็เรียง priority เลือกของเข้า sprint
ส่วน QA อย่างเราก็นั่งฟังไป จดไป ว่ามีงานอะไรรอให้เราเทสบ้าง
บางทีเราอาจจะรู้สึกว่า “ก็มันไม่มีอะไรจะพูด แค่ตั้งใจฟังก็พอแล้ว”
แต่จริงๆ มันเป็นแบบนั้นรึเปล่า
.
เราไม่มีอะไรจะพูดจริงๆ หรือ เราอาจจะแค่คิดว่าสิ่งที่เรารู้มันไม่ได้สำคัญพอ
QA หลายคนอาจจะรู้สึกว่าตัวเองถูกกำหนดบทบาทหน้าที่มาให้อยู่แล้ว
“รอ Dev โค้ดเสร็จก็เอามาเทส”
“ออกแบบ Test Case ตาม Requirements ที่ได้รับมา”
“เจอบั๊ก ก็เปิด ticket ให้แก้”
“ถ้าเทสผ่าน ก็ approve ให้เอาขึ้นได้”
แล้วเราก็จะรู้สึกว่า นี่คือทั้งหมดที่เราทำได้แล้ว
.
จริงๆ แล้วยังมีอีกหลายอย่างที่อยู่ในหัวของเรา ที่คนอื่นอาจจะไม่รู้นะคะ
อย่างเช่น
เรารู้ว่าถ้างานแบบนี้ บั๊กมักจะไปโผล่ตรงจุดไหน
เรารู้ว่าบาง feature อาจจะดูเล็ก เหมือนไม่มีอะไร แต่ซ่อนงานไว้เต็มไปหมด
เรารู้ว่า ถ้า story ไหนมีปัญหา แล้วมันจะบล็อคงานอื่นหมดทั้ง sprint
ข้อมูลพวกนี้มันไม่ได้อยู่ใน Jira ticket ไม่ได้อยู่ใน backlog
แต่มันอยู่ในหัวของเรา สะสมมาจากสิ่งที่เราเจอ (และเจ็บ) จาก sprint ที่ผ่านมา
บางทีเราอาจจะไม่ทันนึกถึง แล้วถ้าปล่อยให้มันผ่านไป มันก็จะหายไปพร้อมกับเรานั่นแหละ
.
💡ลองมาดูตัวอย่างกันดีกว่าว่าเราทำอะไรได้บ้าง
- Story ไหนมีความเสี่ยง บอกไปเลย
ตอนที่ทีมกำลังเลือกของเข้า sprint นี่แหละค่ะ เป็นจุดที่ดีที่สุดที่จะบอกว่าความเสี่ยงอยู่ตรงไหนบ้าง ดีกว่าไปเจอเอาตอนกำลังจะจบ sprint แล้วต้องมาเร่งแก้ปัญหากัน
สมมติทีมกำลังทำ feature โค้ดส่วนลด แต่เรารู้ว่ามันจะเชื่อมกับส่วนที่เป็นการสะสมแต้มด้วย ก็สามารถบอกไปได้เลยโดยไม่ต้องรอให้ใครถามก่อน
“Story นี้จะเชื่อมกับการสะสมแต้มด้วยนะคะ มีคิด scope ตรงนั้นไว้รึยัง ต้อง estimate เผื่อไว้เลยมั้ยคะ”
“Feature นี้ ตอนที่ทำเรื่องสะสมแต้มแล้วติดปัญหาเรื่องการคำนวณเยอะเลยนะคะ มีคิดเผื่อไว้รึยัง”
อะไรเล็กๆ น้อยๆ แค่นี้ อาจจะเปลี่ยน sprint ได้เลยนะคะ
เพราะเราอาจจะทำให้ทีมคิดถึงจุดที่ทุกคนลืมไป แล้วกลับมาคุยกันใหม่อีกรอบก็ได้
👉 ถ้าไม่พูด: ทีมก็อาจจะทำไปตาม requirement ที่มี สุดท้ายมาเจอว่าถ้าใช้โค้ดส่วนลด แล้วการสะสมแต้มจะคำนวณไม่ถูก อาจจะต้องรื้อ logic กันใหม่ตั้งแต่ต้น เสียเวลาอีกหลายวัน
👉 ถ้าพูดตอน planning: ทีมได้คุย scope กันตั้งแต่แรก จะเพิ่ม requirement ไปเลย หรือจะเปิด ticket แยกไว้ทำทีหลัง เราก็จะได้เคลียร์กันตั้งแต่ต้น ไม่ต้องมาเจอเซอร์ไพรส์ตอนหลัง
.
- Testing effort ที่บางคนอาจลืมไป อย่าปล่อยให้มันเป็นงานที่ไม่มีใครมองเห็น
Dev อาจจะ estimate มาแค่เวลาที่ใช้ implement
แต่บางงานที่ใช้เวลา implement นิดเดียว อาจจะใช้เวลาเทสมากกว่าหลายเท่าก็ได้
“Story นี้ถ้าจะเทสให้ครบ ต้องเตรียม data เยอะมากเลยนะคะ ต้องให้ทีมช่วยดูด้วยกัน เรา estimate เผื่อตรงนี้รึยังคะ”
“Story นี้แก้นิดเดียว แต่ต้องทำ regression ทั้งหมดเลยนะคะ น่าจะใช้เวลาพอสมควร”
“Story นี้ต้องต่อกับ 3rd party เยอะเลยนะคะ เราเผื่อเวลาเตรียม mock api สำหรับเทสไว้รึยังคะ”
เห็นมั้ยคะ ว่ามันมีหลายอย่างที่เราช่วยถาม เพื่อเคลียร์ให้ชัดตั้งแต่ต้นได้เลย
👉 ถ้าไม่พูด: เราอาจจะได้ sprint ที่ออกมาดูสวยงาม แต่พอทำจริง งานไม่เสร็จ แล้วก็ไม่มีใครรู้ว่าเกิดอะไรขึ้น แล้ว ticket ก็โดนยกไป sprint หน้าไปเรื่อยๆ
👉 ถ้าพูดตอน planning: ทีม plan ได้ดีขึ้น เห็น scope ชัด ไม่เจอเซอร์ไพรส์ตอนหลัง
.
เห็นมั้ยคะว่า Sprint Planning มันไม่ใช่แค่การเข้ามาฟังเพื่อรับงานอย่างเดียว
แต่มันเป็นจุดที่เราจะช่วยทำให้ sprint มันเคลียร์ขึ้นตั้งแต่ต้น
โดยที่ยังไม่ได้เริ่มเขียนโค้ดซักบรรทัดเลย
และสิ่งที่เราจะช่วยทีมได้ มันไม่ได้ต้องไปหาจากที่ไหนไกลเลยค่ะ
มันอยู่ในหัวของเราอยู่แล้ว จากงานที่เราทำมาทั้งหมดนี่แหละ
.
พี่กิ่งเชื่อว่าถ้าหน้าที่ของ QA จะต้องเหลือแค่อย่างเดียว
สิ่งนั้นคือ “การถามคำถาม” ค่ะ
ไม่ใช่การถามเพื่อจับผิด แต่เป็นการถามเพื่อให้เกิดบทสนทนาที่จะพาทีมไปข้างหน้าได้
.
QA ร่างทอง ต้องออกจากห้องประชุมด้วยความรู้สึกว่า “เราช่วยให้ sprint นี้เคลียร์ขึ้น”
ไม่ใช่แค่ “เราต้องเทสอะไรบ้าง” 💪
เพราะ “Quality starts with how you think”