Design&Develop Test Scenarios แล้วดำเนินการทดสอบ ดู Expected Result(s) เทียบกับ Actual Result(s) #LearningWithSCK

บทความที่เกี่ยวข้อง

1. ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่หนึ่ง
2. ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่สอง & เกริ่นเข้า Test Scenarios

Day 4

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

เป้าหมายสัปดาห์นี้ คือการเปลี่ยนจาก Miro ไปลง Google Sheet แล้วร้อยเรียง Test Scenarios

จากครั้งที่แล้ว ฝึกการเขียน Test Cases ด้วย เทคนิค Blackbox ตอนที่สอง & เกริ่นเข้า Test Scenarios การออกแบบ Test Scenarios (สถานการณ์การทดสอบ) เราต้องแบ่ง Scenarios เป็น Success กับ Unsuccessful จากนั้นก็จะไหลต่อมาที่ การพัฒนา Test Scenarios

ในบริบทของ SCK ที่ทำงานกันอยู่ การพัฒนา Test Scenarios จะตั้งคำถามแรกด้วย “Is Automation?”

• YES = พัฒนา Test Source code ขึ้นมา ส่วนมากควรจะถูกดันให้เป็น Automation ทั้งหมด
• No = พัฒนา Test Script ที่เราเขียนลงใน MS Excel, MS Word เป็นต้น (กรณีที่ทำ Manual แล้ว ดีกว่า เร็วกว่า แต่ส่วนนี้ควรจะน้อยมากๆ)

จากนั้นก็ ดำเนินการทดสอบ Expected Result(s) เทียบกับ Actual Result(s)

• Expected Result(s) มาจาก ที่เราออกแบบไว้
• Actual Result(s) มาจากระบบ (System) หรือ Software

สมการการเปรียบเทียบ

• ถ้า Expected Result(s) เท่ากันกับ Actual Result(s) ผลการทดสอบ Pass (ผ่าน)
• ถ้า Expected Result(s) ไม่เท่ากันกับ Actual Result(s) ผลการทดสอบ Fail (ไม่ผ่าน)

ถ้าผลการทดสอบ Fail (ไม่ผ่าน) จะต้อง รายงาน หรือแจ้งผลการทดสอบที่ไม่ผ่าน จากนั้นทีมพัฒนา จะ วิเคราะห์ ออกแบบ ดำเนินการแก้ไข

Retest

ดำเนินการทดสอบว่า Bugs/Defects ที่ถูกแจ้งมาว่า Fail (ไม่ผ่าน) ได้ทำการแก้ไขแล้ว ซึ่งคนที่ต้องดำเนินการก่อนคนแรกคือ Developer/ Programmer/ Software Engineer ไม่ใช่โยนมาให้ Tester เลย

* การ Retest ต้องอยู่ใน Environment, Test Data, Expected Result แบบเดียวกัน

ก่อนทำการ Retest เราต้อง เตรียมการก่อนการดำเนินการทดสอบ เพราะถ้ากดรันเลย ยอดเงินคงเหลือในระบบมันมีแค่ 485 พอเอาไปรันอีกรอบปุ๊บก็ติดลบปั๊บ

การเตรียมการก่อนการดำเนินทดสอบ = การเตรียม Test Data = เงินต้น == 2,000.00 บาท (ตัวแปรควบคุม) เพื่อให้เกิดการทำซ้ำได้

ถ้า Developer/ Programmer/ Software Engineer แก้ไขแล้วถูกต้อง

Actual Result ยอดเงินคงเหลือ == 500.00 บาท == เงินต้น == Expected Results == ผ่าน

จากตัวอย่างที่แสดงให้เห็น จะเห็นว่า เราต้องมี “การเตรียมการก่อนดำเนินการทดสอบ” ก่อน ซึ่งส่งผลกับสมการของ Test Scenario ด้วย

การเปลี่ยนแปลงของ C ส่งผลกับคนอื่น ต้องทำ Regression Tests ทั้งหมด

