Basic Test Scenario แบบเข้าใจง่ายใน5นาที

Test Scenario คือ ตารางข้อมูลการทดสอบระบบ ที่บันทึกข้อมูลที่จำเป็นในการทดสอบ และ ผลการทดสอบ ซึ่งปกติจะจัดทำโดย QA (Quality Assurance) แต่สามารถประยุกต์ใช้ได้ในหลายสถานการณ์

ประโยชน์และหน้าที่ของ Test Scenario

• เป็นเครื่องมือในการวางแผนการทดสอบของ QA ทำให้ QA สามารถใช้เวลาในระหว่างที่ Developer กำลังพัฒนา Feature ในการคิดและออกแบบแผนการทดสอบสำหรับ Feature นั้น เพราะการคิดวางแผนไว้ล่วงหน้า และลงมือทำตามแผนเมื่อถึงเวลา จะมีความถูกต้องและรวดเร็วมากกว่าการทำงานโดยไม่มีแผน หรือคิดไปทำไป
• เป็นเครื่องมือในการ Recheck ความถูกต้องของ Developer หลังจากการพัฒนา Feature เสร็จสิ้น จะสามารถเปิด Test Scenario ของ QA เพื่อ Recheck ได้ หรืออาจจะเปิดดูระหว่างการพัฒนาก็ได้ เพื่อตรวจสอบความถูกต้องของ Feature ที่พัฒนา หรือตรวจสอบความเข้าใจว่าเข้าใจตรงกันหรือไม่
• เป็น Case ที่ให้ Developer สามารถนำไปเขียน Unit Test เพื่อให้การทดสอบครอบคลุมได้มากยิ่งขึ้น
• เป็นเครื่องมือเตือนความจำ ว่ามีการวางแผนใดไปบ้าง ไปถึงจุดไหน หรือ เตือนความจำว่า ตรวจสอบระบบไปถึงจุดไหนแล้ว เพื่อให้ไม่ผิดพลาดซ้ำซ้อน ตรวจวนไปวนมาไม่จบเพราะลืมว่าเคยลอง Case นี้ไปแล้ว
• เป็นหลักฐาน ยืนยันความถูกต้อง ที่บันทึกพฤติกรรมโดยละเอียดของระบบ ซึ่งในระบบที่ใหญ่มาก และใช้เวลาในการพัฒนาเป็นเวลานาน ทำให้ Feature ที่ถูกพัฒนาไปตอนแรกอาจจะมีการลืมพฤติกรรม หรือ มีพฤติกรรมเปลี่ยนไปโดยไม่ได้ตั้งใจ เราจะสามารถตรวจสอบ Test Scenario เก่าเพื่อยืนยันได้ว่าเมื่อเริ่มพัฒนาพฤติกรรมเป็นอีกแบบหนึ่งหรือไม่
• เป็นคู่มืออย่างละเอียด สำหรับผู้เกี่ยวข้องในระบบ เช่น เพื่อนร่วมทีม, ทีม Support หรือทีมพัฒนาอื่นๆ ที่ทำงานร่วมกัน จะสามารถใช้ Test Scenario เป็นคู่มือได้

Given

• สถานการณ์ปัจจุบัน
• การตั้งค่าต่างๆ เพื่อที่จะ Test
• ไม่ใช่การบอกว่ากำลังจะ Test อะไร เช่น “ทดสอบระบบ Login” แบบนี้ไม่ได้ แต่ถ้าจะใส่เป็นหัวข้อไว้ แล้วตามด้วยการตั้งค่าตามปกติ ก็เข้าใจได้
• ถ้าทำงานร่วมกับหลายๆ ทีม หรือภายนอก ต้องเขียนอย่างละเอียด
• ถ้าทำงานกับคนที่คุ้นเคยฝีมือ ทีมเดียวกัน ที่มีความรู้ความเข้าใจใน App นั้นมาก สามารถ Assume ว่าบางอย่างทำแล้วได้ เพื่อการไม่สิ้นเปลืองและรก เช่น บาง Action ต้องการการ Login อยู่แล้ว เราก็อาจจะไม่เขียนซ้ำซ้อน ว่า ต้อง Login เราก็จะ Focus ที่การตั้งค่าอื่นๆ ที่จำเป็นเลย

