[SCK-WLB]<micro-learning> Software Test Strategy Day 1–5 จดบันทึก

ที่มาที่ไป: พี่หนุ่มเปิดสอนอัปเดต Firmware ให้กับชาว We Love Bug (WLB) และ SCK ที่ขอเข้าไปเอี่ยวด้วย และก็เปิดฟรีให้กับคนที่สนใจได้ลงทะเบียนเข้ามาเรียนด้วย ผ่านทาง Zoom ทุกเย็นวันธรรมดา วันละ 1 ชั่วโมง

Day 1

การบริหารและจัดการ คนที่เกี่ยวข้องกับเรื่องเหล่านี้ เป็นระดับของ Software Test Manager หรือ Software Test Leader อาจจะเกี่ยวไปหา Senior บ้าง และ Software Development Manager หรือ Software Development Lead รวมถึง ผู้เชี่ยวชาญเฉพาะเรื่องส่วนงาน ไอที เช่น Security Team หรือ Infra

Test == การทดสอบซอฟต์แวร์

Test != การทดสอบซอฟต์แวร์ของ Tester/QA

ความสัมพันธ์ของแต่ละหัวข้อ

• Software Test Management จะบริหารจัดการ ดำเนินการอย่างไร เป็นเรื่องระดับองค์กร
• Software Test Strategy เรื่องราวของกลยุทธ์
• Software Test Plan แผนการดำเนินงาน

เป็นการทำงานแบบสองทาง ต้องมี Continuous Improvement อาจจะเป็นระดับปี ไตรมาส อะไรก็ตาม แต่ต้องทำเป็นประจำอย่างสม่ำเสมอ เป็น Iterative

• Product = ในบริษัทมี Software หนึ่งตัว
• Program = มีหลาย Product/Service ทำงานด้วยกัน
• ใน Product อาจจะมี Project หรือ Release แยกลงไปอีก
• Test Plan ก็มีได้หลายประเภท

จาก Strategy ลงมาที่ Plan ก็ต้องมี Continuous Improvement เช่นกัน

อีกรูปแบบ มีหลาย Strategy ใน Test Management

Software Development Process

• ช่วงต้นโครงการ
• ช่วงดำเนินโครงการ
• ช่วงท้ายโครงการ

มีเรื่อง “การบริหารจัดการโครงการ” คลุมอยู่ (Software Project Management) แน่นอนว่าต้องมีระยะเวลาของโครงการแนบอยู่ด้วย

• ในแต่ละช่วงโครงการ ก็จะมีหลายๆ เรื่องที่ต้องทำ ซึ่งการเรียงลำดับ ยังไม่มีนัยยะอะไร
• ก่อนจะเข้าไปทำงาน ก็ต้องมีแผน Roadmap ของ Product/Service หรือ งานที่จะเข้ามาในทีม IT มาก่อน ส่วนมากจะเป็นแผนระดับปี และไตรมาส (ซึ่งส่วนมากจะมาคู่กัน)
• ถ้าเกิดการเปลี่ยนแปลงของแผน ไม่ว่าจะเป็นระดับไหน อาจจะส่งผลกระทบ ให้เกิดการเปลี่ยนแปลง Software Test Strategy และ/หรือ Software Test Management
• สิ่งเหล่านี้ ต้องเกิดขึ้นก่อน วันที่ 1 ของวันเริ่มต้นโครงการ
• เลยเป็นเหตุผลว่า ต้องเกี่ยวข้องกับระดับ Manager หรือ Specialist มารีวิว Change ที่เกี่ยวข้อง มาร่วมกันวางแผน
• การเปลี่ยนแปลง Software Test Strategy จะกระทบแผนโครงการ ก็จะส่งผลกระทบกับ Software Test Plan อีก
• Software Test Plan จะต้องเกิดในช่วงต้นโครงการ (เส้นประ สีแดง) หรืออาจจะเริ่มก่อน วันที่ 1 ของ Phase ที่ 1 ของโครงการก็ได้ (เส้นทึบ สีน้ำเงิน)
• Software Test Plan มีเกี่ยวข้องกับเรื่องเงิน
• ระหว่างที่ดำเนินการตาม Plan ไปแล้ว อาจจะเจอปัญหาอะไรที่ส่งผล ทำให้ต้องปรับในเชิง Strategy อีกที เพื่อมา Refine แผนอีกที
• การใช้ Software Test Plan จะต้องใช้ถึงช่วงท้ายโครงการ
• เพราะหลังจาก Deploy/Release ต้องมี Regression Tests