• การดำเนินการทดสอบ ต้องเป็น Automation ไม่ว่าจะอยู่ในรูปแบบการทำงาน Waterfall หรือ Agile Software Development ก็ตาม
• การทดสอบคนแรก ดําเนินการโดย Developer/ Programmer/ Software Engineer เช่นกัน

เช่นเดียวกับการทำ Retest ระดับ Feature/Function ก็ให้เป็น Automation

ยกตัวอย่าง การ Test Report ที่ดาวน์โหลดออกมาเป็น Excel

• ถ้าเป็นเฉพาะ Field = Retest
• ถ้าภาพรวม Report = Regression Tests
• เราตรวจสอบความถูกต้องของ Data ใน Cell ต่างๆ ทำได้ตั้งแต่ชั้น API เลย = Automation
• แต่ถ้าตรวจสอบความสวยงามว่า Font, Color ถูกต้องไหม = ตรวจด้วยตาคน (Manual) เร็วกว่า

เราจะต้องทำ Test มากแค่ไหนถึงจะพอ? มันจะมีเยอะเสมอ และมีเวลาไม่พอ ถ้า Tester ทำ Manual อย่างเดียว ทำยังไงก็ไม่ทัน

น้อยสุดที่จะครอบคลุม (Test Coverage)

แต่ละเงื่อนไข แต่ละกรณีการทดสอบ ถูกทดสอบอย่างน้อยหนึ่งครั้ง แต่บางเงื่อนไขจะโดนทดสอบซ้ำๆ อยู่ เช่น บัญชีไม่ติดอายัด (จากโจทย์เดิม)

1) เริ่มจากการใส่ ID ให้แต่ละ Requirements

2) แล้วก็เอา ID ไปแปะไว้ในแต่ละ Test Cases ยกตัวอย่างเช่น

จากสมการใหม่

• Test Scenario = Test Case + Test Case + Test Case+ … + Test Case
• Test Case = การเตรียมการก่อนดำเนินการทดสอบ + เงื่อนไขที่ถูกทดสอบ + Expected Result + Test Data

Success Test Scenarios = สามารถฝากเงินได้

3) ลองทำ Test Scenario 01 คือ การเอา Test Cases ของหลายๆ เงื่อนไขที่เป็น ฝากเงินได้ มารวมร่างกัน ซึ่งต้องรวมตั้งแต่ DR1, DR2, …, DR8

จากภาพนี้คือยังไม่เสร็จสมบูรณ์

4) ถ้า Test Case ไหน ถูกนำมาใช้แล้วก็ให้ใส่เครื่องหมาย ✔️ ไว้ด้วย จะได้ไม่หลงลืมว่าหยิบมาใช้แล้ว

วันนี้ใช้เวลาเกินมา 30 นาที เพื่อทิ้งท้ายให้มีการบ้านลองเขียน Test Scenarios ที่เป็น Success ดู ว่าสามารถเกิดได้กี่เคส

พอลองเขียนเอง เหมือนว่าจะเห็นภาพ แต่ก็เป็นภาพลวงหลอกตาาาาาาา

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

Day 5

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

ย้อนกลับไปดูที่ ID ที่เราตั้งต้นไว้ แล้ว Identify ว่าเงื่อนไขไหนเป็นเงื่อนไขที่ต้องถูกทดสอบ เพื่อให้ได้ผลลัพธ์เป็น ผ่าน (ที่เปลี่ยน Post-it เป็นสีเหลือง) นอกนั้นจะเป็น ผลลัพธ์ / สิ่งที่ต้องได้

ตามเงื่อนไขของตรรกศาสตร์ ทุกเงื่อนไขต้องเป็น True และเชื่อมกันด้วย And เพื่อให้ผลลัพธ์ออกมาเป็น True

ซึ่งพอดูเงื่อนไข เราสามารถใช้ DR4 เป็นการบอก Test Scenarios ที่น้อยที่สุด เท่าที่จะเกิดได้ เนื่องจาก DR5, DR8 เป็นประโยคบอกเล่า

