[บันทึกเด็กข้างห้อง] Holistic Testing: Strategies for Agile Teams Day 3 #LearningWithSCK
Recap เรื่องราวของเมื่อวานสักนิดว่า การทดสอบเป็นเรื่องของทุกคน จากนั้นพี่หนุ่มก็แชร์สิ่งที่ตอนนี้ SCK ใช้กัน
ทักษะ ประสบการณ์ที่ใช้ในการทำงาน
ที่จำเป็นต้องมี ก่อนจะไปใช้เครื่องมือ
- วิเคราะห์ และออกแบบ Arrange
- พัฒนา Arrange
- วิเคราะห์ และออกแบบ Act และ Assert
- พัฒนา Act และ Assert
เครื่องมือพื้นฐานที่ต้องใช้เป็น เช่น Git SCM, VSCode, Basic Unix Commands, Cloud AWS, Cloud Google, Cloud Azure, Cloud Tencent
รวมถึงเครื่องมือต่างๆ ที่ใช้ในการ Arrange, Act, Assert (เยอะมากแม่!)
เพื่อให้ได้ประโยชน์สูงสุด Dev และ QA ต้องใช้เครื่องมือพวกนี้เป็น และ ดูแลรักษาได้
เวลาจะทำอะไร ต้องคิดก่อนว่าจะทำการทดสอบอย่างไร และจะให้มันเป็นอัตโนมัติอย่างไร
Whole Team Approach
- Whole Team = Product Team
- ทีมทุกคนมีหน้าที่ในการทำการทดสอบ รวมถึง Automation
- ทีมมีทักษะที่ต้องการทั้งหมด
- ทีมออกแบบ ให้ง่ายในการทดสอบอัตโนมัติ
- ให้การทดสอบอัตโนมัติ เป็นโรคติดต่อ
Specialists Needed?
- อาจจะต้องการทรัพยากร หรือบุคคลจากภายนอกมาช่วย
- รู้เครื่องมือหลากหลาย รู้ว่าตัวไหนเหมาะสมกับอะไร
- ทีมต้องรับผิดชอบเรื่องการทดสอบทั้งหมดให้ครบถ้วน
- เอาหลายๆ คนมาช่วยกันคิด มองได้หลากมุมขึ้น จะได้เห็นความเสี่ยงมากขึ้น
Simplicity and Courage
- ตั้งต้นจาก ปัญหาคืออะไร องค์กรต้องการให้มี Automation Test เพราะอะไร เช่น ลดเวลา ลดค่าใช้จ่าย (ใน Long Term)
- แตกปัญหาออกมาเป็นส่วนเล็กๆ ว่าต้องการปรับแก้ส่วนใดก่อน ให้มันมี Progress วิ่ง
- เริ่มจากสิ่งที่ง่ายก่อน
- ทำไป ปรับไป ทำไป ปรับไป
- ทำแล้วพลาดตรงไหน หยุดคิด แล้วก็ลงมือทำใหม่
- จับคู่กับบุคคลที่มี ทักษะ ประสบการณ์ (ชั่วโมงบิน หรือ พรรษา) สูงกว่าเรา การจับคู่ ไม่ได้แปลว่า ทักไปถาม แต่นั่งคู่กัน
Automation Retrospectives หยุดแล้วดูซิว่า มันยังช่วยอยู่หรือเปล่า
- เมื่อเวลาผ่านไป มันยังง่ายในการสร้าง บำรุงดูแลรักษาอยู่ไหม
- ถ้าไม่ ต้องการ การ Training หรือคนมาประกบเพิ่มด้วยไหม
- ใช้เวลาเท่าไหร่ในการดูแลรักษา ในการ Refactor รวมถึงต้นทุนที่ใช้
- Regression แล้วเจอข้อผิดพลาดอยู่ใช่ไหม
Keeping Up!
- พยายามตัด Stories ให้อยู่ในขนาดที่เล็กและทดสอบได้
- ให้ Feedback Loop เร็วที่สุด รอบเล็กที่สุดแนะนำเป็นรายวัน
- Automation ต้องเป็น Task งานที่เกิดขึ้นด้วย
- แต่ก็อย่าลืมภาพใหญ่นะ
แล้วจะเลือกเครื่องมืออย่างไร?
- มีดอันเดียว ไม่ได้เหมาะกับการใช้งานกับทุกสิ่งอย่าง
- ต้องทำ Research ดูว่า Tool นี้ทำอะไรได้ เรากำลังจะมาแก้โจทย์เรื่องอะไร ต้องใช้วิธีการอะไรในการแก้
- ทำตารางออกมา แล้วก็ ติ้กๆๆ ว่าเครื่องมือตอบเรื่องอะไรบ้าง แล้วค่อยตัดสินใจเลือก Tool
เรื่องสำคัญ
- ทักษะของทีมปัจจุบันตอนนี้เป็นอย่างไรอยู่
- ภาษาที่เขียนใช้ภาษาอะไรอยู่ เช่น TypeScript ทั้ง FE, BE ดังนั้น Automation Tool ต้องใช้ TypeScript ด้วย (หรือหาภาษาที่ใกล้เคียง)
- ต้องได้รับความร่วมมือจากทุกคน
- การทำการทดสอบในอนาคต
เครื่องมือแบบไหนไม่ควรเลือก อย่าหาทำ อย่าใช้
- Test ผ่าน UI อย่าทำ
- Dev ไม่ช่วยทำการทดสอบ ก็อย่าเอามาใช้
- ทำ Automation Test หลังเขียนโค้ดเสร็จแล้ว
- Tester โอบกอด Tool ไว้คนเดียว สร้างและพัฒนาอยู่คนเดียว
ปัจจัยอื่นๆ ที่สามารถนำมาพิจารณาเพิ่มได้
- Workflow
- Table / Data-driven tests พยายามหาเครื่องมือที่ import test data เข้าไปในเครื่องมือได้ เช่น .csv, .tsv กดรันหนึ่งครั้ง รันได้เป็นร้อย data เป็นต้น
- Keyword เช่น Robot framework สามารถสร้างคำสั่งมาใช้ได้เองอีกที
- Web Services
- Exploratory testing support
- Analytics
- Machine Learning
Deployment Pipeline
ต้องออกแบบขั้นตอนการทำงานในกระดาษก่อน ที่จะไปลงมือทำในเครื่องมือ
Retrospective ใน Scrum
- คือการ Reflects ได้ทั้ง Product, Process, Skills, Knowledge, Tools, internal relationship and external relationship
- What went well
- What problems it encountered
- How those problems were (or were not) solved
- Identifies the most helpful changes to improve
- จากนั้นเอาสิ่งที่อยากจะปรับแก้ เก็บเข้าไปใน Backlog ด้วย
- ถ้าเป็นพี่หนุ่ม จะเอา Defects ขึ้นมาดู เอา Automation Tests มารัน แต่ก็ต้องดูวุฒิภาวะของทีมด้วยว่าพร้อมไหม ถ้ายังไม่พร้อม ก็ไปเตรียมการด้านหลัง
- คนที่ต้องรันพิธีกรรมนี้คือ Scrum Master
- แต่ถ้าองค์กรไม่มี Scrum Master พี่หนุ่มบอกว่า ให้ยกทีมไปเทรนเรื่อง Problem-solving แล้วเอาคนที่มีประสบการณ์ด้าน Problem-solving มากสุดมารันพิธีกรรม
พอมีคนเรียนถามเรื่อง Scrum Master พี่หนุ่มก็เพลินไปกับเรื่องราวของ Scrum และ Scrum Master ตลอดไป ป ป ป
ถ้าทำแบบนี้ได้ จะอยู่ในโครงการแบบไหนก็ทำได้ แต่ต้องถามว่าคนแบบไหนที่จะอยู่ไม่ได้มากกว่า
เพื่อให้ Automation Work สั้นๆ คือ มันไม่มี ONE perfect solution ให้เริ่มจากเรื่องง่ายๆ ก่อน วิเคราะห์ก่อนทำอะไร เอา Feedback มาปรับให้ดีขึ้น
Regression Testing
จากนั้นก็ให้ชาวน้องต้าแชร์งานจริงให้ดู ว่าทีมมีวิธีการทำงานอย่างไร วางแผนงานอย่างไรในการทำ Automate Testing
- การทำ Automation ตามทีหลัง เละ และ เหนื่อยสุดๆ เพราะต้องนั่งหาทุกอย่างเอง API มีบ้าง ไม่มีบ้าง ใช้การแกะเอาจากหน้า Frontend
- พี่บอยก็นำเสนอ proxyman มาช่วย แต่มันก็ฉลาดเกิน เก็บมาหมด ก็ต้องมานั่งคัดอีก
- ถ้าให้ชีวิตสบายขึ้น ต้องทำ Automation ก่อน
Module 4: Testing Activities at the Release and Feature Level
- เป็นเรื่อง การเปลี่ยนจาก Needs → สิ่งที่ต้อง Deliver ได้
- เนื่องจากพี่หนุ่มหา slide ไม่เจอ เลยวาดเองใน Miro ซะเลย
- ตั้งต้นด้วย ระยะของโครงการ แบ่งเป็น ต้นโครงการ ดำเนินโครงการ ท้ายโครงการ
- เวลาเราเอา Iteration มาใช้ เราใช้ในช่วงของ “ดำเนินโครงการ”
- จากนั้นก็อธิบายการทำงาน ความแตกต่าง ระหว่าง Waterfall Model และ Iterative Development Model
- ถ้าจะใช้ Scrum แบบถูกต้อง จะรู้แผนงานก่อนเริ่ม Sprint
- ระหว่าง Sprint ทีมต้องส่งของที่ใช้งานได้ และพร้อมขายออกมา ไม่ใช่ตอนท้าย Sprint
- Product Backlog Refinement (PBR) ใน Scrum Guide เขียนว่า no more than 10% of the capacity team หรือตีความว่า 10% ของระยะเวลาทำงาน (10 วันทำการ)
- มีผู้เรียนถามว่า “ต้องใช้เวลากี่ชั่วโมงในการทำ PBR เพราะทีมรู้สึกว่า 3 ชั่วโมงก็นานไป” พี่หนุ่มเลยบอกว่า จะใช้กี่ชั่วโมงก็ได้ ถ้าได้ output (specification ที่ใช้ในการเขียนโค้ดและทดสอบ) ออกมาเท่าเดิม
- Scrum Team ของผู้เขียน Scrum Guide นั้น มีทักษะ ประสบการณ์ ความสามารถในการ Analyst and Design มายี่สิบกว่าปี คือทีมมี Maturity สูงปรี๊ดดด
- ถ้าทีมทำงาน (Development Team = Dev, QA และอื่นๆ) รู้ว่าเคสหลุด ก็ยกมือ แล้วเติมเข้าไป
- ไม่ว่าจะ Waterfall หรือ Iterative โอกาสที่จะคิดทุกอย่างได้ครบ เท่ากับศูนย์ เลยต้องหาวิธีจัดการรับมือกับมัน
- เดิมที่ออฟฟิศใครมีหน้าที่เตรียมของ เตรียม Specification? พอเปลี่ยนเป็น Scrum แล้วโยนภาระให้ Dev ทำเลยทันที ก็ทำไม่ได้ เพราะไม่เคยทำ ทักษะไม่มี
- ย้ำรอบที่สอง เราต้องการคนที่มี ทักษะ และ ประสบการณ์ ที่เคยทำพวกนี้ ระหว่างนั้นก็ต้องหาทางเพิ่มทักษะของคนที่ยังไม่เคยทำ เพื่อให้เก่งขึ้นด้วย
- ตัวอย่าง Product Backlog ที่ดี ให้ไปดูเว็บ Major Cineplex
- ถ้าทำงานเป็น Sprint — UAT ต้องเกิดในรอบการทำงาน
- Test-First Development เป็นวิธีปฏิบัติใน Software Testing อยู่แล้ว ไม่เกี่ยวอะไรกับ Agile โดยการมี Test Scenarios ทั้ง Functional และ Non-Functional ประกบไปกับ REQs ตั้งแต่ต้น
- มีของที่ต้องเตรียมก่อนเข้า PBR เสมอ ไม่ใช่ไปเตรียมกันใน PBR แบบนั้นมันทำอะไรไม่ทันแน่นอน
- บอกเล่า Case Study ของพี่หนุ่มสมัยอยู่ Rakuten TARAD ที่เอา Tester มาทำงานตั้งแต่ช่วงเก็บ REQs แล้วทำการเก็บสถิติเทียบว่า ก่อนทำ/หลังทำ งานในรูปแบบนี้ จำนวน Bugs น้อยลงอย่างไร (ซึ่งเทียบ Apple to Apple ไม่ได้ เพราะเป็นคนละโครงการ)
- เล่าตัวอย่างการวางแผนงาน ว่าควรจะทำ PBR อะไรตอนไหน ทำล่วงหน้าอย่างน้อย 2 Sprints หน้าตาเป็นยังไง
- เล่าการวางแผนงานในโครงการจริง ที่มีแผน A, B, C, D
Expand Tests + Think about Coding
เกิดในช่วง PBR ใช้ประมาณ 4–6 ชั่วโมง หรือมากกว่าถ้าระบบมันซ้ำซ้อน
จากนั้นเปิดตัวอย่างในชีวิตจริง เพื่อให้เห็นความยุ่บยั่บ (รายละเอียด) ของการเตรียมของใน PBR มีทั้งเรื่อง การลง ID ในแต่ละ Field ตัวอย่างข้อมูลจริงที่จะแสดง API Spec ที่มีทั้ง Request และ Response
- ที่ SCK การ Validate Field เป็นการคัดกรองข้อมูลก่อนประมวลผล ไม่นับเป็น Unit Test ชาว FE ต้องจัดการมาให้เรียบร้อย ซึ่งภาษาใหม่ๆ น่าจะมีใน Library ของแต่ละภาษาอยู่แล้ว
- เราไม่จ้าง Tester มาเพื่อ Validate Field
เราจะ Design Test Cases ออกมาได้อย่างไร
ที่นี่ จะได้ Test Cases ระดับ Unit Test ก่อน แล้วค่อยตามมาด้วย Test Scenarios
ที่เรากำลังคุยกันอยู่ตอนนี้ อยู่ใน Module 5 แล้วจ้า
Module 5: Testing Approaches and Techniques
คุณพระ! เล่ายังไงให้ผ่านไป 1 Module โดยไม่เปิด Slide 5555
- ATDD: Acceptance Test Driven Development
- BDD: Behavior-driven development เขียนในรูปแบบ Given, When, Then
- SBE: Specification by Example คุยแล้วเอา Data ประกบเข้าไป
Real examples ใส่ข้อมูล (ในชีวิต) จริงเข้าไป
- เพื่อให้ได้รายละเอียดที่ชัดเจน
- ลดความเข้าใจไม่ตรงกัน
- เป็นฟอร์มส่วนหนึ่งที่เรียกว่า Specification
- จะได้เข้าใจเรื่องราวของธุรกิจว่าเป็นเช่นไร
Activity: ทดลองให้ทำโจทย์ว่า การ Design Test Cases เป็นเช่นไร
แล้วก็อธิบายวิธีการคิด Case ในแต่ละหัวข้อ ถ้าสนใจ สามารถลงเรียนได้ที่ Be Skilled Software Tester the Series
- QA ในบริบทของ คุณ Janet ต้อง Provide Training Class ให้ทุกคนสามารถ Design Test Cases ได้
- Test เท่าที่ Code
- User Stories (XP) = REQs + Test Scenarios
- Test Scenarios ที่กำลังทดสอบ กำลัง Link ไปหา REQs ข้อไหน
- Test Scenarios ต้องมี Input Data และ Expected Result
- Thin Slide (ในบริบทของคุณ Janet และ คุณ Lisa) คือ ถ้าชิ้นใหญ่มาก ทำให้เล็กลงก่อน พอเล็กลงแล้ว มันยังดูใหญ่ไปอยู่ ก็ตัดตามเส้น Scenarios ทำสำเร็จก่อน แล้วค่อยตามด้วยไม่สำเร็จอีกที
- Exploratory testing คือการเอ๊ะเยอะๆ
- UI คำว่า สังเกต มีสระอุ มา เจอก่อนเขียนโค้ด เป็น Defect ถูกเปลี่ยนเป็น FE code แล้ว เป็น Bug เอ๊ะ หรือเป็น Defect ? ขึ้นอยู่กับการ Define ของแต่ละที่
- Agile ยังไม่ค่อย Work ในไทย เพราะไม่ได้เป็น Culture แบบต่างชาติที่ Feedback กันตรงๆ ได้
Module 6: Planning and Execution Activities at the Story Level
- การทำงานในแต่ละ Iteration (หรือ Sprint)
- QA เข้าร่วม PBR เพื่อ Design Test Cases, Test Scenarios, Test Source Code
- ในเมื่อทุกอย่างเป็น Automation Tests แล้ว ทุกคนต้องสามารถรันได้ ใช้งานเป็น
- ใน Sprint — QA ทำส่วนของ Exploratory testing ส่วน Dev ก็เขียนโค้น รันเทส เขียนโค้ด รันเทส สิ้นวันก็ต่อ Projector โชว์ผลงานจริง
Module 7: The End Game/ Success Factors
ไม่สอนเฉย แต่น่าจะมีสอนไปแล้วแหละ 55
ภายในคืนนี้หรือพรุ่งนี้ น่าจะมีอีเมลส่งออกจาก [Agile Testing Fellowship] เพื่อทำข้อสอบภาษาอังกฤษ ที่พี่หนุ่มจำไม่ได้แล้วว่า ข้อสอบเป็นเช่นไร ขนลุกส์
อ่านสองบทความก่อนหน้าได้ที่นี่
สำหรับใครที่สนใจคอร์สนี้ รอติดตามได้ที่ บริษัท สยามชำนาญกิจ จำกัด น่าจะเปิดสอนอีกที ปีหน้า (2567) และพิเศษ! สำหรับท่านใดที่มาเรียนรุ่นนี้แล้ว อยากจะส่งเพื่อนร่วมงาน หัวหน้างานมาเรียนบ้าง ทักมาขอส่วนลดพิเศษได้เลยที่อีเมล grow_up@scrum123.com นะจ๊ะ
เนื่องจากไปสอบมาแล้ว ก่อนเขียน Blog อันนี้เสร็จ ก็เลยขอมาประกาศกร้าวในนี้ด้วยว่า สอบผ่านแล้วเมื่อคืน (11 Nov 2023) อิอิ