หลังจาก Deploy to Production หรือ Release ไปแล้ว มันจะเกิด เรื่องการบำรุง ดูแล รักษา เพื่อให้บริการ

ถ้าการแก้ไข (Change) นี้ มันไปกระทบกับ Product/Service ที่เราให้บริการ เกิดการเปลี่ยนแปลงใดๆ ก็ตาม ไม่ว่าจะ Software หรือ Hardware ต้องทำการทดสอบ แปลว่า Default ต้องทำ Regression Tests

Software Test Management คือ พ่อทุกสถาบัน (ตัวใหญ่สุด) เพราะเป็นระดับองค์กร ดังนั้น คนที่เกี่ยวข้องจะมี

• Software Test Manager/Software Test Leader
• Software Development Manager/Software Development Lead
• ผู้เชี่ยวชาญเฉพาะเรื่องส่วนงาน ไอที เช่น Security Team หรือ Infra
• ผู้เชี่ยวชาญเฉพาะเรื่องส่วนงาน ITSM เช่น Change Manager (ITIL) / Incident Manager (ITIL) / Problem Manager (ITIL)

Day 2

ลงรายละเอียดเพิ่มเติมในส่วนของ Software Test Strategy

Test Approach

• Define the Testing Process, Level of Testing หรือ Testing Types, Roles, and Responsibilities of every development team member.
• Level จะยุ่งกับ Roles and Responsibilities คือใครเป็นคนทำ สมาชิกในทีมพัฒนา ทำอะไร

Level of Testing จะโดนสองส่วนคือ

• Functional REQs เช่น บวก ลบ คูณ หาร ออกรายงานนู่นนี่นั่น (function การทำงาน)
• Non-Functional REQs เช่น โดนเจาะระบบ การรับโหลดจากผู้ใช้งาน การตอบสนองผู้ใช้งานภายใน x วินาที
• สองระดับต้องถูกแยกออกจากกัน
• การวางแผนกลยุทธ์ มีหลากหลายวิธี ในส่วนที่ WLB ใช้ ชื่อว่า Agile Testing Quadrants เป็นเครื่องมือที่นำมาช่วยในการวางแผน — มาจากคลาส Holistic Testing (ของคุณป้าผู้น่านับถือสองท่าน ที่พี่หนุ่มได้ License มาสอน)

• ใช้เป็นภาพอธิบายเลย ไม่ต้องมาเขียน บรรยาย พรรณนาโวหาร
• Agile Testing Quadrants ล้อมาจาก Brain Child สมองของมนุษย์ที่แบ่งเป็นสองฝั่ง

Guide Development

• tests are written and executed before or during coding to help guide development
• คร่อมระหว่าง Q1, Q4

tests แยกเป็นสองส่วน

• test case กรณีการทดสอบ
• test scenarios สถานการณ์การทดสอบ

written before แปลว่า ต้องถูกพัฒนา ถูกเขียนออกมาก่อน coding

