[บันทึกเด็กข้างห้อง] Holistic Testing: Strategies for Agile Teams Day 1 #LearningWithSCK

Workshop นี้ พี่หนุ่มได้ License จาก Agile Testing Fellowship โดย คุณ Janet และ คุณ Lisa ซึ่งคลาสนี้เป็นคลาสที่พี่หนุ่มสอนฟรี เพราะต้องการปัดฝุ่นตัวเอง หลังจากหยุดสอนไปหลายปี เนื้อหาในคลาสหลักๆ ก็คือมาจากสองท่านนี้ ทั้ง Presentation และ Handout

ถ้าเปิดคลาสปีหน้า ราคาน่าจะอยู่ประมาณ 30,000–40,000 บาท เพราะต้องจ่ายค่า Loyalty fee 200 USD และค่าข้อสอบอีก 20 USD

ตลอดทั้งคลาสนี้มีทั้งหมด 7 Modules

• Module 1: Agile — What is it? ในบริบทของคุณ Janet และ คุณ Lisa
• Module 2: Adapting to Agile
• Module 3: Making Automation Work ลงลึกเรื่องการทำ Automation มันมีเรื่องประมาณ 90% ที่ต้องทำให้เป็นอัตโนมัติด้วย การใช้เว็บหรือ API ยิง เป็นแค่ 10% เท่านั้น
• Module 4: Testing Activities at the Release and Feature Level การทดสอบจะอยู่ในแต่ละเลเวลอย่างไร
• Module 5: Testing Approaches and Techniques วิธีปฏิบัติว่าต้องใช้อย่างไร
• Module 6: Planning and Execution Activities at the Story Level สตอรี่ในที่นี้ไม่ใช้ User Story ที่เป็น As a, I want, so that.
• Module 7: The End Game/ Success Factors ช่วงปิดเฟสของการทำงาน และมีปัจจัยอะไรที่ทำให้ประสบความสำเร็จ หรือดีขึ้น

ใน Handout ที่ทุกคนมี จะเป็นการรันสไลด์และเล่นกิจกรรมหลายอย่างที่เราน่าจะโตเกินกว่าจะเล่นแล้ว เลยจะเปลี่ยนเป็นแชร์จากประสบการณ์พี่หนุ่ม และทำโจทย์ที่ใกล้เคียงชีวิตจริง พร้อมเปิดงานจริงให้ดู (ซึ่งถ่ายรูปไม่ได้นะจ๊ะ)

พรุ่งนี้ กับ วันศุกร์ จะมีการ Demo ว่า Programmer ที่ถูกปรับสภาพเรียบร้อย ทำแบบนี้เป็นปกติ การทดสอบแบบอัตโนมัติมันมีหน้าตาเป็นอย่างไร

ซึ่งพี่หนุ่มย้ำอีกครั้งว่า ถ้ารักชอบคลาสนี้ แล้วไปสปอยล์กับที่ทำงาน ให้มาเรียนปีหน้า รายละเอียดครั้งหน้าก็จะไม่เหมือนเดิม เพราะไม่เคยเหมือนกันเลย

Module 1: Agile — What is it?

กิจกรรมแรก

แนะนำตัว ชื่ออะไร อยู่ที่ไหน ทำอะไร/ความสามารถหลัก ประสบการณ์กับ Agile (จำนวนปี และใช้อะไรอยู่บ้างตอนนี้)

ปัญหาที่เจอจากบริบทคุณ Janet และ คุณ Lisa (จากต่างประเทศ) 🥴

1. ทีมเป็น Silo ไม่ว่าจะมีกี่ทีม เช่น SA, BA, QA, Dev (FE, BE) และอื่นๆ ตอน Waterfall แบบไหน ปรับมาใช้ Agile ก็แบบนั้นแหละ แล้วก็ ส่งสาร/สื่อสาร กันอย่างแย่ ที่เห็นส่วนมาก ก็คือการส่งเอกสารต่อกัน แล้วก็ไม่คุยกัน
2. การทดสอบเป็นช่วงสุดท้ายของแต่ละรอบการทำงาน ไม่เคยมีเวลาพอที่จะทดสอบให้เสร็จ (เพื่อให้เห็นภาพมากขึ้น พี่หนุ่มก็สลับสไลด์ไปเป็นของ SCK ก่อน เพื่อเล่าวิธีการทำงานในรูปแบบ Waterfall และ Sprint ของ Scrum ซึ่งส่วนมากจะเป็นรูปแบบของ mini-waterfall อยู่ดี)
3. มีการเปลี่ยน REQs (ความต้องการ) ตลอดเวลา แต่ก็ไม่คุย ไม่สื่อสารกัน
4. Tester ไม่ได้เข้าไปมีส่วนร่วมด้วยตั้งแต่ต้น ไม่ได้ช่วยออกแบบชุดการทดสอบตั้งแต่แรก ถึงแม้จะถูกผลักให้เข้าไป แต่ก็ทำอะไรไม่ได้ เนื่องจากไม่มีความเข้าใจเรื่อง Business Domain นั้นๆ และยังหา REQs ที่ถูกซ่อนไม่เจอ ซึ่งต้องเอา Test Scenarios แนบไปด้วยตั้งแต่แรก
5. ไม่มีความเข้าใจเรื่อง REQs ซึ่งส่วนใหญ่ IT ก็จะโบ้ยไปหา Business User แต่บางทีทั้ง User และ IT ก็ไม่เข้าใจ Business นั้นด้วยกันทั้งคู่
6. Dev ไม่มีการทำเรื่อง Unit Testing ซึ่ง ถ้าถอยไปตอนเรียนมหาวิทยาลัยสมัยกระนู้น ก็ไม่ได้มีสอนเรื่องนี้ หรือบางที่สอน พอจบออกมาก็ไม่ได้ใช้