DR4.1, 4.2 เคสที่ “ฝากเงินได้” จะมีทั้งหมด 5 เคส แต่สามารถยุบได้เหลือ 4 เคส

ถ้าเราต้องการให้เกิด Expected Results ที่เป็น ผ่าน แปลว่า เราต้องเอาเงื่อนไขที่เป็นจริงในข้ออื่นๆ มาวาง

เราจะพบว่า

• DR5 มีความสัมพันธ์กับ DR1
• แล้วพอเลือก DR7 ก็ต้องเลือก TC1 อีก เพราะ จำนวนเงินฝากต่อวัน น้อยกว่า 250,000.00 การที่เราเลือก DR3_TC2 การฝากเงินเวลา 09:00 น. แปลว่า ยังไงก็ไม่มีทางฝากครั้งแรกที่ 250,000.00 ได้เลย เพราะมันมีความสัมพันธ์กับ DR5 อีก

สิ่งที่ได้เรียนรู้เพิ่มเติม: ทำการแสดง Data ในทุกจุดที่อาจก่อให้เกิดความเข้าใจไม่ตรงกัน เช่น เงินในบัญชีก่อนฝาก/หลังฝาก เงินโควต้าก่อนฝาก/หลังฝาก

Test Scenario = การเตรียมการก่อนดําเนินการทดสอบ(s) + เงื่อนไขที่ถูกทดสอบ(s) + Expected Result(s) + Test Data

การเตรียมการก่อนดําเนินการทดสอบ(s)

• รายละเอียดของบัญชีธนาคาร: ชื่อเจ้าของบัญชี (ใช้ข้อมูลจริง) เลขบัญชี ประเภทบัญชี ธนาคาร สถานะบัญชี
• จำนวนเงินในบัญชี ก่อนฝาก
• จำนวนเงินที่ฝากต่อวัน ก่อนฝาก
• วันเดือนปีเกิดของเจ้าของบัญชี
• วันที่ ที่ทำธุรกรรม เพราะมีผลกับ อายุของเจ้าของบัญชี
• เวลา ที่ทำธุรกรรม เพราะมีผลกับ การฝากได้ หรือไม่ได้

ไม่ว่าจะทำการทดสอบ Scenarios นี้เมื่อไหร่ ต้อง Set วันที่กลับมาเป็นวันที่ทำธุรกรรมเสมอ เพื่อที่จะได้รันได้ซ้ำ สามารถทำการทดสอบได้ทั้ง Automation และ ​Manual ซึ่งต้องได้รับความช่วยเหลือจาก Programmer ให้สามารถจำลองวันที่ได้ โดยไม่ได้ใช้วันที่จริงของระบบ

เงื่อนไขที่ถูกทดสอบ(s)

• บางสิ่งไม่ได้บอกใน Requirements แต่ด้วยประสบการณ์ สามารถเพิ่ม การฝากเงินที่ร้าน C-Store สาขาไหน เข้าไปด้วยได้ เพราะมันจะส่งผลกับระบบบัญชีอีกทอดหนึ่ง

• เราจะพบว่าบางเงื่อนไข จะถูกทดสอบไปตั้งแต่ การเตรียมการก่อนดำเนินการทดสอบแล้ว

Expected Result(s)

ก่อนฝาก

• ถ้าเงื่อนไขทั้งหมดเป็นจริง แสดง QR Code/Barcode ก่อนฝาก
• ถ้าใน Requirements ไม่ได้บอกมาว่า QR Code/Barcode จะแสดงอะไรบ้าง ให้ตั้งสมมติฐานเอาว่าควรมีอะไรบ้าง

เมื่อทำการฝากเงินเรียบร้อย สิ่งที่เราตรวจสอบ

• จำนวนเงินในบัญชีหลังฝาก (เพิ่มขึ้น)
• จำนวนเงินที่ฝากต่อวัน (ลดลงจากโควต้า 250,000.00)

และเช่นเคย หาก Requirements ไม่ระบุมา เราสามารถตั้งข้อสงสัยเพิ่มเติมได้

