EP.12 to Prevent defects, Not to find them

เส้นทางสู่การเป็น Tester 🐞 Bootcamp by WeLoveBug (28–31 สิงหาคม 2566)

และแล้วก็เดินทางมาถึงสัปดาห์สุดท้ายของโปรเจคการเงินการธนาคาร ความพิเศษของสัปดาห์นี้คือเป็นสัปดาห์แรกของการทำงานใน Sprint ที่ 1 ควบคู่กับการเตรียมของสำหรับ Sprint ที่ 2–3

แผนการทำงานใน Sprint ที่ 1 สำหรับสัปดาห์นี้

จากแผนจะเห็นว่า มีการแยกสีในแต่ละ Role เอาไว้ด้วย เพื่อให้ทุกคนสามารถเข้า Review หรือ Meeting ได้ตามหน้าที่และบทบาทของตน ซึ่งในแต่ละวันก่อนที่จะเริ่มการทำงาน เราจะมีการเข้า Workshop ที่เรียกว่า “Coding Dojo” ร่วมกันเสียก่อน

Coding Dojo คืออะไร?

• Coding หมายถึง การเขียนโค้ด (Code) หรือโปรแกรม
• Dojo “Do-โด” หมายถึง วิถีหรือหนทาง “Jo-โจ” หมายถึงสถานที่ เมื่อรวมกันแล้วหมายถึง สถานที่ซึ่งเป็นที่ฝึกวีถีต่างๆเช่น โรงฝึกวิชาศิลปะการป้องกันตัว

“Coding Dojo” จึงหมายถึง “กระบวนการพัฒนาทักษะในการเขียนโปรแกรม” ไม่ว่าจะเป็นศิลปะการต่อสู้และการเขียนโปรแกรม ความชำนาญและความรวดเร็วจะขึ้นอยู่กับการฝึกฝน ซึ่งใช้แนวทางปฏิบัติที่คล้ายกัน นั่นคือเราจะฝึกฝนและพัฒนาซ้ำแล้วซ้ำเล่าจนกว่าเราจะเรียนรู้และเข้าใจในกระบวนท่าหรือการเขียนโปรแกรมนั้นๆ ได้อย่างถ่องแท้ อีกทั้งยังเป็นการปรับพื้นฐานและความรู้ของทุกคนในทีมให้อยู่ในระดับเดียวกันอีกด้วย

รูปแบบการฝึกแบ่งออกได้ 3 แบบ ดังนี้

1. Kata (คาตะ) == การฝึกฝนทักษะที่สำคัญอย่างสม่ำเสมอ

🎯 เป้าหมายของการทำ Kata คือ การฝึกฝนทักษะที่สำคัญอย่างสม่ำเสมอ โดยซ้อมการแก้ปัญหา โดยที่ไม่ได้เน้นการแก้ปัญหาที่ยากแต่เน้นการเข้าใจถึงขั้นตอนการคิดและเขียนโปรแกรม เพื่อให้เราสามารถแก้ปัญหาได้เมื่อเผชิญกับการเขียนโปรแกรมจริง

2. Wasa (วาสะ) == เทคนิค ลีลา ชั้นเชิง ซึ่ง Wasa เปรียบเสมือนเป็นการฝึก Kata แบบเป็นคู่ เช่น คนนึงเขียน Unit test แล้วให้อีกหนึ่งคนเขียนโปรแกรมและมีการสลับบทบาทและหน้าที่กันไปมา

🎯 เป้าหมายของการทำ Wasa คือ เน้นการเรียนรู้และวิเคราะห์การฝึกฝนรวมถึงแนวคิดของแต่ละคน

3. Randori (รันโดริ) == การฝึกซ้อมจริง เปรียบเทียบกับการต่อสู่อย่างอิสระที่มีการจำลองสนามจริงที่มีผู้เล่นหลายคนและมีการเปลี่ยนกฎกติกาไปเรื่อยๆ

🎯 เป้าหมายของการทำ Randori คือ เน้นบรรยากาศการฝึกฝนที่สนุกสนานและได้เรียนรู้แนวคิดที่หลากหลายมากขึ้นในการแก้ปัญหาต่างๆ

