เมื่อต้องไปสอนนักศึกษาเขียน Robot framework — Day 1 (Part 2/2)
บทความในชุดเดียวกัน
- เมื่อต้องไปสอนนักศึกษาเขียน Robot framework — Day 1 Testing Fundamental (Part 1/2)
- เมื่อต้องไปสอนนักศึกษาเขียน Robot framework — Day 1 Testing Fundamental (Part 2/2)
- เมื่อต้องไปสอนนักศึกษาเขียน Robot framework — Day 3 How to Web Element Locator (Part 1/2)
- เมื่อต้องไปสอนนักศึกษาเขียน Robot framework — Day 3 How to Web Element Locator (Part 2/2)
Blog ที่แล้วก็พูดเรื่องทักษะพื้นฐานที่ Tester ควรมีไปบางส่วนแล้วนะคะ ทีนี้เรามาดูส่วนที่เหลือกันว่ามีอะไรอีกบ้าง
Test case VS Test scenario
Test case — กรณีที่ใช้ในการทดสอบ
จะอิงกับ Business requirement ที่เราได้จากการเริ่มเก็บ Requirement จากลูกค้าหรือ User โดยที่ Test case จะต้องมีการกำหนดสถานการณ์จำลองให้ครอบคลุม
Test Scenario — ขั้นตอนในการทดสอบ
ยกตัวอย่างเช่น User ต้องกรอกข้อมูลลงในฟิลด์ก่อน แล้วคลิกปุ่ม submit นั่นเอง ซึ่งเอกสาร Test script จะเป็นตัวที่บ่งบอกผลการทดสอบระบบทั้งหมด
ความสัมพันธ์ระหว่าง Test scenario และ Test case จะเป็นแบบ One to many หรือพูดง่ายๆก็คือ Test scenario สามารถนำไปแตกย่อยได้หลาย Test case นั่นเอง
ทำไมต้องมี Test case
ที่ต้องมี Test case ก็เพื่อให้เป็นมาตรฐานและแนวทางในการทดสอบระบบ โดย Test case จะต้องถูกต้อง ตาม Requirement และ Condition ที่ถูกกำหนดไว้นั่นเอง
Test case ที่ดี ไม่ต้องมีจำนวนเยอะ แต่ต้องครอบคลุม
นี่คือสิ่งสำคัญสำหรับการเขียน Test case นะคะ จำนวนไม่สำคัญเท่ากับว่าเราเขียนครอบคลุมรึป่าว เพราะถึงมีจำนวนเยอะก็ไม่ได้แปลว่าจะครอบคลุมถูกไหมคะ อันนี้ต้องจำให้แม่นน๊า
Structure : Test case
โดยปกติแล้ว Test Case ที่มีรูปแบบอย่างเป็นทางการจะต้องประกอบไปด้วย 3 ส่วนหลัก ๆ ดังต่อไปนี้
- ข้อมูลทั่วๆไป : Test case ซึ่งประกอบไปด้วยหมายเลข ผู้สร้าง เวอร์ชัน ชื่อ วัตถุประสงค์หรือรายละเอียดโดยย่อ เป็นต้น
- กิจกรรม (Activity) : Test case ประกอบด้วยข้อมูลสภาพแวดล้อมที่เกี่ยวข้องกับการทดสอบ Pre-Post condition, Test step รวมไปถึง Test data
- ผลลัพธ์ (Results) : เป็นข้อมูลที่ประกอบไปด้วยผลลัพธ์ที่คาดไว้และผลลัพธ์ที่แท้จริงจากการทำงานของระบบ และ Test case ที่กำหนดไว้
Test case ที่ดีนั้น…
- ต้องมีความชัดเจน
- ต้องเป็นไปตามลำดับการทำงานที่เกิดขึ้นจริงจากผู้ใช้ระบบ
- เลี่ยงการทำงานที่ซ้ำซ้อน
- ต้องมีการกำหนดชื่อหรือหมายเลขไว้ ทั้งนี้เพื่อให้สามารถจำแนกความแตกต่างได้ง่ายหรือสามารถนำไปใช้อ้างอิงในภายหลัง
- ควรมีการจัดลำดับความสำคัญไว้เสมอ
- ถ้าใช้งานบ่อยๆ ควรจัดรวบรวมไว้ในรูปของ Test suite
- ต้องใช้ร่วมกับเทคนิคการทดสอบต่าง ๆ เพื่อให้ผลลัพธ์ของการทดสอบเป็นไปอย่างถูกต้อง
Test case template
ต่อไปเรามาดูตัวอย่าง Template ของ Test case กันบ้างเนาะ ตัวอย่างนี้จะเป็น Template ที่เราให้จริงๆ แต่ก็อาจจะมีลด-เพิ่มบ้างตามการทำงานนะคะ
- Test case ID : ตัวเลขที่เอาไว้จัดลำดับ Test case
- Test description : คำอธิบายสั้นๆเกี่ยวกับ Testcase
- Test data : ข้อมูลที่เราจะใช้ในการทดสอบ
- Test steps : ขั้นตอนในการทดสอบ
- Expected result : ผลที่คาดว่าจะได้รับจากการทดสอบตามเงื่อนไขของความต้องการนั้นๆ
- Actual result : ผลจากการเทสจริง
- Test result (Pass/Fail) : ผลการเทสว่าผ่านหรือไม่ผ่าน
- Data : เวลาที่เทสล่าสุด
- Remark : เอาไว้โน๊ตเพิ่มเติม
**จริงๆแล้ว Expected result & Actual result ต้องตรงกันน๊า เพราะมันคือผลที่คาดหวังกับผลที่ได้
กรณีมี Tester หลายคน ก็เพิ่มช่อง Create by อีกช่องก็ได้นะ จะได้รู้ว่าใครเป็นคนทำเคสนี้ แล้วก็กรณีมี UI ก็เพิ่มช่อง Screen capture เพื่อใส่รูปได้จ้า
วิธีการ Test มีอยู่ 2 แบบหลักๆ
Manual test
Manual Test เป็นเหมือนการจำลองว่าเราคือ User ต้องกรอกข้อมูล ทำรายการทีละขั้นตอนตาม Test steps (ถ้าเป็นระบบใหญ่ มี process การทำงานเยอะล่ะก็ ถึงขั้นมือหงิกกันเลยทีเดียว)
Automation test
คือการ Test โดยใช้ Tool ช่วยในการเทสทำงานด้วยตัวของมันเอง ซึ่งจะช่วยลดเวลาในการ Manual Test แต่อาจจะต้องมีการใช้ Coding เพื่อเขียน Script ที่ใช้สำหรับ Run นั่นเองจ้า
ส่วนเรื่อง Automate test มีรายละเอียดอะไรยังไงบ้าง รวมถึงวิธีการเขียน Robot framework เบื้องต้นต้องทำยังไง เดี๋ยวเรามาติดตามกันใน Blog ต่อไปนะคะ (โปรดติดตามตอนต่อไป อีกแล้ววววว 5555555)