When

• การกระทำก่อนที่จะเกิดผลลัพธ์
• บางครั้งอาจจะระบุรายละเอียดเพิ่มเล็กน้อย เช่น “กดที่ปุ่ม Submit”

Then

• สิ่งที่เกิดขึ้นหลังจาก When
• สิ่งที่เราสนใจ คาดหวังว่าต้องเกิดขึ้น หรือต้องไม่เกิดขึ้น
• สามารถเกิดขึ้นได้หลายอย่าง
• อะไรที่ test ไปแล้วใน case ก่อนหน้า ถ้าไม่จำเป็น ไม่ต้องใส่ซ้ำ

QA

• สถานะของ Case นั้นๆ ว่าผ่าน หรือไม่ผ่าน หรือมี Comment อย่ Iางไร อาจจะเพิ่ม Unit Column ให้ Developer Check เมื่อนำไปเขียน Unit Test แล้ว เพื่อให้ QA ไม่จำเป็นต้องเขียน Automation Test ซ้ำซ้อน

สิ่งที่นำมาเขียน Test Scenario จะได้มาจาก Acceptance Criteria ในเบื้องต้น และอาจจะเพิ่มรายละเอียดที่เหมาะสมแตกย่อยละเอียดเข้าไปอีกได้

ตัวอย่างการเขียน Test Scenario ของกล่อง Post เหมือนใน Twitter ที่หน้า Home โดยมี Requirement ว่า

• เมื่อกรอกข้อมูลไม่เกิน 280 ตัวอักษร จะสามารถกด tweet ข้อความไปยังหน้า Home ได้
• ไม่สามารถกด tweet ได้ ถ้ายังไม่กรอกข้อความ
• Place Holder จะหายไปเมื่อกรอกข้อความ
• แสดงสัญลักษณ์บอกสถานะของจำนวนข้อความในกล่องปัจจุบันเมื่อมีการกรอกข้อความ
• ไม่สามารถกด tweet ได้ เมื่อกรอกข้อความเกิน 280 ตัวอักษร
• สามารถกด tweet ได้ หลังจากแก้ไขข้อความให้สั้นลง

จาก requirement หลวมๆ เราอาจจะเขียน Test Scenario ได้ ดังนี้ Click

หัวข้อสีดำ จะทำให้เรารู้ว่าต้องการทดสอบ Case ใดเรื่องอะไร

ข้อมูลอื่นๆ ในแต่ละ Column คือการทดสอบว่า พฤติกรรมของระบบเป็นไปตาม Case นั้นจริงๆ

การตั้งชื่อหัวข้อสีดำให้มีความสัมพันธ์กับสิ่งที่ทดสอบ มีความสำคัญมาก เพราะเมื่อเวลาผ่านไป แล้วเรากลับมาตรวจสอบพฤติกรรมของ Feature เก่าๆ จะทำให้เราสามารถอ่านเข้าใจได้ไวว่าพฤติกรรมของ Feature เป็นอย่างไร โดยไม่ต้องอ่านข้อมูลการทดสอบทั้งหมด (เหมือนการเขียนคู่มือที่อ่านง่ายไว้)

หากเขียนไว้ไม่ดี หรือไม่ได้เขียน จะทำให้เราต้องนั่งอ่านขั้นตอนการทดสอบทั้งหมด เพื่อหาความหมายว่าผู้ทดสอบกำลังทดสอบอะไรอยู่ (ประสบการณ์ตรง)

การทำงานทุกอย่าง ควรคำนึงถึงผู้อ่านด้วย ว่าอ่านรู้เรื่องหรือไม่ หรือแม้กระทั่งคนทำเอง ถ้าเวลาผ่านไปแล้วกลับมาดูงานของตัวเองจะสามารถเข้าใจได้ง่ายหรือไม่

สำหรับผู้ที่ไม่มีประสบการณ์ อาจจะลองเขียน Test Scenario ของอะไรก็ได้ ใกล้ๆ ตัว เช่น Facebook Post , Line , Pantip หรือ แม้กระทั่ง ตู้กดน้ำอัตโนมัติ, ATM, อะไรก็ได้ ไม่จำกัดว่าจะต้องเป็น Software เสมอไป