ก่อนอื่นจะต้องทำการเลือกและโหวตสำหรับเนื้อหาหรือโปรแกรมที่ทุกคนเห็นสมควรว่าควรจะฝึกฝนร่วมกันเสียก่อน

เรามีการจัดกลุ่มของหัวข้อและทำการโหวต แต่ละคนสามารถโหวตได้จำนวน 3 โหวต และจากผลการโหวต โปรแกรมที่มีจำนวนโหวตเป็นอันดับ 1 ได้แก่ Postman

สัปดาห์นี้เราได้ทำการส่งมอบไฟล์ Stubs และ Postman ให้กับ QA ของทีมพัฒนา ถือเป็นอันเสร็จสิ้นภารกิจ

สรุปสิ่งที่ได้รับหลังจากการเข้าร่วมโปรเจคนี้

• เห็นถึงความแตกต่างระหว่างการทำงานแบบ Online และ On Site อย่างชัดเจน ส่วนตัวแล้วชอบการทำงานแบบ On Site มากกว่า เนื่องจากได้ทักษะและประสบการณ์มากมายที่หาไม่ได้ง่ายๆ ไม่ว่าจะเป็นทักษะการวิเคราะห์ธุรกิจการเงินการธนาคารที่มีความละเอียดมาก หรือจะเป็นเทคนิคการสื่อสาร/การตั้งคำถามที่ดี/การจับจังหวะ/การทำงานร่วมกับคนหมู่มาก เป็นต้น
• เห็นถึงความแตกต่างระหว่างการทำงานของ QA หรือ Tester บริษัทอื่นและบริษัทเรา คือ ที่อื่นยังวิเคราะห์และออกแบบ Test Case และ Test Scenarios จากหน้าจอ UI ซึ่งหน้าจอจะมีการเปลี่ยนแปลงและแก้ไขอยู่ตลอดเวลา ส่งผลให้เกิดความไม่แน่นอนและต้องแก้ไขตามหน้าจออยู่เสมอ แต่หากเราเปลี่ยนเป็นการออกแบบและวิเคราะห์จากเงื่อนไขของระบบหรือธุรกิจแทน ซึ่ง Work Flow จะมีความคงที่อยู่แล้ว ทำให้เราไม่ได้รับผลกระทบจากการเปลี่ยนแปลงรูปแบบหรือส่วนประกอบต่างๆ บนหน้าจอและไม่ต้องแก้ไขงานซ้ำๆ วนๆ อีกเช่นเดิม
• ทีมพัฒนาส่วนใหญ่ยังให้ความสำคัญกับการออกแบบและวิเคราะห์ Test Case ก่อนขั้นตอนการพัฒนาระบบอยู่น้อยหรือเรียกว่า ยังไม่เห็นความสำคัญของการ Test Fisrt สักเท่าไหร่ เนื่องจากปกติแล้วทุกคนจะเข้าใจบริบทและการทำงานของ Tester หรือ QA ว่าจะต้องรอทดสอบก็ต่อเมื่อระบบหรือโปรเจคถูกพัฒนาเสร็จแล้ว (Test Last) ซึ่งวิธีนี้เสี่ยงต่อการเกิดความผิดพลาดสูง ดังนั้นจึงขอสนับสนุนให้ทุกคนนั้นหันมาใช้วิธี Test First เพื่อเป็นการป้องกันการเกิดข้อผิดพลาดและไม่ต้องเหนื่อยหา Defects ในภายหลัง ซึ่งพ่วงมาด้วยการใช้เวลาในการหา Root Causes และ Debugs ที่เพิ่มขึ้นด้วย

Photo by Nathan Dumlao on Unsplash

หวังว่า ความรู้และมุมมองที่ได้จากการทำงานนี้จะเป็นประโยชน์ต่อทุกท่านไม่มากก็น้อย (แพทเทิร์นการเขียนคำนำรายงานสุดๆ 5555)

ค่ำคืนนี้ขอบคุณและราตรีสวัสดิ์ค่ะ 🌙