แนะนำการเขียน Test ที่มีประสิทธิภาพ เน้นว่าจะทดสอบอะไรก่อนเสมอ

จากหนังสือ 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

ดังนั้นมาดูตัวอย่างที่ผิด ๆ กันดีกว่า
ซึ่งทำการเขียนลงรายละเอียดเลยว่า ระบบทำงานอย่างไร
ซึ่งมันน่ากลัวมากมาย !!!

	Scenario: Basic flow
	Given the user mike log in
	And the user click on “Deposit”
	And the page reload
	Then the page is “Deposit”
	And the user click on “1000 THB”
	And the page reload
	Then the page is “Card Payment”
	When the user enter a valid card number
	And the user click on “Submit”
	And the payment id approved
	And the page reload
	Then the page is “Account”
	And the account field show “1000 THB”
	And the user click on “Find Tickets”
	and the page reload
	Then the page is “Tickets”
	And the price is “700 THB”
	And the user click on “Buy Tickets”
	Then the purchase is approved
	And the page reload
	And a ticket confirmation number is displayed
	And the account field show “300 THB”

จากตัวอย่าง เหมือนมันจะดูนะ หรือคิดว่าอย่างไร ?
มันมีขั้นตอนละเอียดมากมาย
สุดท้ายที่เราต้องการจริง ๆ คือ ในบัญชีเหลือ 300 บาท
หลังจากการซื้อตั๋ว 1 ใบ

แต่ทำไมเราเขียนเยอะแยะจังเลย ทั้ง

• การ click
• การ reload

ทั้งหมดที่เขียนทำการทดสอบแบบเฉพาะเจาะจงมากจนเกินไป

ลองคิดดูสิว่า
ถ้าเราต้องทำการทดสอบหลาย ๆ เงื่อนไข จะลำบากหรือไม่ ?
ถ้ามีการเปลี่ยนแปลงขั้นตอนการทำงานของระบบ จะลำบากหรือไม่ ?
ถ้ามีขั้นตอนใดขั้นตอนหนึ่งเกิดผิดพลาดขึ้นมา จะตามหาจุดผิดได้ง่าย หรือ ยาก ?
เอกสารชุดนี้มันคือ การทดสอบแบบ End-to-End จริง ๆ หรือไม่ ?

เราลงในรายละเอียดของการสร้างระบบ และ การทำงานของระบบมากจนเกินไป
จนทำให้เราหลงลืมไปว่า
เรากำลังคุยเรื่อง feature/user story ที่กำลังสร้างนะ

ดังนั้น แนะนำให้หลีกเลี่ยงในรายละเอียดของการทำงานแบบนี้ซะ
เพราะว่า มันอธิบายว่าเราทดสอบอย่างไร นั่นเอง
ให้ปลี่ยนมาเป็น เราจะทดสอบอะไรดีกว่า !!

ตัวอย่างที่น่าจะดีกว่าเดิม เป็นดังนี้

	Scenario: Pre-paid account purchase
	Given a user with “1000 THB” in a pre-paid account
	When the user attemp to buy a “700 THB” ticket
	Then the purchase is approved
	And the user is left with “300 THB” in the account

ลองคิดดูสิว่า
มันน่าจะดีกว่าเดิมใช่ไหม ?
แถมมันง่ายต่อการพูดคุยกันอีกนะ
เช่น ต้องการทดสอบ เมื่อเงินในบัญชีไม่เพียงพอ
แล้วต้องทำการ reject การสั่งซื้อนั้น ๆ
หลังจากนั้นเงินในบัญชีต้องไม่ถูกตัด

	Scenario: Reject Pre-paid account purchase
	Given a user with “500 THB” in a pre-paid account
	When the user attemp to buy a “700 THB” ticket
	Then the purchase is rejected
	And the user is left with “500 THB” in the account

เห็นไหมว่า ?
เมื่อเราลดสิ่งที่ไม่จำเป็น หรือ สิ่งที่รบกวน หรือ สิ่งที่ไม่เกี่ยวข้องออกไปแล้ว
มันทำให้เห็นขอบเขต และ รายละเอียดของ feature/user story นั้นชัดเจน
ส่งผลให้การพูดคุยมีประสิทธิภาพมากยิ่งขึ้น

ผลที่ตามมาอีกอย่าง คือ

เราสามารถแยกการทดสอบในกรณีต่าง ๆ ออกจากกันได้ง่าย
นั่นช่วยให้เราดูแลรักษาชุดการทดสอบได้ง่ายขึ้นไปอีก

คุณเคยปวดหัวกับการแก้ไขชุดการทดสอบ
เมื่อมีการเปลี่ยนแปลง requirement หรือ การพัฒนาหรือเปล่าล่ะ ?

คำถาม แล้วไม่สนใจในรายละเอียดบ้างหรือไง ?

คำตอบ
ต้องสนใจสิครับ ทิ้งไม่ได้เลย

ดังนั้นสิ่งที่ต้องทำคือ แยกการประชุมออกเป็น 2 การประชุม คือ

1. คุยเรื่อง What มันคุ้น ๆ นะ เหมือน Sprint planning part 1 ใน Scrum เลย ?
2. คุยเรื่อง How มันคุ้น ๆ นะ เหมือน Sprint planning part 2 ใน Scrum เลย ?

แนะนำการเขียนรายงาน