จากหนังสือ Fifty Quick Ideas to Improve your TESTS
ได้แนะนำวิธีปรับปรุงชุดการทดสอบให้มีประสิทธิภาพมากยิ่งขึ้น
โดยหนึ่งในนั้น คือ
ชุดการทดสอบควรเริ่มจากการอธิบายว่า
จะทดสอบอะไร (What) หรือ พฤติกรรมการทำงานของระบบตาม Use case
มากกว่าการลงรายละเอียดของการทำงานจริง ๆ (How)
อ่านดูแล้วอาจจะงงบ้าง ไม่มากก็น้อย
ดังนั้น มาดูในรายละเอียด และ ตัวอย่างกันดีกว่า
ความผิดพลาดที่มักเกิดขึ้น สำหรับการเขียน Acceptance criteria
การพัฒนาระบบงาน ในแต่ละ feature/user story นั้น
จะต้องมีข้อตกลงในการตรวจรับ หรือ acceptance criteria เสมอ
เพื่อใช้กำหนดว่าในแต่ละ feature/user story นั้นเสร็จ หรือ Done เป็นอย่างไร
ไม่ต้องมานั่งเดา กันอีกต่อไป !!!
แต่ข้อผิดพลาดมักเกิดขึ้นกับทีมที่ไม่มีประสบการณ์มากนัก
นั่นก็คือ มักจะเขียน acceptance criteria แบบเยอะ ๆ คือ
- เราจะทำการทดสอบอะไรบ้าง ?
- แต่ละการทดสอบจะต้องทดสอบอย่างไรบ้าง ?
เขียนทั้งสองอย่างไปพร้อม ๆ กัน
ส่งผลให้เราไม่ focus กับสิ่งที่คุยกัน
นั่นคือ เรากำลังจะสร้าง feature อยู่นะ
สุดท้ายเกิดอาการออกทะเล หรือ ใช้เวลาในการคุยกันนานมากมาย !!!
คุณเคยตกอยู่ในสถานการณ์เช่นนี้ไหม ?
มาดูตัวอย่างของความผิดพลาดกันดูบ้าง
หลาย ๆ ทีมเริ่มเขียน Acceptance criteria ตามแนวคิดของ
- ATDD (Acceptance Test-Driven Development)
- BDD (Behaviour Driven Development)
- SBE (Specification By Example)
ซึ่งมันสามารถนำไปทดสอบแบบอัตโนมัติได้ทันที
โดยรูปแบบการเขียนมีหลากหลายมาก ๆ
หนึ่งในนั้นคือ Given-When-Then
ดังนั้นมาดูตัวอย่างที่ผิด ๆ กันดีกว่า
ซึ่งทำการเขียนลงรายละเอียดเลยว่า ระบบทำงานอย่างไร
ซึ่งมันน่ากลัวมากมาย !!!
จากตัวอย่าง เหมือนมันจะดูนะ หรือคิดว่าอย่างไร ?
มันมีขั้นตอนละเอียดมากมาย
สุดท้ายที่เราต้องการจริง ๆ คือ ในบัญชีเหลือ 300 บาท
หลังจากการซื้อตั๋ว 1 ใบ
แต่ทำไมเราเขียนเยอะแยะจังเลย ทั้ง
- การ click
- การ reload
ทั้งหมดที่เขียนทำการทดสอบแบบเฉพาะเจาะจงมากจนเกินไป
ลองคิดดูสิว่า
ถ้าเราต้องทำการทดสอบหลาย ๆ เงื่อนไข จะลำบากหรือไม่ ?
ถ้ามีการเปลี่ยนแปลงขั้นตอนการทำงานของระบบ จะลำบากหรือไม่ ?
ถ้ามีขั้นตอนใดขั้นตอนหนึ่งเกิดผิดพลาดขึ้นมา จะตามหาจุดผิดได้ง่าย หรือ ยาก ?
เอกสารชุดนี้มันคือ การทดสอบแบบ End-to-End จริง ๆ หรือไม่ ?
เราลงในรายละเอียดของการสร้างระบบ และ การทำงานของระบบมากจนเกินไป
จนทำให้เราหลงลืมไปว่า
เรากำลังคุยเรื่อง feature/user story ที่กำลังสร้างนะ
ดังนั้น แนะนำให้หลีกเลี่ยงในรายละเอียดของการทำงานแบบนี้ซะ
เพราะว่า มันอธิบายว่าเราทดสอบอย่างไร นั่นเอง
ให้ปลี่ยนมาเป็น เราจะทดสอบอะไรดีกว่า !!
ตัวอย่างที่น่าจะดีกว่าเดิม เป็นดังนี้
ลองคิดดูสิว่า
มันน่าจะดีกว่าเดิมใช่ไหม ?
แถมมันง่ายต่อการพูดคุยกันอีกนะ
เช่น ต้องการทดสอบ เมื่อเงินในบัญชีไม่เพียงพอ
แล้วต้องทำการ reject การสั่งซื้อนั้น ๆ
หลังจากนั้นเงินในบัญชีต้องไม่ถูกตัด
เห็นไหมว่า ?
เมื่อเราลดสิ่งที่ไม่จำเป็น หรือ สิ่งที่รบกวน หรือ สิ่งที่ไม่เกี่ยวข้องออกไปแล้ว
มันทำให้เห็นขอบเขต และ รายละเอียดของ feature/user story นั้นชัดเจน
ส่งผลให้การพูดคุยมีประสิทธิภาพมากยิ่งขึ้น
ผลที่ตามมาอีกอย่าง คือ
เราสามารถแยกการทดสอบในกรณีต่าง ๆ ออกจากกันได้ง่าย
นั่นช่วยให้เราดูแลรักษาชุดการทดสอบได้ง่ายขึ้นไปอีก
คุณเคยปวดหัวกับการแก้ไขชุดการทดสอบ
เมื่อมีการเปลี่ยนแปลง requirement หรือ การพัฒนาหรือเปล่าล่ะ ?
คำถาม แล้วไม่สนใจในรายละเอียดบ้างหรือไง ?
คำตอบ
ต้องสนใจสิครับ ทิ้งไม่ได้เลย
ดังนั้นสิ่งที่ต้องทำคือ แยกการประชุมออกเป็น 2 การประชุม คือ
- คุยเรื่อง What มันคุ้น ๆ นะ เหมือน Sprint planning part 1 ใน Scrum เลย ?
- คุยเรื่อง How มันคุ้น ๆ นะ เหมือน Sprint planning part 2 ใน Scrum เลย ?
ลองกลับไปดูสิว่า
คุณเขียนชุดการทดสอบ และ acceptance criteria อย่างไรกันบ้าง ?
