[บันทึก] การส่งมอบใน micro-learning Software Testing ยามเช้า 0530–0700 วันที่สาม

วันที่สาม: วันจันทร์ที่ 26 กรกฎาคม พ.ศ. 2564 เวลา 05:30 น. ถึง 07:00 น.

เช้าวันที่สามของการส่งมอบ วันนี้เริ่มต่อจาก Test Strategy ในส่วนของ Automation Strategy ที่

เริ่มต้นจากการลากเส้นเชื่อมระหว่าง ความต้องการ (Requirements) และ การทดสอบ (Testing) ซึ่ง การทดสอบอัตโนมัติ (Automated Testing) นั้นมันเป็นอยู่แล้วตามกลุ่มของการทดสอบ ไม่ใช่เพิ่งจะมาคิดว่าต้อง Automation ณ ยามนี้

เสริมไปว่า Test Strategy มีทำจริง ๆ น้อยมาก มักจะเป็นในรูปแบบของเอกสาร และเปิดเอกสารที่เคยทำไว้สมัยทำการทดสอบ และบริหารจัดการทีมเทสเตอร์ตอนอยู่ที่เว็บไซต์สนุกดอทคอมให้ดูเป็นตัวอย่าง แต่อย่าเอาไปทำตาม

แนะนำการสร้าง Test Strategy

• ใช้ Mindmap แทนการเขียนออกมาเป็นเอกสาร
• Test Strategy จะต้องเป็นของ ผลิตภัณฑ์ หรือบริการ ไม่ใช่ของทีมเทสเตอร์
• Test Strategy จะต้องถูกปรับปรุงในทุก ๆ วันหากมีการเปลี่ยนแปลงใด ๆ เกิดขึ้นไม่ว่าจะเป็นการเปลี่ยนแปลงของความต้องการ การเปลี่ยนแปลงของโซลูชั่น การเปลี่ยนแปลงทางอินฟราสตัลเจอร์ และอื่น ๆ ที่จะส่งผลกระทบกับผลิตภัณฑ์ หรือบริการ

สิ่งที่จะต้องใช้เพิ่มในการสร้าง และปรับปรุง Test Strategy คือ โครงสร้างสถาปัตยกรรม ของ System-to-Be หรือที่เราเรียกกันติดปากว่า Architecture ที่จะต้องทำการออกแบบเสร็จเป็นฉบับตั้งต้น ณ ช่วง Pre-Game หรือตอนต้นของโครงการ ที่จะต้องได้รับการวิเคราะห์ และออกแบบมาว่าจะเกิดการปรับเปลี่ยนอะไรบ้างกับ รุ่น (Version) ที่จะเกิดขึ้นใหม่

เหตุผลที่จะต้องได้ โครงสร้างสถาปัตยกรรม ของ System-to-Be เพราะจะนำมาใช้ในการกำหนดประเภทของการทดสอบ (Test Level หรือ Test Types ก็แล้วแต่ความสะดวกที่จะเรียก) โดยเน้นย้ำไปว่า

