ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่หนึ่ง #LearningWithSCK

ที่มาที่ไปของคลาส

เนื่องจากมีสมาชิกใหม่มาร่วมงานกับ SCK และ We Love Bug จำนวนสองคน ในต้นเดือนพฤศจิกายน 2565 น้องทั้งสองเป็นผู้มีความสนใจ และ/หรือ อยู่ในสายงานของ Software Testing แต่สิ่งที่ได้เรียนรู้หรือติดตัวมา อาจจะไม่สามารถใช้งานได้ในบริบทของ SCK และ We Love Bug จึงเกิดการปูพื้นฐานความรู้ให้ ในทุกเช้าวันจันทร์ พุธ ศุกร์ เวลา 08:00–09:00 น. ซึ่งคนทางนี้ก็อยากเรียนเพื่อเพิ่มเติมความรู้ด้วย ก็เลยขอเข้ามาเอี่ยวกับน้องๆ (หาทำตลอดไป)

Day 1

• ผู้ส่งมอบความรู้: พี่หนุ่ม ประธาน
• ผู้พยายามรับมอบความรู้: ข้าพเจ้า น้องเอ็ม น้องบี

ปูพื้นเรื่อง Software Testing Process ใน SDLC (Software Development Life Cycle)

ความต้องการที่เป็น Functional Requirements ทำการสกัดและหาออกมา ให้มันเป็นข้อๆ จากนั้นก็จะวิ่งเข้าสู่เรื่องของการ Design Test Cases ออกแบบ กรณีการทดสอบ โดยแบ่งออกเป็นสองเทคนิคคือ Blackbox และ Whitebox

สิ่งที่เรารู้ของทั้งสองเทคนิค คือ

1. Test Conditions เงื่อนไขที่จะถูกทดสอบ
2. Expected Result(s) หรือ Expected Output(s) ผลลัพธ์ที่คาดหวัง
3. Input (s) ต้องมีหน้าตาแบบใด

ความต่างของสองเทคนิค

• Blackbox = เราไม่รู้ว่า Programmer จะเปลี่ยนเงื่อนไขนี้ไปเป็น Source Code ยังไง ปกติแล้ว Tester และ คนทำ UAT จะอยู่ที่จุดนี้
• Whitebox = เรารู้ว่า Programmer จะทำอะไร มีการดีไซน์ Flow Chart อย่างไร

เมื่อผ่านสองเทคนิคนี้แล้ว จะได้ Test Cases (กรณีการทดสอบ) หรือ Test Scenarios ซึ่งต้องคุยกันก่อนเริ่มทำว่าแต่ละที่ (แต่ละองค์กร) มีการใช้รูปแบบไหนอยู่

Test Cases กรณีการทดสอบ จะแบ่งเป็นสองกรณีคือ

1. Success กรณีการทดสอบสำเร็จ ปกติจะทำอันน้ีก่อน เพราะเงื่อนไขมันค่อนข้างชัดเจน
2. Unsuccessful/Alternatives กรณีการทดสอบไม่สำเร็จ

สมการของ Test Case

Test Case = Tested Condition + Expected Result(s) + Test Data (Input(s))

• Test Case จะอธิบายถึง Expected Result(s)
• Expected Result(s) จะ ระบุ ค่า (Value) ที่คาดหวัง จาก เงื่อนไขที่ถูกทดสอบ เพื่อตรวจสอบว่า Functional/Method ทำงานได้ถูกต้องตามเงื่อนไขที่กำหนดหรือไม่
• Test Data ข้อมูลที่ใช้ในการทดสอบเงื่อนไข เพื่อตรวจสอบ Expected Results

เทคนิคใน Blackbox

1) Equivalent Partitions (EP) แบ่งเป็นสองฝั่ง Partition (ช่วงของข้อมูล)

2) Boundary Value Analysis (BVA) สนใจค่าขอบของแต่ละช่วง

จากนั้นก็ได้รับโจทย์ การฝากเงินสดที่ร้านสะดวกซื้อ เป็นการบ้านให้ทดลองเขียน Test Cases ด้วยตัวเองว่าแต่ละอันเกิดเคสอะไรได้บ้าง และใช้เทคนิคใด EP หรือ BVA

โดยเริ่มจากการวางแผนใน Miro ก่อน แล้วค่อยไปเขียนใน Google Sheet ทางนี้ก็รีบปั่น เพราะช่วงบ่ายมีประชุมยาวๆ ส่งไปให้ตรวจรอบแรกปุ๊บ ก็โดนปาดแดงปั๊บกลับมา ปาดปื้ดทั้งแผง แบบที่ดูแล้วต้องปาดเหงื่อ โดยได้รับ Comment ว่า

ตรวจดูแล้ว ตรงสีแดงคือที่ต้องปรับ แก้ไข พี่จะไม่ระบุว่าต้องปรับอะไร แต่จะให้กว้าง ๆ ไว้ว่า