• manual test แปลว่า มนุษย์ดำเนินการทำ อาจจะมีเครื่องมือมาช่วย เช่น ทำความสะอาดบ้าน โดยการใช้ไม้กวาดหรือเครื่องดูดฝุ่นที่ต้องใช้มือจับ | Spreadsheet, Word
• ถ้าเป็น automation คือ เครื่องมือดำเนินการทำ โดยที่ไม่มีมนุษย์เข้ามาเกี่ยวข้องระหว่างดำเนินการทำ เช่น เครื่องซักผ้าอัตโนมัติในขั้นตอนของการซัก ไม่รวมเอาผ้าใส่เครื่อง หรือเอาสารเคมีใส่เครื่อง | Sourcecode ที่ประกอบไปด้วย Action — Asssertion — Arrange (เตรียมการ)

executed ในเชิง automation แปลว่า sourcecode จะต้องถูกรันก่อนเขียนโค้ด เพื่อจะ guide development

Business facing

• the language the business folks can understand
• เป็นภาษาที่คนปกติ อ่าน Sourcecode ไม่เป็น อ่านรู้เรื่อง
• คร่อมระหว่าง Q2, Q3

Q2 = Functional Test

Testing Process แบ่งเป็น

1. Test Development พัฒนา และเตรียมการการทดสอบ
2. Test Execution ดำเนินการทดสอบ

Functional Test = UAT = ดูว่าทำงานได้อย่างถูกต้องหรือไม่ = E2E Biz Process Test

• Test Scenarios คือการร้อยเป็น Flow ยาวๆ วิ่งให้จบ E2E Biz Process
• พอได้ UAT Test Scenarios แล้วก็แปลงมันให้เป็น Automation ซึ่งทำได้สองระดับคือ UI หรือ APIs
• จังหวะ Execute ควรจะปรับให้เป็น Automation เพราะถ้าเป็น Manual เราไม่สามารถรันมันก่อน แล้วดูได้ว่าเป็น Pass หรือ Fail
• รันมันก่อนเพื่อ Guide ก่อนทำการ Coding
• ผู้ใช้ Test Scenarios ในการทดสอบคือ Developer และ CI Tool เช่น Jenkins ใช้ในการรัน Regression Tests

Day 3

ลงรายละเอียดเพิ่มเติมในส่วนของ Agile Testing Quadrants

ถ้าไป Search ในอินเตอร์เน็ต “Test Strategy” ส่วนมากเป็นเอกสาร ซึ่งไม่มีใครอ่านหรอก ก็เลยเอาอันนี้มาใช้ ให้เห็นเป็นภาพ

ถ้าลองเอาคำว่า Agile Testing Quadrants ไป Search ก็จะเจอรูปต่างๆ มากมาย

ปัญหาคือ เราจะเห็นการวางรูปแบบต่างๆ ที่ไม่เหมือนกัน ซึ่งการวางแต่ละภาพมันก็ขึ้นกับบริบทของคนที่เอาไปใช้อีก และ แต่ละภาพก็จะไม่ได้ลงรายละเอียดมากนักอีก

ยกตัวอย่างจาก TOR ภาครัฐแห่งหนึ่ง

สิ่งสำคัญคือ

• ต้องดูโจทย์ ต้องดูหน้างาน แล้ววิเคราะห์ว่า มันควรอยู่ใน Q ไหน ไม่ใช่การจำที่พี่หนุ่มบอกแล้วเอาไปพูดต่อ
• ฟังแล้วอย่าคล้อยตาม ถ้าหน้างานที่เจอไม่ใช่แบบนี้ ให้ตั้งคำถาม อย่าเอาคำที่กล่าวเป็น “สรณะ”
• ถ้าหน้างานเจอปัญหา อยากปรึกษาก็ทักหาพี่หนุ่มได้

(เปิดตัวอย่างการเขียน Test Cases ในอดีต ที่พี่หนุ่มเคยทำมา ขออนุญาตไม่แคปแปะ เพราะผ่านมาหลายสิบปีแล้ว และไม่แนะนำให้ใช้)