ไม่มีเวลาทำให้มันดี แต่มีเวลา แก้ของที่เสีย ตอนท้าย — คำพูดที่เกือบ Copy มาจากพี่ปุ๋ย somkiat.cc

ศัพท์ที่จะใช้ในการเรียนคลาสนี้

Iteration

• Time boxed delivery มีกำหนด Set ของเวลาชัด
• Time boxed คือ กรอบระยะเวลา ถ้าเป็น Scrum คือ The Sprint (ระยะเวลาไม่เกิน 1 เดือน)
• Delivery = ส่งมอบซอฟต์แวร์ที่ใช้งานได้จริง บน Pre-Production Environment (เป็น Production อีกชุดหนึ่ง) หรือพร้อมที่จะเปิดใช้บน Production Environment ซึ่งส่วนมากที่เจอตอนนี้จะเป็น UAT ก็ต้องดูว่า เราเชื่อผลการทดสอบบน UAT ได้ไหมว่าขึ้น Production ไปแล้วมันจะไม่พัง
• จำง่ายๆ จบ 1 Sprint (ที่นิยมใช้คือ 10 วัน) ต้องมีของพร้อมใช้บน Pre-Production หรือ Production
• Iteration (Iterative) เป็นรากฐานของ Scrum

Kanban

• Flow-based delivery
• เป็นการเปลี่ยน Item ทีละหนึ่ง ผ่านกระบวนการทำงาน (Process) ที่ 1, 2, 3, 4, 5, … แล้วได้ออกมาเป็น Software ที่พร้อมใช้งาน
• ให้นึกถึงไลน์การผลิตในโรงงานอุตสาหกรรม ที่ทำของออกมาทีละชิ้น
• ถ้าเป็น Process ของการ Testing เจอ Bugs ก็ต้องแก้ให้เสร็จ ก่อนจะไปทำชิ้นอื่นได้
• Kanban board เป็นศัพท์ที่ Toyota เอามาใช้ ซึ่งที่ Toyota ไม่มี Kanban board แต่มี Visualized board
• เมื่อเอามาใช้ในบริบทของ Software แต่ละชิ้น Item จะใช้เวลาไม่เท่ากัน

Whole Team