1. แต่ละเงื่อนไขที่จะถูกทดสอบ ให้ระบุว่าใช้ เทคนิค ใด ระหว่าง BVA และ EP
2. Test Cases ของ BVA จะประกอบไปด้วย 3 กรณี ในแต่ละเงื่อนไข
3. ข้อที่ 4. ค่าธรรมเนียมการทำธุรกรรม ในช่วงระยะเวลา 6 เดือนที่เปิดให้บริการ คิดตามช่วงอายุ > ลองกลับไปดูว่ามีกี่เงื่อนไที่ต้องถูกทดสอบอยู่ภายในประโยคนี้
4. รูปแบบการแสดงตัวเลขทางการเงิน
5. คำถามที่ต้องถามจาก เจ้าของความต้องการ
6. ตัวเลขที่เกี่ยวข้องกับ เงื่อนไขทางธุรกิจ หรือเงื่อนที่ที่จะถูกทดสอบ ต้องมีที่มาที่ไป

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

รายละเอียดที่ได้เพิ่มสำหรับวันนี้

1. Flow การทำงาน Software Testing Process

เรื่องใหม่ที่ได้รู้ และฝึก

1. ความหมาย ความแตกต่างของ Whitebox, Blackbox และจุดที่อยู่ ว่าอยู่ตรงไหนของ Process
2. ทดลองเขียน EP, BVA ด้วยตัวเอง จากโจทย์น้ำหนักลิฟต์ และการฝากเงิน
3. ได้รับการแนะแนว ชี้แนะถึง TCs ที่หลุดไป เมื่อมี Range เข้ามาเกี่ยวข้อง, มีเงื่อนไขมากกว่าหนึ่งเรื่องใน Rule
4. การเห็นตัวอย่างก่อน (ทำโจทย์ลิฟต์) ทำให้สามารถ Apply กับโจทย์ฝากเงินได้
5. สิ่งที่ไม่ได้ระบุมา ห้าม “มโน” เอง แต่ให้ตั้งคำถามไว้ข้างๆ
6. การทำให้เห็นภาพ ช่วยให้สื่อสารกันได้เข้าใจมากขึ้น

Day 2

• ผู้ส่งมอบความรู้: พี่หนุ่ม ประธาน
• ผู้พยายามรับมอบความรู้: ข้าพเจ้า น้องเอ็ม น้องบี พี่แจ๊ก พี่ป๋อม คุณเล็ก คุณแพร

เนื่องจากมีสมาชิกใหม่เข้ามา พี่หนุ่มเลยใช้เวลาประมาณ​ 22 นาทีในการ Recap และเตรียมการ Google Sheet, Miro ที่จะให้แต่ละคนใช้

จากนั้นก็มาเฉลยการบ้านเรื่องการฝากเงินกันทีละข้อ

1. บัญชีออมทรัพย์ แต่ละประเภทจะมีเงื่อนไขการรับฝากเงินขั้นต่ำ

รายละเอียดที่ได้เพิ่มจากการเฉลยการบ้าน

1. หากโจทย์ไม่ได้ระบุตัวเลขมา เราสามารถใช้คำว่า “ยกตัวอย่างเช่น” เพื่อให้เห็นภาพตรงกันได้ (ตัวเลขจะมาลอยๆ ไม่ได้ ต้องมีที่มาที่ไปว่าเรา “ยกตัวอย่างมา” ไม่ใช่คิดเอาเอง)
2. เวลาเราทำเรื่อง Test Data ให้ใช้ข้อมูล Production-likely หรือ เสมือนพฤติกรรมการทำงานจริงๆ ของผู้ใช้งานหรือระบบ
3. ใช้ภาษาการเขียนให้คนทั่วไปเข้าใจ ไม่ใช่การเขียน True, False

2. ต้องไม่เป็นบัญชีออมทรัพย์ที่ถูกอายัด

รายละเอียดที่ได้เพิ่มจากการเฉลยการบ้าน

1. จะระบุเลขบัญชีลงไปเลย หรือยังไม่ระบุก็ได้ ตอนที่ทำ Test Design
2. แต่ควรระบุ ประเภทบัญชี ธนาคารด้วย ไม่ใช่แค่สถานะของบัญชี

3. ช่วงเวลาที่อนุญาตให้ทำรายการฝาก ได้ 09:00–22:00

รายละเอียดที่ได้เพิ่มจากการเฉลยการบ้าน

1. เนื่องจากมีสองจุดเวลา ให้แยก 09:00 ออกจาก 22:00 โดยเริ่มทำจุดเวลาที่ 09:00 น. ก่อน ก็จะได้เป็นสามเคส แล้วค่อยย้ายไปทำที่เวลา 22:00 ก็จะได้อีกสามเคส รวมเป็นหกเคส
2. ช่วงเวลาตรงกลาง สามารถยุบกรณีที่ 3–4 มารวมกันได้ เพราะเป็นช่วงเวลาตรงกลางที่เปิดทำการคือ 09:00–22:00 แต่! ต้องเกิด “การเห็นชอบและอนุมัติ” จาก เจ้าของความต้องการ และ ทุกคนที่เกี่ยวข้อง “ต้องเห็นชอบ” ด้วย
3. ไม่จำเป็นต้องเป็น Tester คนอื่นก็สามารถทำสิ่งนี้ได้เหมือนกัน

ยังเหลือเฉลยการบ้านอีกหลายข้อ โปรดติดตามตอนต่อไป!

การได้ลงมือเขียน Test Cases เอง ผิดพลาดเอง โดนปาดแดงปื้ดดดดด แล้วต้องแก้ไขเอง มันจำแม่นกว่าการนั่งเรียนเฉยๆ อย่างมากเลยล่ะ