• UAT เมื่อก่อนใช้คนในการทำการทดสอบ (ตอนนี้ก็ยังเป็นนี่หน่า) การจะดันมาเป็น Automation ต้องดูว่า Feature/Function ไหนเหมาะสม หรือไม่เหมาะสมในการทำ เพราะทุกอย่างมี Cost
• Software Test Strategy ต้องวางมาให้ถึง Support Production ซึ่งปกติขานี้มันจะไม่ค่อยมี UAT ส่วนมากแก้ CR เสร็จก็บอกให้ช่วยทดสอบหน่อย ซึ่งไม่ได้เรียกมันว่า UAT ด้วย

Automation Tool

• Commercial ต้องซื้อมาใช้ ซึ่งก็ต้องมีคนใช้พวกนี้เป็น แล้วถ้ามันพัง มักจะมี Support ให้โทรหา
• Open sources ก็มีต้นทุนเรื่องเวลา ของบุคลากรที่มาเกี่ยวข้องอยู่ดี (ค่าจ้าง) หรือถ้ามีปัญหา ก็ต้องไปตามหาคนที่ช่วยแก้ได้ใน Communities ต่างๆ

Output ของเครื่องมือพวกนี้คือ Sourcecode ซึ่งก็แบ่งเป็น

• ใช้ทดสอบ — ส่วนมากจะเป็น Automation Tester
• ใช้เตรียมการก่อนการทดสอบ — ส่วนมากจะเป็น Developer มาช่วย

เท่าที่เจอ จะเกิดใน Phase: Development

พอเรา Deploy งานขึ้น Production มันจะมี Code อย่างน้อย 3 ชุด (และน่าจะคนละภาษากันอีก)

1. Production Sourcecode — Developer บำรุง ดูแล รักษา
2. Automation Test Sourcecode ใช้ทดสอบ — คำถาม: Automation Tester ตามมา Support Production ด้วยไหม? — คำตอบที่เจอหน้างาน: ไม่มีคนอาสามาดูแลรักษา
3. Automation Test Sourcecode ใช้เตรียมการก่อนการทดสอบ — ถ้า Developer เป็นคนเดียวกับ 1. อาจจะดูแลรักษาให้ แต่ส่วนใหญ่ ก็จะไม่มีคนดูแลรักษาส่วนนี้เช่นกัน

ในชีวิตจริง Change Request (CR), Incident บน Production ส่วนมากแก้แค่ 1. หรือขึ้น Production ไปแล้วปิดเรื่องการทดสอบทิ้งอีก -o-? แน่นอนว่าส่วนนี้ก็มีต้นทุนบุคลากรในการมา Maintain

ถ้าไม่มีใคร Maintain Automation Test Sourcecode ชุดนี้ ก็ต้องดูว่าคุ้มค่าไหมที่จะลงทุน ทำไปแล้วมีประโยชน์แค่ไหน รันซ้ำได้ถี่แค่ไหน รวมถึงมันอาจจะไม่เหมาะที่จะทำ เช่น Report, Dashboard, Export file ถามว่าทำได้ไหม ตรวจตาราง ตรวจกราฟ ทางเทคนิคมันทำได้ แต่มันคุ้มค่าการลงทุนไหม

ตัวอย่างภาษาที่เขียน เขียนแบบนี้ ถึงจะเรียกว่า Business Facing

อธิบาย Business Process และขั้นตอนที่อ่านเข้าใจ ใน Robot framework

• ของพวกนี้สามารถเขียนได้ก่อน โดยไม่ต้องรอหน้าจอ UI เสร็จ
• ถ้า Tools การทดสอบ ใช้ภาษาใกล้เคียงกันกับภาษาที่ Developer ใช้อยู่ ก็จะง่ายในการช่วยกันดูแล
• ทำยังไงให้เกิด UAT ตั้งแต่แรก
• ถ้าจะไป Automation ต้องเขียนในภาษาที่มนุษย์ปกติรู้เรื่อง

Critique the Product

