มาใช้ชีวิตให้ง่ายๆ ด้วย Test Techniques กันเถอะ
อยากเป็น QA ที่ใช้ชีวิตง่าย ๆ ไม่ยุ่งยาก ในการคิด test case ก็เอา Test Techniques มาช่วยชีวิตเราสิ
ถ้าพูดถึง Test Techniques แล้ว มันก็คือวิธีการหรือเทคนิคที่จะมาช่วย QA ในการออกแบบ test cases หรือทดสอบโปรแกรมให้ครอบคลุมดียิ่งขึ้น เพื่อลดความผิดพลาดบางจุดที่เราอาจจะมองข้ามไป งั้นเรามาทำความรู้จักกับเทคนิคต่าง ๆ กันเลยยย
Equivalent Partitioning
Equivalent Partitioning คือ การแบ่งกลุ่มของการทดสอบออกเป็น 2 กลุ่มใหญ่ ๆ คือ กลุ่ม valid กับ กลุ่ม invalid หรือกลุ่ม positive กับ กลุ่ม negative โดยข้อมูลหรือสิ่งที่อยู่ในกลุ่ม ๆ นั้น จะถูกมองว่ามีค่าเท่ากัน
ตัวอย่าง บริษัทประกันแห่งหนึ่ง จะรับทำประกันในกรมธรรม์ B+ ให้กับลูกค้าที่มีอายุระหว่าง 5 — 65 ปี
จากโจทย์ตัวอย่าง ถ้าใช้วิธี Equivalent Partitioning จะสามารถแบ่งข้อมูลสำหรับการทดสอบได้เป็น 3 ช่วง คือ
เราก็จะได้ partition ออกมาเป็น 3 กลุ่ม คือ
partition 1 : อายุน้อยกว่า 5 ปี
partition 2 : อายุระหว่าง 5 — 65 ปี
partition 3 : อายุมากกว่า 65 ปีขึ้นไป หรือ อายุตั้งแต่ 66 ปีขึ้นไป
แล้วในแต่ละ partition เราจำเป็นจะต้องทดสอบยังไงละ? ต้องทดสอบทุกข้อมูลในแต่ละ partition เลยไหม? ถ้าทุกคนยังจำได้ ตัว Eqivalent Partitioning บอกว่า “ข้อมูลหรือสิ่งที่อยู่ในกลุ่ม ๆ นั้น จะถูกมองว่ามีค่าเท่ากัน” นั่นหมายความว่า เราจะทดสอบเพียงแค่ 3 ค่าเท่านั้น จากแต่ละ partition ก็จะถือว่าครอบคลุมตามเทคนิคนี้แล้ว ตัวอย่างเช่น
partition 1 : ข้อมูลที่จะใช้ทดสอบ คือ 3
partition 2 : ข้อมูลที่จะใช้ทดสอบ คือ 30
partition 3 : ข้อมูลที่จะใช้ทดสอบ คือ 80
Boundary Value Analysis
Boundary Value Analysis จะมีความคล้าย ๆ กับ Equivalent Partitioning ตัว Boundary Value Analysis ก็จะมีการแบ่งกลุ่มการทดสอบเหมือนกัน แต่จะมีส่วนที่ต่างกัน คือ Boundary Value Analysis จะเป็นการใช้ข้อมูลหรือการทดสอบเป็นขอบ หรือการทดสอบแบบขอบบน — ขอบล่าง
ตัวอย่าง บริษัทประกันแห่งหนึ่ง จะรับทำประกันในกรมธรรม์ B+ ให้กับลูกค้าที่มีอายุระหว่าง 5–65 ปี
จากรูป ถ้าใช้ Boundary Value Analysis เราก็จะได้จำนวน cases หรือจำนวนข้อมูลที่เราจะเอาใช้ทดสอบ คือ 4, 5, 6, 64, 65 และ 66 ก็จะถือว่าการทดสอบครอบคลุมตามเทคนิคนี้แล้ว แต่ถ้าลองพิจารณาดูแล้ว ทำไมเราถึงได้ชุดการทดสอบเป็น 4, 5, 6, 64, 65 และ 66 ละ ลองกลับไปพิจารณาโจทย์กันอีกรอบ โดยโจทย์บอกว่า “จะรับทำประกันให้ลูกค้าที่มีอายุ 5–65 ปี” นั่นหมายความว่า ข้อมูลที่อยู่ตรงขอบที่กั้นระหว่าง valid กับ invalid ก็คือ 5 และ 65 ถ้าเราเลือกแค่เฉพาะ 2 ชุดนี้ เราก็จะได้แค่การทดสอบสำหรับ valid case และมันก็จะไม่ครอบคลุมการทดสอบสำหรับ invalid case นะซิ แล้วทำยังไงละ? เราก็ต้องพิจารณาการทดสอบเพิ่มเติมจากขอบของข้อมูลที่เราได้มาแล้ว โดยให้เลือกชุดการทดสอบเพิ่มจากสิ่งที่อยู่ใกล้ ๆ กับขอบของข้อมูลที่มีอยู่ หรือจะบอกง่าย ๆ ว่าให้เอาขอบที่มีอยู่มา +/- เพื่อหาขอบบน — ขอบล่าง เช่น เรามีขอบ คือ 5 ให้เอา 5 มาบวกเพิ่มอีก 1 เราก็จะได้ขอบบน คือ 6 และถ้าเราเอา 5 มาลดลง 1 เราก็จะได้ขอบล่าง คือ 4 เป็นต้น
Decision Table
Decision Table ก็คือการเอาเงื่อนไขต่าง ๆ ที่จะเกิดขึ้นได้ มาทำในรูปแบบของตารางการตัดสินใจ หรือก็คือการ combinations ของเงื่อนไข โดย Decision Table จะมีหน้าตา ดังรูป
ตัวอย่าง ถ้าลูกค้าซื้อสินค้าเกิน 10 ชิ้น และราคาสินค้ารวมเกิน 10,000 บาท ระบบจะให้ส่วนลดลูกค้า 10%
จากโจทย์ตัวอย่าง ถ้าใช้วิธี Decision Table จะได้ชุดการทดสอบ ดังนี้
เราก็จะได้ชุดการทดสอบที่เกิดขึ้นทั้งหมด 4 ชุดการทดสอบ คือ
- ซื้อเกิน 10 ชิ้น และราคารวมไม่เกิน 10,000 บาท
- ซื้อเกิน 10 ชิ้น และราคารวมเกิน 10,000 บาท
- ซื้อไม่เกิน 10 ชิ้น และราคารวมไม่เกิน 10,000 บาท
- ซื้อไม่เกิน 10 ชิ้น และราคารวมเกิน 10,000 บาท
State Transition
State Transition เป็นเทคนิคที่จะช่วยให้เห็น flow การทำงานรวมระบบ รวมถึง action ต่าง ๆ ที่เกิดขึ้น ซึ่งจะทำให้เรารู้ว่าในแต่ละ state ที่เราทำไป ทำให้เกิดอะไรขึ้นบ้าง โดยหลัก ๆ แล้ว องค์ประกอบของเทคนิคนี้ จะมีอยู่ด้วยกัน 4 องค์ประกอบ คือ
- Start State คือ สถานะเริ่มต้น
- Target State คือ สถานะปลายทาง
- Action คือ สิ่งที่กระทำให้เกิดการเปลี่ยนสถานะ
- Output คือ ผลลัพธ์ที่เกิดขึ้น เมื่อเกิดการเปลี่ยนสถานะ
ตัวอย่าง ในการใช้งาน otp ลูกค้าสามารถระบุ otp ผิดได้ไม่เกิน 5 ครั้ง ถ้าเกิดลูกค้าระบุผิดเกิน 5 ครั้ง ระบบจะ freeze การใช้งาน otp ของลูกค้าเป็นเวลา 1 ชั่วโมง
จากตัวอย่าง เราก็จะได้ State ดังนี้
จาก State ข้างต้น แสดงให้เห็นว่า จะเกิด cases ทั้งหมด 6 cases
- ลูกค้าใส่ otp ถูกครั้งแรกเลย
- ลูกค้าใส่ otp ผิดครั้งที่ 1 แต่ใส่ถูกครั้งที่ 2
- ลูกค้าใส่ otp ผิดครั้งที่ 1 และครั้งที่ 2 แต่ใส่ถูกครั้งที่ 3
- ลูกค้าใส่ otp ผิดครั้งที่ 1, 2 และครั้งที่ 3 แต่ใส่ถูกครั้งที่ 4
- ลูกค้าใส่ otp ผิดครั้งที่ 1, 2, 3 และครั้งที่ 4 แต่ใส่ถูกครั้งที่ 5
- ลูกค้าใส่ otp ผิดครบ 5 ครั้ง
จนถึงตอนนี้แล้ว ทุกคนอาจจะมองว่าสิ่งที่เล่ามาและยกตัวอย่างมาเป็นตัวอย่างที่ดูง่าย ๆ และไม่ยุ่งยากซับซ้อนอะไรเลย ไม่เห็นเหมือนในชีวิตการทำงานจริงเลยที่เจอ requirement ที่เยอะ ซับซ้อน และยุ่งยาก เราเพียงแค่ให้ทุกคนเข้าใจภาพและวิธีการของแต่ละเทคนิคก่อน ถ้าทุกคนเข้าใจภาพของเทคนิคนั้นดีจริง ๆ แล้ว ต่อให้เราเจอ requiremnt รูปแบบไหนก็ตาม เราก็จะสามารถผ่านมันไปได้สบาย ง่าย ๆ ไม่มีคำว่ายาก ยากเกิน และยากเกินไป
เมื่อได้รับ requirement มาแล้ว ในการคิด test case แต่ละครั้ง ควรนำ test techniques หลาย ๆ เทคนิคมาประยุกต์ใช้ร่วมกัน เพื่อให้การคิด test case มีประสิทธิภาพและครอบคลุมสิ่งที่จะสามารถเกิดขึ้นได้ทั้งหมด
สำหรับบทความนี้ขอฝากไว้เพียง 4 เทคนิคก่อนนะทุกคน ไว้เจอกันใหม่ในเทคนิคอื่นๆ ในบทความหน้านะ