• The delivery team
• “ทีม” จะต้องประกอบด้วย ผู้ที่มีทักษะ องค์ความรู้ ทั้งเชิง Business Domain (Domain = ขอบเขตความรู้ //แปลเอง) และ Technical และ ประสบการณ์ ในการปรับเปลี่ยน Requirements ให้เป็น Software ที่พร้อมใช้งาน
• ถ้าไม่มี ทักษะ ความรู้ ประสบการณ์ ต่อให้เป็น Waterfall ก็ส่งมอบงานไม่ได้
• ให้คิดถึงทีมกีฬา ที่ทุกคนมีเป้าเดียวกัน ที่ทุกคนต้องชนะไปด้วยกัน

Business Value

• สิ่งที่ทำ ทำไปทำไม ไม่ใช่แค่ทำให้เสร็จ
• value to the business/customer ของที่ส่งผลิต มีคุณค่าทางธุรกิจอะไร หรือลูกค้าจะได้อะไร
• ถ้า Waterfall ไม่ใช้ มาเป็น Agile มันก็ไม่มี
• ถ้า Waterfall นับชิ้นงาน มาเป็น Scrum ก็นับชิ้นงานเหมือนกัน ซึ่งมันไม่ได้

Prioritization

• คิดว่าจะทำอะไรก่อนหลัง ซึ่งจะมาพร้อมกับ Business Value
• ถ้าไม่มี value มันจะเรียงลำดับตามความเสียงดัง (ความคนใหญ่คนโต)

Done

• Coded & Tested (Think Levels) ที่ต้องมีการคิด และคุยกันตั้งแต่แรก
• การจะเอาของขึ้น Deploy ได้ จะต้องทดสอบอะไรบ้าง ต้องมี checklist อะไรบ้าง (แล้วพี่หนุ่มก็เปิดไฟล์ตัวอย่างที่เป็น Excel ให้ดู)
• Functional Test และ Non-Functional Test

Velocity

• ไม่มีใน Scrum ไม่ใช่การเก็บ Story Point
• เป็นการวัดปริมาณงานที่ออกในแต่ละหนึ่งช่วงเวลา ใน 1 รอบการทำงาน ว่าทีมงานสามารถส่งของออกได้กี่ชิ้น ที่มีความพร้อมที่จะ Deploy to Production
• หลังจากทำไปแล้ว ทำเสร็จมาก็ต้อง revisit อีกทีหนึ่ง
• พี่หนุ่มแนะนำให้เลิกใช้ มันไม่ช่วย และไม่เห็นบริษัทไหนจ่ายเงินเป็น Story Point

ข้อตกลงอะไรที่ต้องใช้ร่วมกัน อย่าเขียนเป็น Text ให้ทำออกมาเป็นภาพ ถ้ามีตัวอย่าง ให้เอาตัวอย่างประกบไปด้วย

Feature (epic) — Stories — Tasks ในบริบทของ คุณ Janet และ คุณ Lisa

Feature (epic)

• เรากำลังจะเพิ่มความสามารถอะไรเข้าไปในนั้น มันใหญ่มาก
• ลูกค้าต้องชำระเงินด้วย Cryptocurrency ได้

Stories

• ส่วนหนึ่งของ function ที่สามารถพัฒนาให้เสร็จได้ ภายใน 2–3 วัน
• ลูกค้าต้องชำระเงินด้วย Bitcoin ได้ สำเร็จ
• ลูกค้าต้องชำระเงินด้วย Bitcoin ไม่สำเร็จ
• ลูกค้าต้องชำระเงินด้วย USDC ได้ สำเร็จ
• ลูกค้าต้องชำระเงินด้วย USDC ไม่สำเร็จ

Tasks

• แต่ละทีมงานต้องเขียน Task เพื่อให้ทำของให้สำเร็จ
• 1 Task ไม่ควรเกิน 1 วัน

คำที่พี่หนุ่มคาดการณ์ว่ากำลังจะระเบิดเป็นคำฮิต คือ DORA

Google’s DevOps Research and Assessment (DORA) team identified four key metrics for evaluating a team’s performance:

1. Lead time for changes
2. Deployment frequency
3. Mean time to recovery
4. Change failure rate

Agile ในบริบทของ คุณ Janet และ คุณ Lisa

1. ให้ Feedback loop มันสั้น เพื่อให้รู้ว่า สิ่งที่ทำอยู่ มันใช่ หรือ ไม่ใช่
2. Business จะต้องเข้ามามีส่วนร่วมโดยตลอด ไม่ได้แปลว่า ต้องมาอยู่ทุกวัน แต่ โทรไปต้องรับ ไลน์ไปต้องตอบ
3. ทีมที่มีต้อง “ร่วมหัวจมท้ายด้วยกัน” เห็นว่า QA งานหนัก ทีมงานส่วนอื่นก็ต้องไปช่วยงาน QA ด้วย ไม่ใช่บอกว่า “สู้ๆ นะ”
4. ทำการทดสอบ Features หรือ Stories เท่าที่สั่งผลิต (ที่ถูกป้อนเข้ามาใน Sprint) และ Test ของเดิมที่เคยทำงานผ่านด้วยนะ
5. ส่งมอบ Business Value หรือ Outcome หรือ ผลลัพธ์ที่เกิดขึ้น (ซึ่งสัมพันธ์กับข้อ 1.) เป็นประจำและเรื่อยๆ
6. ทำงาน วันละไม่เกิน 8 ชั่วโมง และ สัปดาห์ละไม่เกิน 40 ชั่วโมง ทุกคนในทีม ต้องการ การพักผ่อน และเวลาส่วนตัว (มีอยู่ใน Extreme Programming: XP)
7. ต้องปรับ Process การทำงานเกือบทุกวัน ทั้งภาพย่อยและภาพใหญ่

Sustainable Pace (extremeprogramming.org)

การก่อร้าง สร้าง Agile

• Changes ทุกอย่างต้อง เพิ่ม ลด ปรับ แก้ ได้
• ทำยังไงให้เกิด Trust นัดส่งก็ต้องส่ง ไม่เลื่อน
• รวมโค้ด และ ทดสอบบ่อยๆ (Continuous Integration)
• มีวินัย ฝึก เพิ่มความรู้บ่อยๆ ให้สม่ำเสมอ
• พยายามเน้นการวาดภาพเป็น Flow อย่าคุยกันเป็นคำแล้วพยักหน้าหงึกๆ
• อะไรใช้เครื่องมือมาทำแทนได้ ให้เปลี่ยนเป็น อัตโนมัติ = Build + Tests + Deploy (Rollout + Rollback)
• Retrospectives คือ การหยุดแล้วมองดูว่า มีจุดไหนที่ต้องปรับให้มันดีขึ้นบ้าง (การส่องกระจกทุกวัน มีปัญหาปุ๊บแก้เลย) ถ้ามีผลกับการส่งมอบ ต้องคุย หา Root Cause เลยทันที ไม่ต้องรอ Retro แล้วค่อยคุย แนะนำให้เลิก Good, Bad, Try แล้วเปลี่ยนเป็น Problem-solving (fishbone, 5-Whys)

จากนั้นพี่หนุ่มก็เล่าที่มาที่ไปของคำว่า Agile ว่าเกิดจากลุง 17 คน ว่าแต่ละคนใครคิดอะไร ใช้อะไรกันอยู่ ไปรวมตัวกันที่สกีรีสอร์ตแห่งหนึ่ง แชร์กันไปมา แล้วก็โหวตคำ ระหว่าง Agile กับ Flexible ผลโหวตออกมาเป็น Agile จบจ้ะ

แล้วก็ปูพื้นเรื่อง Scrum Framework

เกิดจากการทำซ้ำจาก คุณ Jeff และคุณ Ken ถูกสร้างขึ้นมาจาก

1. The New, New Product Development Game (paper)
2. ศึกษา TPS 2 ปี ที่โตโยต้า ปัจจุบันเรียกว่า Lean
3. Iterative, Incremental Development
4. Timeboxes

เอาไปทดลองใช้ Smalltalk Development Tools แล้วก็ออกมาเป็น Scrum ซึ่งชื่อนี้ก็มาจากกีฬารักบี้

👩‍🔬 Empirical Process (การทำการทดลอง)

• Transparency
• Inspection
• Adaptation

Scrum มีหนังสือด้วยชื่อ Agile Software Development with Scrum (Series in Agile Software Development) 1st Edition

แต่ทุกวันนี้ที่เราใช้กัน มาจาก Scrum Guide ก็มีประมาณ 19 หน้า บางๆ เบาๆ ตัวอักษรล้วนๆ ซึ่งมีส่วนหนึ่งกล่าวว่า Scrum ไม่ใช่ Process ไม่ใช่ Technique หรือ Method เอาไปใช้กับอะไรก็ได้ ถ้าเอาไปใช้แล้วผิด ก็โทษตัวเองนะจ๊ะ

Scrum Guide เป็นการบันทึกจากสิ่งที่ คุณ Jeff คุณ Ken คุณ Mike ทำมา กับ Dev ที่มีประสบการณ์ ทักษะ วุฒิภาวะสูงระดับยี่สิบปี

อธิบายการทำงานแบบ Scrum จาก Scrum Guide ที่พี่หนุ่มตีความออกมา

ถ้าเทียบเข้ามาในชีวิตจริงสมัยเรียนปริญญาตรี

• Product Backlog = สิ่งที่ต้องเรียนให้ครบตลอด 4 ปี
• Sprint Backlog = ตารางเวลาชีวิต 🗓️

แล้วผู้เรียนก็ถามว่า แล้ว Scrum Master ต้องทำอะไร ทีนี้พี่หนุ่มก็เพลินเลยสิ เปิด Scrum Guide มาอธิบายกันไปเลย เอกสาร Official Scrum Guide ตั้งแต่ปี ค.ศ. 2010 ถึง ค.ศ. 2020 | by Prathan D. | Scrum123 ปลา ฉลาม ขึ้น บก

ถ้าให้เทียบในชีวิตจริง Scrum Master คือ ครูสอนว่ายน้ำ ที่สอนตั้งแต่ว่ายน้ำไม่เป็น พาว่าย จนกระทั่งปล่อยให้ว่ายเองได้

ถ้าต้องการเปลี่ยนองค์กรมาใช้ Scrum คุณ Bas Vodde บอกว่า ต้องใช้เวลาเท่ากับเวลาที่ก่อตั้งองค์กรมา

ถ้าองค์กรไม่พร้อมเปลี่ยน Scrum Master จะเป็นคนที่น่ารำคาญมาก

หลายๆ เรื่องที่ Scrum Master ต้องทำ มีคนทำอยู่แล้วในบริษัท หาคนนั้นให้เจอ แล้วดูว่าคนๆ นั้นทำได้ไหม หรือทำไม่ได้ เพราะงานยุ่ง

กับอีกตัวที่อยากให้รู้จัก คือ Extreme Programming (XP)

ทุกคนอาจจะคุ้นเคยบางคำศัพท์อยู่แล้ว แค่ไม่รู้ว่ามาจาก XP ยกตัวอย่างคำศัพท์ เช่น User Story, Story Points, Velocity, TDD, CI, CD, Standup meeting

Extreme Programming Rules

ถ้าทำ Software จำเป็นต้องใช้ XP เพราะ Scrum ไม่สามารถนำมาใช้ทำ Software ได้

ระดับ Release

ระดับ Iteration

ระดับ Development

ระดับการทำงานของ Developers

ซึ่งปีหน้า พี่หนุ่มคาดว่าจะสอน XP แบบลงรายละเอียด ซึ่งใช้เวลา 3–4 วัน

Agile:

• Iterative or flow-based
• Incremental
• Each story is expanded, coded and tested
• Possible release after each iteration

Test Approach — The Agile Way

แบ่งออกเป็น 5 ช่วงคือ

1. Cycle initiation ทำความเข้าใจมุมมอง เป้าหมายทางธุรกิจ ปัญหาที่ต้องแก้ Business Goal หรือภาพปลายทางที่จะต้องไป [Waterfall ก็ต้องทำอยู่แล้ว]
2. Release / Feature Planning เราจะได้จำนวน Iteration(s) และ Feature(s) หรือ Storites ของแต่ละ Iteration การทดสอบต้องเห็นภาพใหญ่ของการทดสอบ รู้เรื่องการทดสอบทุกประเภท ความเสี่ยงที่อาจเกิดขึ้น การตั้งสมมติฐานต่างๆ ในแต่ละ Stack แต่ละ Level ต่างๆ รวมถึงการเชื่อมต่อไปกับระบบอื่น (เปิดตัวอย่างงานจริงให้ดู ซึ่งถ่ายภาพไม่ได้นะจ๊ะ) [Waterfall ก็ต้องทำอยู่แล้ว]
3. Each Iteration 1, 2, …, X ทำการประเมินการทดสอบของแต่ละ Task
   Monitor เรื่อง regression test results (automation)
   ร่วมมือกับลูกค้าในการทำ acceptance tests (UAT: User Acceptance Test) ทดสอบ ตรวจรับ ระดับ functional requirements ว่าส่งมอบครบถ้วนไหม + ทดสอบ ตรวจรับ Non-functional requirements
   เขียน → automate → execute new story tests
   ทำงานกับ tester คนอื่นและ developers อย่างใกล้ชิด
   เตรียม exploratory test (manual) คือ ทำการทดสอบอยู่ดีๆ แล้วก็เอ๊ะ ถ้ามันเป็นแบบนี้ล่ะ แบบนั้นล่ะ
4. System Test / End Game ทำ FINAL load test, regression test, system testing, UAT รันทุกอย่างอีกครั้ง เพื่อให้เห็นภาพว่าทุกอย่างปกติสุข
   แล้วก็เตรียม mock deploy (ซ้อม deploy ทั้ง Rollout และ Rollback) รวมถึงเข้าร่วม release readiness
5. Release to Prod / Support เข้าร่วม release to prod, monitor production analytics และเข้าร่วม retrospectives

DevOps ที่แปลว่า Continuous Delivery ไม่ใช่ DevOps ที่เป็นตำแหน่ง

https://octopus.com/devops/

https://janetgregory.ca/testing-from-a-holistic-point-of-view/

Quality ใน Software ไม่ได้หมายถึงการไม่มี Bugs เยอะ

• คนอื่นมาทำต่อไม่ได้ ตกเรื่อง Maintain
• ถ้าเขียนเทพ แต่เอามาทำ Unit Test ต่อไม่ได้ ก็ตกเรื่อง Testability

https://slideplayer.com/slide/16139052/

ถ้าจะเอา Agile มาใช้ ต้องไม่มีเฟส Test แล้ว เพราะ Test จะกลายเป็น Activities หรือ Tasks งาน

Module 2: Adapting to Agile

Whole team = Delivery team กลุ่มคนที่มีทักษะในการปรับเปลี่ยน Requirements ให้เป็น Software ที่พร้อมใช้งาน

• เราไม่ได้ต้องการ Role เราต้องการทักษะของทุกคน
• ต้องเอา Silo ทิ้งออกไปให้ได้ก่อน

https://www.autofun.co.th/news-motorcycles/2022-chariot-with-two-motorcycles-tied-together-for-the-ride-44661 ไม่ใช่รูปของคุณ Lisa และ Janet แต่ให้อารมณ์ประมาณนี้

ทั้งทีมจะรับผิดชอบเรื่องการทดสอบด้วยกัน ถ้ามีปัญหาเรื่องการทดสอบ ทุกคนจะต้องช่วยกัน

T-Shaped

ทำยังไงให้คนเดิมที่อาจจะมี Skill หลักอะไรบางอย่างอยู่แล้ว จะมี Skill เพิ่ม เป็น Multi-skill

https://maharshisinha.hashnode.dev/which-shaped-engineer-you-are

Communication and Collaboration 🗣️

• Communication แปลไทย คือ การติดต่อสื่อสาร การแบ่งปัน ไอเดีย/ข้อมูล/การตัดสินใจ/solutions/สิ่งที่เกิดขึ้นต่างๆ โดยต้องรู้จักคนที่เราสื่อสารด้วย (audience)
• Collaboration การร่วมมือกันแก้ไขปัญหา หา solutions ร่วมกัน
  ในบริษัทใหญ่จะมีบางกิจกรรมที่ทุกคนร่วมมือกันดีมาก เป็น Self-manage ไม่ต้องมี PM, PO ไม่ต้องมี Report แต่พอถึงวันส่งมอบงานทุกอย่างเนียนกริ๊บ เกิดขึ้นปีละครั้ง กิจกรรมนั้นได้แก่ “กีฬาสี”

Tools ที่มีใน Slide แต่ไม่ลงรายละเอียด (ไปอ่านเอาเอง)

• Impact Mapping
• Mind Mapping

Mini-Waterfall ที่อยู่ใน Iteration

จะเห็นอยู่ 2 รูปแบบ ที่ไม่ว่ากี่ปีผ่านไป (อาจจะเป็นสิบๆ ปีแล้ว) ก็ยังตกสภาพนี้กันอยู่ดี

• ซึ่ง Test ในที่นี้ต้องเสร็จทั้ง Functional และ Non-Functional ด้วย เพราะเราคุยกันในบริบทที่ “ของพร้อมให้บริการ” (หรืออาจจะพร้อมบน UAT ก่อน ณ ตอนนี้)
• ใน Scrum มีการ Set Priority แปลว่ามีคิว แปลว่าทำทีละหนึ่งชิ้น ทำเสร็จ ทดสอบ แก้ไข พร้อมใช้ ไม่ใช่หยิบมาทำพร้อมๆ กัน แบบนั้นจะเรียงลำดับความสำคัญไปเพื่อ?

แล้วเราจะหลีกเลี่ยง Mini-waterfall ได้อย่างไร?

1. Integrate testing and coding ให้ทำการ Code และ Test บ่อยๆ ตลอดทั้งวัน ซึ่งการเตรียมการอาจจะเป็นคนทำ แต่พอเป็นช่วงดำเนินการทดสอบให้เป็นอัตโนมัติ
2. Focus the whole team on testing ทุกคนยกระดับความสำคัญของการทดสอบ
3. Limit Work In Progress ณ หนึ่งช่วงเวลา ทำงานเท่าที่ไหวและทำทีละชิ้น ไม่ทำ multi-tasking
4. Rule of thumb for story size งานชิ้นหนึ่งต้องเสร็จ (เขียนโค้ดและทดสอบ) ภายใน 2–3 วัน ในรอบการทำงาน 10 วันทำการ
5. ถ้าเขียนโค้ดไม่เสร็จ ทดสอบไม่เสร็จ แก้ไขบั๊กไม่เสร็จ Story นั้นจะไม่ถูกเรียกว่า Done ซึ่ง Tested = Functional tests + Nonfunctional tests
6. Under commit กินข้าวเท่าที่ไหว ถ้าเจอผู้บริหารสายยัด สิ่งที่จะช่วยคือทีมเราได้คือ ต้องเก็บสถิติว่าแต่ละชิ้นใช้เวลา (ชั่วโมง) เท่าไหร่ในการทำงาน ถ้าเก็บได้ทั้งปีให้เก็บด้วย

🚧 Barriers to a successful transition

1. 1 คนอยู่มากกว่า 1 ทีม
2. ทีมทดสอบก็ยังแยกกันอยู่
3. ไม่มีคำศัพท์ หรือภาษาที่ทุกคนเข้าใจตรงกัน
4. ขาดทักษะในเชิง Technical หรือเครื่องมือที่นำมาใช้
5. ข้อจำกัดในเชิงกายภาพ เช่น พื้นที่ทำงานไม่สะดวก
6. การทดสอบอยู่ช่วงท้ายเสมอ

Other Pitfalls

1. ลืมภาพใหญ่ สนใจแค่ของที่อยู่ใน Sprint
2. รอ Build ต้องรอใครซักคนเป็นคนทำ ซึ่งไม่ควรเป็นเช่นนั้นแล้ว เพราะตอนนี้เรามี DevOps คำถามคือ เรา build วันละกี่ครั้ง? build แล้ว deploy เลย หรือมี test อยู่ในนั้น?
3. Testing ไม่ได้เป็นส่วนหนึ่งของทีม
4. Test ถูกดันไปเป็น Manual “ทำงานไม่ทันแล้ว อย่าไปทำ Automation เลย งานมันรีบ” พอเวลาผ่านไป “ความว่าง” ก็ไม่เคยมี ก็ทำการทดสอบแบบ manual วนไป ซึ่งข้อนี้จะมีความสัมพันธ์เกี่ยวข้องกับ Lack of technical or tools skills

Defect Tracking

เป็น Group Activity 5 นาที เขียนแล้วเล่าให้เพื่อนในกลุ่มฝั่งว่า ถ้าเจอ Defect เกิดขึ้นตอนทดสอบ ทีมเราทำอะไรบ้าง?

จากผลลัพธ์ของทุกกลุ่ม ทุกคนเหมือนจะเขียนว่า QA ทำงานอะไร แต่ไม่ได้รับมือกันในระดับทีม

🐞 แล้วถ้าเปลี่ยนมาทำงานเป็น Agile เรามีวิธีจัดการ Defects อย่างไร?

ในประสบการณ์ของ คุณ Jenet กับ คุณ Lisa ที่มีประสบการณ์ตรงกับ Extreme Programming

Consider alternatives

• สร้างการ์ดบนผนัง (ที่ไม่ใช่ jira) ให้เขียน Bug ลงกระดาษ แล้วแปะลงไปในช่อง Doing แล้วแปะไว้กับแม่มัน ไม่ว่าจะเป็น Feature หรือ Story ถ้าลูกยังไม่แก้ แม่จะเคลื่อนไปที่ Done ไม่ได้
• ทุกวันนี้เรามีการใช้ Figma กันแล้ว ทำไมเราถึงต้องเขียน Test Steps หรือเอา Steps ไปใส่ใน Scenarios อีก ถ้า Figma เปลี่ยน เราก็ต้องแก้ (ถ้าเค้าแจ้ง) แต่ถ้าเค้าไม่แจ้ง ก็จะยึดตาม version ล่าสุดที่ Tester ได้รับมา ก็ผิดต่อเนื่องไปอีก
• ถ้าเป็นการทำงานแบบเดิม เราจะเจอ Bugs ก้อนใหญ่ๆ ช่วงท้ายของการทำงาน ซึ่งตอนนั้นก็จะมีเรื่อง Change, New เข้ามาด้วย ก็เลยเกิด severity level เข้ามาเป็น Critical-High-Medium-Low จะได้รู้ว่าต้องแก้อะไรก่อน จากนั้นก็เพิ่มความซับซ้อน เพราะ Critical มีหลายตัว ด้วยการใส่ Priority ของแต่ละ level เข้าไปอีก เป็น High-Medium-Low แล้วก็ใส่แบบนี้ไปทุก level
• คำแนะนำ ถ้าทำงานเป็น Sprint ถ้าเป็น Low เจอปุ๊บแจ้ง แก้เลย ถ้า Dev ไม่แก้ ยกโน้ตบุ๊คไปนั่งข้างๆ ถ้าทำงานออนไลน์ก็แปะภาพ แล้วก็ตามมันทุกชั่วโมง

Defects are queues of rework (waste)

• ยิ่งโค้ดไปทับของที่ผิดมากเท่าไหร่ เวลาที่ใช้ในการแก้จะเพิ่มขึ้นเท่านั้น
• ยิ่งสะสมไม่รีบแก้ไข ก็ยิ่งเกิด Technical Debt (หนี้สิน)
• ถ้าตรวจเจอ ต้องรีบแก้ไขทันที
• เวลา Tester ตรวจพบ Bugs เวลาเฉลี่ยในการเขียน log คือ 5–20 นาที ในชีวิตที่ผ่านมา log มากสุดกี่ตัว? ก็คูณเวลาเข้าไป ซึ่งเวลานี้ใช้เพื่อรายงานข้อผิดพลาด แล้วก็ไปเข้าคิว

Focus on prevention, not tracking

• ให้ความสำคัญกับการป้องกัน defects มากกว่าการตาม track
• ทำยังไงให้เกิดปัญหาน้อยที่สุด เราทำให้มันเป็นศูนย์ไม่ได้ แต่เราคุมกำเนิดได้

Zero tolerance

• เจอ แก้ เจอ แก้ ทุกรอบการทำงาน จะไม่มีบั๊กหลุดออกมา
• เจอปุ๊บ แล้วถ้า Bugs ตัวนั้นไม่มี Test Scenarios ประกบให้ Design Test Scenarios เพิ่มขึ้นมา
• แต่ถ้ามี Test Scenarios ให้ Fix แล้ว Retest ทดสอบว่าบั๊กหายไหม และ Regression Test
• ถ้า Dev เป็นคนแก้บั๊ก คนจะ Retest คนแรกคือ Dev ก่อนส่งกลับหา Tester (Regression Test ก็เช่นกันนะจ๊ะ)

• Regression Test ทดสอบว่า การแก้ไขบั๊ก ส่งผลกระทบกับระบบหรือไม่ ซึ่งทำทั้ง Functional Tests และ NonFunctional Tests

• Regression Test เป็น Automation เท่านั้น ใช้คนทำไม่ได้ กดปุ๊บต้องรู้ผลเลยทันที ใช้เวลา 5–10 นาที

• พอทำ Regression Test ที่มี Test Scenarios อยู่ในนั้นอยู่แล้ว ก็ลืมไปเลยว่าเคยมี Bugs ตอนนี้ เพราะมันจะถูกทดสอบซ้ำๆ อยู่แล้ว
• แก้ “บั๊กตัวแม่” ได้ บั๊กตัวลูกจะหาย
• ระบบเราทำงานผิดพลาดจากอะไร จาก Input ที่ระบบอื่นใส่เข้ามาหรือเปล่า ต้องคิดวิเคราะห์ก่อนด้วย
• ทุกคนน่าจะต้องเจอ Legacy code ไม่ได้แปลว่า code เก่า แต่แปลว่า code ที่ไม่มี unit test หรือยากที่จะเข้าใจ จะไปใช้งานต่อ
• “ช่างมัน” ถ้าเรารู้ว่า ระบบนี้จะต้องถูกเขียนใหม่อยู่แล้ว โดน Replace แน่ๆ ก็ไม่ต้องไปแก้มัน

เจอ แก้ เคลียร์ให้จบ และทำให้เป็น Automation ให้ได้ ให้ลงทุนที่ Unit test มากกว่า API และ UI

แล้วเราจะจัดการ tracking defects เมื่อไหร่?

• ถ้าเราใช้ Zero tolerance ก็ไม่จำเป็นต้อง Tracking Defects อะไรทั้งสิ้น
• ถ้าเรามีหลายทีมที่ทำงานอยู่คนละที่ ก็อาจจะจำเป็นต้องใช้
• ถ้าเราเจอระบบที่มีความซับซ้อน หรือใหญ่มากๆ ก็มีความจำเป็นที่ต้อง track อยู่
• ถ้าเรา log แล้วไม่ได้ใช้ประโยชน์ แค่ไป Generate report ก็ไม่ต้อง log ละเอียด แต่ถ้ามีคนเอาไปใช้งานต่อ เช่น ใช้ใน Retrospective (ดีกว่า Good, Bad, Try) หรือ เอาไปดูลักษณะของเทรนด์ หรือ density ที่มันเกิดขึ้น เพื่อเอาข้อมูลไปใช้ต่อในเชิงการป้องกัน ก็ log ได้

Requirements Traceability

• ถ้าใครเคยใช้ RTM มาก่อน ก็คือ เดิม Requirement ID นี้ เจอกับ Code อะไร เจอกับ Test ID อะไร กี่อัน และสามารถ Track กลับได้
• เมื่อเราเปลี่ยนมาเป็น User Story ของ XP ที่มี Test Scenarios ประกบ มันก็ Link ไปหากันได้เช่นกัน
• ถ้ามีความจำเป็นต้องทำ เพื่อส่งมอบงาน เพื่อเงิน หรือเพื่อ Certified อะไรบางอย่างก็ทำไป

Quality Models, Audits & Governance

• ถ้าต้องประยุกต์การทำงานเป็นรอบแบบ Agile เข้าไป ของพวกนี้ก็จะติดแข้งติดขาไปด้วย ต้องหาวิธีจัดการกันเอาเอง
• เริ่มจากการถามก่อนว่า Why? What? และ For Whom?

สงสัยความแตกต่างของ Bugs, Issues, Defects อยู่เหมือนกันว่า มันต่างกันยังไง พอไป search ดันเจอคำเพิ่มอีก Flaws, Faults, Failures, Errors ซึ่งก็ไม่รู้ว่า นิยามของเขาและเราเหมือนกันไหม

อันที่จริงก็เคยเขียน Module 1–2 ไปแล้วเมื่อครั้งกระนู้น

• Holistic Testing: Strategies for agile teams — Module 1: Agile — What is it? #LearningWithSCK
• Holistic Testing: Strategies for agile teams — Module 2: Adapting to Agile #LearningWithSCK

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

Reflect ตัวเอง

เนื่องจากคลาสก่อนเป็นการเรียนตั้งแต่ช่วงต้นปีที่ผ่านมา (และพี่หนุ่มยกเลิกสอนไปก่อนหลังจากเรียนได้สองครั้ง เอ้า!) และเป็นการเรียนออนไลน์ แล้วก็เพิ่งมา Join SCK ได้ประมาณสี่เดือนกว่าๆ ก็ยังเอ๋อๆ เบลอๆ อยู่

• พอผ่านการทำงานมาได้สักพัก ได้ลงงานจริงมาหลายๆ โครงการ
• รวมถึงการอ่านหนังสือหลายเล่มที่พี่หนุ่มโยนมาให้ (อ่านจบบ้าง ไม่จบบ้าง)
• และการเรียนนู่นนี่เพิ่ม คลาสที่ระบุชื่อได้ เช่น RSM, RPO, PMP หรือคลาสที่ไม่ได้ระบุชื่อ

พบว่าหลายอย่างในคลาสนี้ที่เคย งง และ เบลอ เห็นภาพชัดขึ้นมาก เข้าใจมากขึ้น (แม้บางหัวข้อจะยังเอ๋ออยู่บ้างก็ตาม 55+)