• ต้องมีชิ้นงาน หรือ เวอร์ชันล่าสุดของซอฟต์แวร์ติดตั้งบน Server UAT หรือ Pre-Production
• ยังเป็น Functional Tests แต่เป็น Manual 100%
• ทดสอบระดับ UI ล้วนๆ
• ถ้าเจอกลุ่ม UAT ที่ไม่สามารถทำ Automation ได้ หรือทำไปก็ไม่คุ้มค่าการลงทุน ต้องใช้คนในการทดสอบ เช่น Report จะอยู่ใน Q3 นี้
• การเขียน Test Cases, Test Scenarios ก็ต้องเขียนให้มันอ่านรู้เรื่อง (Business Facing) ให้คนอื่นที่มาต่องาน สามารถเอาไปใช้งานต่อได้ เอาตัวอย่างการเขียนมาแปะไว้ด้วย

การวางแผนในเชิงกลยุทธ์ ต้องมีเหตุผลในการวางของลงไปในแต่ละกล่อง หน้างานแต่ละคนไม่เหมือนกัน ขึ้นอยู่กับว่า วิธีคิด หรือประสบการณ์ของแต่ละคนเป็นอย่างไร

Day 4

Recap: การเกิด Source Code จะต้องเกิด Test Scenarios ขึ้นมาก่อนเสมอ

• Q2 Input = Test Scenarios

Technology Facing

• ภาษาที่ใช้เขียน Code
• ของที่อยู่ในบริเวณ Technology Facing จะครอบคลุม Q1 และ Q4
• Q1 Input = Test Cases กรณีการทดสอบ ที่เกิดขึ้นจากเงื่อนไขทางธุรกิจ
• การทดสอบแบบ Functional และที่อยู่ตรงนี้คือ Unit Test
• Unit Test คือการทดสอบ function หรือ method เล็กๆ ว่ามันทำงานอย่างไร
• Test Execution เป็น Automation Test 100%
• QA หรือ Software Tester อาจจะไม่ต้องเขียนเป็น แต่ต้องรู้ว่ามันคืออะไร เคยผ่านหูผ่านตามาบ้าง

ยกตัวอย่างไฟล์ unit test และเปิดให้ดู — คนปกติ อาจจะอ่านไม่ค่อยเข้าใจ รู้แค่มันเป็นภาษาอังกฤษ

ตัวอย่างของ Cypress

• Cypress, Playwright เป็นสองตัวที่หลายที่นิยมใช้ ก็มีจุดดี จุดเด่นที่แตกต่างกัน
• Katalon เป็น GUI เบื้องหลังน่าจะเป็นภาษา Java (ถ้าจำไม่ผิด)
• ถ้าต้องการทดสอบ E2E Biz Process Test ผ่านทาง UI โดยใช้เครื่องมือ เช่น CyPress จะอยู่ที่ Q1

• Test Cases สามารถเขียนเป็นภาษาคน (ไทย) ได้ ถ้าเขียนแบบนี้ ก็จะถูกย้ายไปอยู่ Q2

แต่เบื้องหลังก็จะมีความเป็น Coding อยู่

• Postman ที่ใช้กับ APIs ถึงแม้จะดูเติมคำในช่องว่าง แต่ Source Code ก็เป็นภาษายากอยู่ ก็จะตกอยู่ใน Q1 (Technical Facing)
• Unit Test, API Test, UI Test ถ้าล้อตาม Biz Process ก็จะอยู่ที่ Q1 นี้ ซึ่งมันเป็นอัตโนมัติด้วยนะ

เพื่อให้เกิด Q1 ใครต้องเป็นผู้ดำเนินการ เพื่อให้เกิด Input ส่งเข้าไป และเกิด Output ใน Q ดังกล่าว

Test Process จะต้องล้อไปกับ Software Development Process

• Waterfall — Test Process จะอยู่ในส่วนของ Test Development ซึ่งจะเกิดที่ Phase: REQs Gathering และ อาจจะลามไปถึง Analysis and Design
• Agile