1. ประเภทของการทดสอบ ให้ตั้งคำนิยาม และตัวอย่างที่ ทุก ๆ คนที่เกี่ยวข้องกับผลิตภัณฑ์ หรือบริการ นั้น ใช้แบบเดียวกัน อย่าไป Copy และ Paste มาจากที่อื่น จากใคร และจากอินเตอร์เน็ต แต่นำมาเป็นตัวอย่างได้
2. ทำออกมาเป็นแผนภาพไม่ว่าจะเขียนบนกระดานไวท์บอร์ด หรือกระดาษฟลิปชาร์ท พร้อมกับใช้ Sticky Note หรือที่เราเรียกติดปากว่า Post-it ก็ได้ ถ้าต้องทำงานกันแบบออนไลน์ก็ใช้เครื่องมือ เช่น Miro (https://miro.com) หรือ Google Jamboard (https://jamboard.google.com) ก็ได้
3. ทุก ๆ คนที่เกี่ยวข้องกับผลิตภัณฑ์ หรือบริการ ไม่ว่าจะเป็น เจ้าของความต้องการ (Requirements Owners) นักวิเคราะห์ระบบ (Analyst) นักพัฒนา (Developer หรือ Programmer หรือ Software Engineer) ซอฟต์แวร์เทสเตอร์ (Software Tester) ผู้ควบคุม ดูแล และประกันคุณภาพของซอฟต์แวร์ (Software Quality Assutance) ผู้เชี่ยวชาญเฉพาะเรื่อง (Expertise เช่น Infrastructure และ Security เป็นต้น)

พาต่อมาที่ระดับของการทดสอบที่เรียกว่า Business Rules/Business Logics ผ่านทาง APIs หรือ Service Layers ที่ใช้เส้นลูกศรสีเหลืองที่แทนสิ่งที่ผมเรียกว่า End-to-End Business Processes หรือ End-to-End Business Flows

ภายใต้ API แต่ละตัวก็จะประกอบไปด้วย Component หลาย ๆ

ภายใต้ Component แต่ละตัวก็จะประกอบไปด้วย Function หลาย ๆ

พาต่อไปที่ระดับการทดสอบที่เรียกว่า Unit Test ที่เป็น Automated Test ที่สำคัญมาก ๆ ไล่ให้เห็นว่าต้นทางของการทดสอบ Unit Test จะต้องมีองค์ประกอบจาก

1. เงื่อนไขทางธุรกิจ (Business Rules) ที่จะได้มาจากการจัดเก็บความต้องการ (Requirements Elicitation) และการวิเคราะห์ความต้องการ (Requirements Analysis)
2. กรณีที่มี ผลิตภัณฑ์ หรือบริการเดิมอยู่ ผมจะเรียกว่า System-as-Is ก็อาจจะต้องใช้ Production Source Code ออกมาเพื่อหาเงื่อนไขทางธุรกิจปัจจุบัน (เกิดขึ้นในกรณีที่อาจจะไม่มีการเขียน Unit Tests ไว้เลย) รวมทั้งแผนภาพต่าง ๆ เช่น Flow Charts หากมีการเขียนไว้ในการออกแบบการทำงานของ Function

ทั้งสองข้อจะถูกนำเข้าไปใช้ใน Test Design Techniques ทั้ง White Box และ Black Box เพื่อให้ได้ออกมาเป็น Unit Test Cases ออกมา ซึ่งจะต้องเกิดในช่วงของ Pre-Game

ช่วงของ Game เป็นช่วงที่จะสร้าง Test Source Code ของ Unit Test Cases ขึ้นมาโดยนักพัฒนา (Developer หรือ Programmer หรือ Software Engineer) โดยมีสองสิ่งที่เป็นพื้นฐานคือ

1. Coding Standard
2. Automation Test Structure ที่ทีมผมใช้กันอยู่คือ 3A คือ Arrange, Act และ Assert

ขยายเรื่อง Unit Test ออกเพื่อให้เห็นว่า Automation Test Structure แบบ 3A นั้นอยู่ตรงไหนบ้าง และแนะนำให้รู้จักกับ Test Double ที่ประกอบไปด้วยเทคนิคจำนวน 5 เทคนิค

สามารถอ่านเพิ่มเติมเรื่อง Test Double ได้จากบทความที่พี่ปุ๋ยสมเกียรติเขียนไว้

test-double (somkiat.cc)

ผมลงรายละเอียดและใช้เวลากับเรื่องของ Unit Test มากเพราะส่วนหนึ่งของผู้ที่ตื่นเช้ามาบ้าบอกับผมนั้นทำงานเป็นซอฟต์แวร์เทสเตอร์ที่ทดสอบอยู่แค่ User Inteface และ APIs

เมื่อเป็น ซอฟต์แวร์เทสเตอร์ ก็ต้องรู้จัก และมีประสบการณ์ในการวิเคราะห์ ออกแบบ และพัฒนาทั้ง Test Scenarios และ Test Cases ในทุก ๆ ระดับของการทดสอบซอฟต์แวร์ทั้ง Functional Tests และ Nonfunctional Tests

วันศุกร์ที่ 30 กรกฎาคม พ.ศ. 2564 เวลา 09:33น.
เขตหลักสี่ จังหวัดกรุงเทพมหานคร ประเทศไทย