ร้อยเรียง Test Scenarios ด้วยการเข้าใจ Business Process และใส่ตัวอย่างให้เห็นภาพตรงกัน #LearningWithSCK
บทความที่เกี่ยวข้อง
- ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่หนึ่ง
- ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่สอง & เกริ่นเข้า Test Scenarios
- Design&Develop Test Scenarios แล้วดำเนินการทดสอบ ดู Expected Result(s) เทียบกับ Actual Result(s)
- วิธีการเปลี่ยนตัวอักษรเป็น Diagram แบบ State Transition
Day 8
- ผู้ส่งมอบความรู้: พี่หนุ่ม ประธาน
- ผู้พยายามรับมอบความรู้: ข้าพเจ้า น้องเอ็ม น้องบี พี่แจ๊ก คุณเล็ก คุณแพร
จากครั้งก่อนที่เราแตก Cases ได้แล้ว เราจะมาร้อยเรียงทำให้เป็น Scenarios กัน เริ่มโดยการตั้ง User ขึ้นมาก่อน User คนนี้เป็นใคร กำหนด Persona ไปก่อน เช่น เป็นลูกค้าของ Product อะไร ประเภทไหน
แล้วค่อยกลับไปถามลูกค้าอีกทีว่า “ใช่ไหม” เป็นการทำงานที่ตั้งสมมติฐานก่อนแล้วค่อยถามไปอีกที (เชิงรุก — Proactive)
การทำงาน เราจะคุยกันทีละชุด ทีละเรื่อง โดยเริ่มจาก
“การได้มาซึ่งแต้ม และใช้งานแต้มได้”
- จากนั้นก็ทำการหยิบเคสจาก Requirements ข้อต่างๆ ที่เกี่ยวข้อง (หยิบอย่างน้อยหนึ่งครั้งมาทำการทดสอบ)
- ตั้งต้นจาก ซื้อสินค้าและชำระเงินสำเร็จ (ถึงจะได้แต้ม) เอาราคามาแปะ เอาแต้มที่จะได้มาแปะ เอาสถานะของแต้มมาแปะ และกำหนด “วันที่-เวลา” ลงไปด้วย
- เมื่อซื้อของเสร็จ ก็จะได้รับสินค้า เอาแต้มที่จะได้มาแปะ เอาสถานะของแต้มมาแปะ และกำหนด “วันที่-เวลา” ลงไปด้วย
- บางทีเราใส่ Actor เพิ่มเข้าไปด้วย ในที่นี้คือ พนักงานส่งสินค้า มาส่งของให้เรา
จะยังไม่มีเรื่องการคลิกหน้าจอใดๆ เข้ามา สิ่งที่กำลังทำคือ การเข้าใจ Business Process ว่า Flow มีการเดินอย่างไร
การได้มาของ Business Process
- ดูจากเอกสาร
- ดูจาก Diagram ต่างๆ เช่น Flowchart
- การสัมภาษณ์
- ลองเล่น
จากนั้นใส่ Examples เข้าไปเลยว่า เข้าใจตรงกันไหม
- เมื่อ ยืนยันการได้รับสินค้า (การใช้คำตรงส่วนนี้ พยายามอย่าเขียนเป็น Action เช่น กดรับสินค้า เพราะมันจะเริ่มเกี่ยวกับหน้าจอ เพราะบางครั้งเราทำสิ่งนี้ก่อน ทีม UX/UI = ไม่ต้องรอให้ Design เสร็จ)
แต้มก็จะเปลี่ยนสถานะเป็น ยืนยันแล้ว
Actor: ลูกค้า ประเภทสมาชิก
Event: ยืนยันการได้รับสินค้า
ทำให้ดึง Requirement เพิ่มมาอีกข้อหนึ่งได้ คือ แต้มจะถูกนับเป็นวันที่ 1 ของอายุ 180 วัน - ซึ่งการเปลี่ยนสถานะ ก่อให้เกิด Output คือ แต้มสามารถใช้เป็นส่วนลดในการซื้อครั้งถัดไป
การใส่ตัวอย่างลงไป ใช้ยืนยันว่า สิ่งที่เจ้าของ Requirement เขียนมาในเอกสาร กับภาพ Flow ที่อยู่ตรงหน้า มันตรงกันอยู่ไหม ซึ่งกว่าจะทำเป็นแบบไหลลื่นคล่องมือ ก็ต้องผ่านการทำซ้ำบ่อยๆ
- เคลียร์ให้ชัดว่า แต้มที่มีอายุ 180 วัน จะไปหมดที่ วันไหน เวลาไหน
- เราได้วันมาแล้ว แต่ เวลาล่ะ จะเป็นเวลาไหน? ก็ต้องถามเจ้าของ Requirement ว่าจะชน 24 ชั่วโมงเต็มหรือเวลาสุดท้าย (23:59 น.) ของวันที่ 180
- หากเลือกจบพอดี 24 ชั่วโมง แปลว่า ระบบต้องมีการเช็ครายนาที ซึ่งผู้ใช้งานไม่ได้มีแค่คนเดียว ถ้ามีสมาชิก 20,000 คน เข้ามาซื้อตอนไหนก็ได้ มากด Activate แต้มตอนไหนก็ได้ มีการลงเวลาหมดอายุที่ต่างกันทุกคน แปลว่า ต้องเช็คของทุกคนทุกนาที
- แต่ถ้าเลือก 23:59 น. แปลว่า ระบบจะเช็คว่าแต้มหมดอายุแล้วหรือยังแค่วันละหนึ่งครั้ง
- คนทำงาน (คนไอที) ให้ข้อมูล แนะนำ Solution แล้วให้เจ้าของ Requirement เป็นคนตัดสินใจว่าจะเลือก Option ใด
- สมมติว่าเจ้าของ Requirement เชื่อคนไอที เลือกแต้มหมดอายุ เวลา 23:59 น.
- เพื่อให้เห็นภาพชัดเจนขึ้น ก็เอา Post-it มาแปะ ว่าอันไหนเป็น Test Data อันไหนที่จะตรวจรับว่า ระบบทำงานถูกต้อง
สร้างความเข้าใจที่ตรงกัน เพื่อลดบั๊ก ลดข้อผิดพลาดที่จะเกิดขึ้นในภายหลัง
การสร้างความเข้าใจที่ตรงกัน
มาจากกลุ่มคนที่มีความเชี่ยวชาญ และมีความเข้าใจใน Business Domain นั้นๆ
และเปลี่ยนการทำงานจาก Test-Last ให้เป็นรูปแบบของ Test-First
ซึ่งสิ่งที่กำลังเรียนรู้อยู่ตอนนี้ ยังคงอยู่ในกรอบสีน้ำเงิน (จากภาพด้านบน)
Day 9
- ผู้ส่งมอบความรู้: พี่หนุ่ม ประธาน
- ผู้พยายามรับมอบความรู้: ข้าพเจ้า น้องเอ็ม น้องบี พี่แจ๊ก คุณเล็ก คุณแพร พี่นุ่น
ระหว่างการเรียบเรียง Business Flow และเงื่อนไขต่างๆ อาจจะมีการตั้งคำถามเพิ่มกลับไปยังเจ้าของ Requirement เช่น ต้องมีการแจ้งเตือน เมื่อแต้มใช้งานได้หรือไม่ อาจจะเจอ เจ้าของความต้องการ บอกว่า ไม่รู้หรือตัดสินใจไม่ได้ แต่ในวงประชุม มันมีคนเข้ามากกว่าหนึ่งคนอยู่แล้ว อาจจะใช้คำถามเดียวกันตั้งคำถามไปยังคนอื่นๆ ที่อยู่ในวงประชุม เพื่อเช็คพฤติกรรมหรือประสบการณ์ของผู้ใช้งานว่า เคยใช้มาเป็นอย่างไรบ้าง หรือ ถ้าเป็นลูกค้าของระบบมีความต้องการแบบไหน เป็นวิธีเร็วสุดที่จะถามความเห็น ซึ่งการตั้งคำถามจะไม่ใช้การชี้นำคำตอบ เป็นคำถามปลายเปิด
หากวงประชุมกล่าวว่า ต้องมีการแจ้งเตือน ก็ตั้งคำถามต่อว่า
- ในการแจ้งเตือนนั้น จะส่งข้อความอะไรออกไป
- แจ้งเตือนผ่านช่องทางใดบ้าง
เพื่อให้เกิดเหตุการณ์แบบนี้ จะตรวจรับว่า ระบบทำงานถูกต้อง จะต้อง Set Persona (หรือ User Test) อย่างไรบ้าง เพื่อให้ตรวจสอบเงื่อนไขต่างๆ ได้ ก็คือ เติม อีเมล เบอร์โทร และ แต้มสะสมทั้งหมดตอนต้นเข้าไป
อิงจากสมการ Test Case = การเตรียมการก่อนดำเนินการทดสอบ + เงื่อนไขที่ถูกทดสอบ + Expected Result + Test Data
- สิ่งนี้เรียกว่า สิ่งที่ต้องเตรียมการก่อนการทดสอบ เพื่อให้ข้อมูลตั้งต้น และ Expected Result เหมือนเดิมเสมอ
- 1 Account Test User คือ 1 Test Scenarios ไม่ใช้ซ้ำ
- ส่งไปเบอร์เดิม อีเมลเดิม ทำให้เราสามารถทดสอบซ้ำๆ เดิมได้ พอทดสอบซ้ำๆ เดิม ก็เหมือนกับเครื่องซักผ้า แทนที่จะต้องซักมือเอง ก็เปลี่ยนให้มันเป็น Automation ซึ่งการทำ Automation ไม่ใช่แค่การหา Tool
- นอกเหนือจากนั้น ก่อนทำการทดสอบ วันที่จะต้องเป็นวันที่เดิมเสมอ ในทางเทคนิคสามารถ เปิด/ปิด โหมดทดสอบได้ ถ้าเป็นโหมดทดสอบ สามารถ Inject เวลาที่เราต้องการเข้าไปได้ ถ้าเป็นโหมดโปรดักชั่นก็ให้ดึงจาก System Date มา ซึ่งสิ่งนี้สามารถทำในโค้ดได้ แต่ต้องทำแต่แรก
- ต้องมี Order ID อะไรที่มีคุณสมบัติ ซื้อสินค้าและชำระเงินสำเร็จ ในราคา 320.00 บาท
สิ่งสำคัญของการทำสิ่งนี้ คือ การทำให้เห็นภาพตรงกัน
ทั้งหมดที่ทำมาตอนนี้ คือ กล่องสีน้ำเงิน
Develop Test Scenarios
ต้องการแบบไหน Automation หรือ Manual ต้องเลือกอย่างใดอย่างหนึ่ง การทำ Manual เยอะมากแล้วค่อยมาทำ Automation ไม่ได้ประโยชน์ เป็นการเสียแรงเปล่า
การไป Test Manual → เปิด Defect Dev แก้แล้ว → แล้วค่อยมาทำ Automate มันไม่ช่วย
การไม่คิดตั้งแต่ต้นว่ามันต้องรันซ้ำได้ จะเกิดปัญหาภายหลัง เช่น ตั้งต้นต้องมีแต้ม 297 พอรันรอบสอง แต้มตั้งต้นกลายเป็น 300 ได้ผลไม่เหมือนเดิม
Automation ต้องถูกรันซ้ำทุกครั้งที่เปลี่ยนแปลงโค้ด ซึ่งจะรันซ้ำหลายครั้งต่อวันก็ได้
เวลาที่ใช้ในการรัน Regression Tests จากวิธีปฏิบัติของ Extreme Programming เราจะใช้ 10 Minute build (ทำให้จบภายใน 10 นาที)
ให้คิดว่าเราจะ Automate ยังไง ไม่ใช่ใช้ Tool อะไร มุมมองเราจะเปลี่ยนไป