สิ่งที่ได้เรียนรู้เพิ่มเติม: การได้ลงมือทำก่อน ได้รับคำแนะนำ และได้รับการเฉลยอีกครั้ง ทำให้เกิดความเอ๊ะ โอ๊ะ เปรียบเทียบกับสิ่งที่พลาดไป เปิดโลกแห่งการเป็น Tester มาก

การบ้านต่อไป

• ปรับ Scenarios Version แรก ให้ออกมาอยู่ในรูปแบบที่พี่หนุ่มเฉลย
• ข้อมูลทั้งหมดต้องแตกต่าง ห้ามใช้ซ้ำในแต่ละ Scenarios (การทำ Automation ทุกอย่างต้องมีความ Unique)
• นำภาพที่กางไว้ ไปเขียนลงใน Google Sheet

ด้วยความใช้เทคนิค Copy and Adjust แปลว่า กางภาพใน Miro ได้อย่างเร็วขึ้นมาก แต่พอต้องไปแปลงร่างลง Google Sheet ที่ต้อง Design หัว Column ก็มีความสงสัยขึ้นมานิดหนึ่ง แต่แล้วก็เอาทุกอย่างจาก Miro ไปลงเลยทุกสิ่งอย่าง เรียกว่า copycat ก็ว่าได้

จากนั้นก็ได้รับการตรวจการบ้านจากพี่หนุ่มร่วมกับน้องๆ ทั้งสอง เพื่อพบว่า

• Test Data ไม่ต้องอยู่ใน Test Description
• Test Description ต้องมีคำว่า “สำเร็จ” อยู่ด้วย
• หาก Test Data เป็นเรื่องตัวเลข ให้ชิดขวาเสมอ
• จัดรูปแบบข้อมูลแบบชิดด้านบน
• ให้ Expected Result แยกออกมาเป็นคนละ Column ไม่จับมารวมอยู่ใน Cell เดียวกัน
• การเตรียมการก่อนการทดสอบต้องอยู่ด้วยกัน เงื่อนไขที่ถูกทดสอบต้องอยู่ด้วยกัน แปลว่า เอาจาก Miro มาลงตรงๆ เลยไม่ได้
• จากนั้นเพิ่มแถวด้านบน เพื่อเพิ่มลงไปสองบรรทัด (ตามภาพด้านล่าง) ซึ่งไฟล์นี้จะเป็นสิ่งที่ถูกแนบเข้าไปในการ์ด Requirement (อาจจะใน Jira หรือ Azure Board) เพื่อบอกทีมพัฒนาแต่ต้นเลยว่า User Story นี้มี Success Cases ประกบมาด้วยแล้วจำนวน 4 Scenarios

สิ่งที่ได้เรียนรู้เพิ่มเติม: การที่พี่หนุ่มสอนทีละขั้นตอน พอมาลองทำเอง แม้จะไม่เคยทำงานด้านนี้มาก่อนเลยอย่างฉันก็สามารถทำได้ อาจจะคิดไม่ละเอียดหรือไม่ครอบคลุมเท่ากับผู้มีประสบการณ์ แต่มันก็ไม่ได้ยากขนาดนั้น

พอทุกอย่างมันออกมาเห็นชัด เรา (และทีม) ก็จะไม่เอ๋อ ไม่มั่ว การทำสิ่งนี้เป็นการพิสูจน์ว่ามันเขียน Test มารอก่อนได้ แบบที่ไม่ต้องมีหน้าจอ (UI) ไม่ต้องพัฒนาซอฟต์แวร์เสร็จแล้วค่อยทดสอบ

การบ้านต่อไป กรณีฝากไม่สำเร็จ

รู้สึกตื่นเต้นตลอดเวลาที่ต้องตอบคำถาม หรือโดนตรวจการบ้าน เพื่อพบว่ามีจุดผิดพลาด จุดเพิ่มเติมอยู่เรื่อยๆ ถ้าเป็นนักรบตอนนี้ก็น่าจะเริ่มมีบาดแผลหลายจุดแล้วล่ะ

โปรดติดตามตอนต่อไป!