ตัดเข้าสู่ช่วงอธิบาย Agile — สิ่งที่จะเอามาปรับประยุกต์ใช้ใน software development คือ methodology หรือ framework

• ตัวที่ทุกคนคุ้นเคย คือ Scrum framwork แล้วก็เข้าสู่การลงรายละเอียดของ Product Backlog Refinement
• ซึ่งจะใช้ Extreme Programming (XP) มาช่วย Adding Details

• นอกจาก Scrum Team แล้ว ก็ต้องเอา เจ้าของความต้องการตัวจริงมาด้วย

The Three Amigos (Amigo = เพื่อน)

• Programmers + Testers = Development Team

https://www.slideshare.net/slideshow/the-three-amigos/11699773#5

• ถ้าอยู่ในบริบท Scrum คนที่จะต้องอธิบายวางแผนอะไรแบบนี้ คือหน้าที่ของ Scrum Master

Day 5

ว่าด้วยเรื่องของ วิเคราะห์ และออกแบบ Unit Test Cases ใครต้องเป็นคนรับผิดชอบ?

• QA จะต้องเป็นคนเทรน คนเหล่านี้ขึ้น เพื่อให้เปลี่ยนจาก No Skill เป็น Be Upskill อ้างอิงจาก Agile Testing
• จากนั้นต้องเอา Cases ต่างๆ มาร้อยให้เป็น Test Scenarios ก็เป็นคนกลุ่มเดียวกันเช่นกัน

คำถาม ทำไมต้องเป็น QA เป็นคนเทรน?

• Test Design Technique เป็นส่ิงที่ QA ต้องใช้
• ดังนั้นเป็นทักษะ ที่ QA ต้องมี และต้องถ่ายทักษะให้คนอื่นด้วย ไม่งั้นตายแน่นอน
• ออกแบบอะไรได้ ก็ต้องถ่าย Skill set ให้คนอื่นทำได้ด้วย
• ความท้าทายคือ QA ที่มี สามารถถ่ายทอดทักษะให้คนอื่นได้หรือไม่

Test Implement

ถ้าเป็น Manual ก็เป็น Word หรือ Spreadsheet ไป

ถ้าเป็น Automation ไปทำ Test Source Code

ซึ่งแบ่งเป็น Preparation หรือ Tearup และ Teardown sourcecode

• Dependencies sourcecode จำลองตัวพฤติกรรมของระบบอื่นที่ต้องไปต่อเชื่อม (Dependencies)
• Sourcecode เตรียม Test Data ของแต่ละ Test Scenarios หรือ Test Suite

Test Suite ตาม Miro Board นี้ = เหล่า Test Scenarios

• สำหรับใครที่เขียน robot framework ให้เขียนแยกกัน อ่านจาก Docs เค้าได้เลย
• บุคคลที่ทำการแปลงเป็น Test Sourcecode = QA ที่มีประสบการณ์ในเครื่องมือนั้นๆ
• เล่นได้ vs เล่นเป็น / ทำได้ vs ทำเป็น / ใช้ได้ vs ใช้เป็น -> ถ้าเป็นคือแบบมีเทคนิค รู้วิธีเยอะแยะ (ตัวอย่างที่ยกตัวอย่างคือ การเล่นบาส และมีศัพท์แปลกๆ ในวงการ ที่ต้องเล่นเป็น ถึงจะเข้าใจ)
• tools smith คือคนที่มีประสบการณ์ตัวจริง และสามารถใช้ tools ได้หลากหลาย

ที่กล่าวมาทั้งหมด อยู่ในการทำแผลกลยุทธ์ เชื่อมต่อไปสู่การทำ Budget แผนงบประมาณ​และการ Up skill ของบุคลากร

ปล. เพิ่งเห็นว่าเขียนไว้ตั้งแต่ Nov 2024 แล้วไม่ได้ Publish!