มีโอกาสไปงาน Agile Bangkok Meetup :: Embracing Agile
แน่นอนว่าเป้าหมายหลักอยู่ที่คุณ Janet Gregory
เป็นหนึ่งในคนเขียนหนังสือ Agile Testing และ More Agile Testing
มาดูกันว่ามีอะไรที่น่าสนใจบ้าง
บอกได้เลยว่า ยาวมาก ๆ
เริ่มต้นด้วย Panel discussion
คำถามหนึ่งที่มันติดหูมาก ๆ คือ
Why do we start Agile ?
เป็นคำถามที่ทรงพลังมาก ๆ
ลองถามตัวคุณเอง ทีม องค์กร ว่า นำ Agile มาใช้เพื่ออะไร ทำไม ?
ถ้าตอบว่า
- มันเป็นของใหม่
- แนวคิดใหม่
- เขาบอกว่ามันดี
บอกได้เลยว่า เพียงเริ่มก็ FAIL แล้ว
เหตุผลที่เรานำ Agile มาใช้เพราะว่า
เราต้องการสร้าง product ออกสู่ตลาดอย่างรวดเร็ว
และแน่นอนว่ามันต้องเป็นสิ่งที่ลูกค้าต้องการ
ถึงแม้ลูกค้าจะรู้ตัว หรือ ไม่รู้ตัวก็ตาม
อีกคำถาม คือ เรื่องของการ Scaling Agile ว่าทำอย่างไร ? ใช้ Framework อะไร ?
ทางคุณ Janet ตอบได้อย่างน่าสนใจ คือ
ก่อนอื่นต้องเปลี่ยน Mindset กล่าวคือ
ปรับเปลี่ยนวิธีการคิด และ การทำงานเป็นแบบ Whole Team Approach
คือทุกคนทำงานด้วยกัน ไม่ใช่ต่างคนต่างทำ
สิ่งที่สำคัญมาก ๆ
มันคือความท้าทายของฝ่าย management
เนื่องจากเป็นกลุ่มที่พยายามจะไม่ทำความเข้าใจอะไรเลย
รวมทั้งไม่ต้องการเปลี่ยนแปลง
ปัญหาที่ตามมา คือ คนกลุ่มนี้ต้องการ training มาก ๆ ครั้งแล้วครั้งเล่า
แต่กลับลืมว่า กลุ่มคนที่ต้อง training ให้มาก และ จำเป็นมาก ๆ คือ TEAM
จากนั้นเข้าสู่การพูดในหัวข้อ Pitfalls and Perils of Agile Testing
ทำการสรุป lesson learn 5 ข้อ
ที่ช่วยให้ทีมที่นำ Agile มาใช้ประสบความสำเร็จได้ง่ายขึ้น
โดยแต่ละข้อประกอบไปด้วย ปัญหา อาการ ความเสี่ยง และ แนะนำวิธีการแก้ไข
ทำความเข้าใจ Agile ก่อนดีไหม ?
และกลับไปถามตัวเองด้วยว่า นำ Agile มาใช้ทำไม ?
ต้องเข้าใจตัวเองก่อนเสมอนะครับ
Agile ว่าด้วยเรื่องของ
- การพัฒนาแบบ iterative และ incremental
- ทำงานร่วมกับลูกค้าอยู่อย่างสม่ำเสมอ
- ทำงานเป็นทีม (Whole team approach)
- ทุก ๆ feature ต้องถูกทดสอบอยู่อย่างสม่ำเสมอ
- ต้องทำการส่งมอบสิ่งที่มีคุณค่าต่อ business อยู่อย่างสม่ำเสมอ หรือช่วงเวลาเท่า ๆ กัน
- ทำการปรับปรุงขั้นตอนการทำงานจาก feedback ที่ได้รับอยู่อย่างสม่ำเสมอ
มันไม่ใช่ง่ายเลยนะ !!
คำถาม
เมื่อเกิดปัญหาขึ้นมา คุณทำการแก้ไข หรือ หาวิธีการแก้ไขกันอย่างไร ?
คำตอบ
ถามไงล่ะ เช่น ปัญหาจริง ๆ มันคืออะไร ?
บ้างก็ใช้ 5-Why
แต่แปลกนะ บ่อยครั้งมาก ๆ ที่เราแก้ไขผิดที่ผิดทาง
ดังนั้นเราควรทำ retrospective เพื่อหาปัญหา หรือ หาอาการ
เพื่อแก้ไขปัญหาให้มันถูกจุดต่อไป
มาดู Lesson Learn 5 ข้อกันดีกว่า
น่าจะทำให้เราเห็นปัญหา และ แก้ไขได้ตรงจุดมากขึ้น
1. Tester ต้องเข้ามาร่วมทำงานด้วยเสมอ
ปัญหาที่มักพบเจอ คือ
เราค้นพบปัญหาต่าง ๆ ช้ามาก ทำให้การแก้ไขก็ช้าตาม
มันคือเรื่องของ feedback ที่ช้านั่นเอง
บ่อยครั้งพบว่า
การทดสอบมักจะอยู่ช่วงท้าย ๆ ของทุกรอบการทำงาน (iteration)
หรือถ้าแย่มาก ๆ ก็ถูกยกไปทำการทดสอบในรอบการทำงานถัดไป
แน่นอนว่า การแก้ไขมันก็ช้าตามไปด้วย
อาการที่พบได้ปกติ
- Tester ไม่รู้ว่าตัวเองจะทดสอบอะไร
- Story มันไม่เสร็จ หรือ DONE เลย
- ได้ผลการทดสอบมันช้ามาก ๆ
- มีการพูดว่า งานนั้นของฉัน งานนั้นของเรา
สิ่งที่น่าสนใจมาก ๆ คือ มีการกำหนด Done-Done
ซึ่งส่วนใหญ่มันหมายถึง
- Done ของ developer
- Done ของ Tester
แต่โดยรวมแล้วมันไม่เคย Done เลย !!
มันบ่งบอกว่า ภายในทีมมีการแบ่งเป็นทีมย่อย ๆ ซึ่งเป็นความเสี่ยงอย่างมาก
สุดท้ายมันส่งผลต่อ เวลาการส่งมอบอย่างแน่นอน
คำแนะนำ เพื่อแก้ไข ประกอบไปด้วย
ให้ทำงานเป็นทีม (Whole team approach)
นั่นคือทุกคนในทีมช่วยกันรับผิดชอบ
ทีมตกลงร่วมกันในเรื่องของการทดสอบ และ เรื่องของคุณภาพ
โดยทาง Tester นั้นต้องเข้าร่วมตั้งแต่การวางแผน และ สรุป requirement
ทำให้ทุก ๆ คนสามารถทำงานใด ๆ ก็ได้
Developer ควรใช้วิธีการเพื่อให้ได้มาซึ่ง feedback ในการทดสอบที่รวดเร็ว
เช่น Test-Driven Development (TDD) เป็นต้น
ในแต่ละ Story จะต้องมีงานสำหรับการทดสอบด้วยเสมอ
ให้การการ pair programming ระหว่าง developer และ tester เลย
เพื่อแบ่งปันความรู้ และ ประสบการณ์การทำงานกัน
สุดท้ายใคร ๆ ก็สามารถทำการทดสอบได้
2. ปรับเปลี่ยน Mindset ซะ
บ่อยครั้งพบว่า Agile team นั้นยังยึดติดกับ Role และ หน้าที่ความรับผิดชอบแบบเดิม
นั่นคือ หน้าที่ของตำแหน่งฉันเป็นแบบนี้ ฉันไม่สนใจใครหรอกนะ !!
หรือทำงานแบบ SILO นั่นเอง
อาการที่พบได้ปกติ
- Bug ทุกตัวเก็บไว้ใน Defect Tracking System (DTS)
- มีทีม Tester แยกกออกมาอย่างชัดเจน
- ทีม Tester มีอำนาจในการสั่งหยุด หรือ ห้ามการ deploy บน production ได้
สิ่งเหล่านี้มันเกิดมาจาก
ไม่มีใครเชื่อในแนวคิด Build Quality In เลย
รวมทั้งทำการพูดคุยผ่านระบบ DTS
ยังไม่พอนะ ทาง developer และ tester ต่างมีกรอบการทำงานของตัวเองอีก
คำแนะนำ เพื่อแก้ไข ประกอบไปด้วย
- ให้ทำการปรับเปลี่ยนแนวคิดว่า QA คือ Question Asker ซะ
- ให้ทำการแบบ pair กับ developer
- ให้ทำการแนะนำการทดสอบกับทาง developer
- ให้ทำการแบ่งปันประสบการณ์กับทาง developer
แล้วการทำงานจะดีขึ้นมากมาย
คำว่า DONE หมายถึง ผ่านการทดสอบด้วยเสมอ
ที่สำคัญให้จำไว้ว่า
Testing is not a phase, Testing is activity
ดังนั้นการทดสอบจึงเกิดขึ้นอยู่ตลอดเวลา และ ใคร ๆ ก็ทดสอบได้
และควรทำให้ทุก ๆ คนเห็นผลของการทดสอบด้วย
สิ่งที่ผมชอบมาก ๆ คือ
ลองให้ทาง Developer และ Tester ทำ Manual Regression Testing ในทุก ๆ story สิ
แล้วจะพบว่า ทุก ๆ คนจะเริ่มถามหา Automated Testing !!
แต่ถ้ายังทนไหว ก็ปล่อยไป …
3. เรียนรู้ Business Domain ซะ
ปัญหาที่มักพบเจอ สำหรับทีม คือ
ไม่รู้เกี่ยวกับ business domain ที่ตนเองกำลังทำอยู่
แปลกดีไหมล่ะ ?
ถ้าคุณไม่รู้และเข้าใจ business domain แล้ว
คุณก็ไม่มีทางเข้าใจ requirement
ดังนั้นคุณก็ไม่รู้ว่าจะต้องถาม หรือ ตั้งคำถามอะไร
ส่งผลต่อสิ่งที่คุณออกแบบ พัฒนา ทดสอบ และ ส่งมอบ
ทุกอย่างก็จะผิดจากความต้องการของลูกค้าไปหมดเลย !!
หรือกว่าจะรู้ว่า ถูก เป็นอย่างไร มันก็สายไปเสียแล้ว
ผมชอบรูปนี้เป็นอย่างมาก มันอธิบายได้ดีจริง ๆ
อาการที่พบได้ปกติ
Bug ที่เกิดจาก requirement ดันไปเจอบน production
Bug มันไม่ใช่ปัญหาที่แท้จริง
แต่มันกลับเป็นเรื่องความผิดพลาดของ data test และ คน
ทีมใช้เวลานานมาก ๆ เพื่อทำความเข้าใจ Bug นั่นคือการแก้ไขก็ล่าช้า
คำแนะนำ เพื่อแก้ไข ประกอบไปด้วย
- ทำการแตก story ออกมาให้มันเล็ก ๆ สิ ให้มันสามารถทดสอบได้ง่าย
- ข้อมูลที่ใช้ในการทดสอบ ควรเป็นข้อมูลจริง ๆ ไม่ใช่พวก asdsfgafgafg ฟหกดเ้
- ต้องส่งสิ่งที่จะทดสอบให้ทาง developer ตั้งแต่เนิ่น ๆ เลย อย่ารอช้า
- ให้ถามกันว่าในตอนนี้เรากำลังแก้ไขปัญหาอะไร ? เพื่อจะได้ช่วยเหลือกันได้
- ถ้าไม่เข้าใจ business domain ภาพใหญ่ ก็ให้แบ่งบางเรื่องมาเรียนรู้กันสิ
- ให้พูดคุยกันด้วยรูปภาพ เพื่อให้เข้าใจตรงกัน อย่าพูดกันแบบลอยบนอากาศ
และแนวคิดที่ดีมาก ๆ คือ ATDD (Acceptance Test-Driven Development)
มันไม่ใช่ best practice แต่มันคือแนวทางหนึ่งที่ดี
มีขั้นตอนการทำงานดังรูป
4. ทำความเข้าใจกับภาพรวมของระบบซะ (Understand Big Picture)
เมื่อคุณไม่รู้ว่าภาพรวมของระบบเป็นอย่างไร ?
อาการที่มักพบเจอ คือ
- ทดสอบในส่วนของตัวเอง หรือ ในส่วนที่ทีมรับผิดชอบเท่านั้น
- ปัญหาระดับ integration testing เยอะมาก ๆ แต่กลับรู้ปัญหาช้าซะงั้น
- ทำการทดสอบตามที่ developer พัฒนาขึ้นมาเท่านั้น
อาการเหล่านี้คือ ต้นตอของปัญหา
ส่งผลต่อขั้นตอนการทำงานของระบบ
บ่อยครั้งมักจะทำการเปลี่ยนแปลงเป้าหมายระหว่างการพัฒนา
ทำให้สุดท้าย ผลลัพธ์ไม่เป็นไปตามที่ฝั่ง business ต้องการอีก
มันน่ากลัวอย่างมากมาย !!
ดังนั้นแนะนำให้
เริ่มที่จากการปรับเปลี่ยนแนวคิดก่อน
ซึ่งมีลำดับดังรูป
จากนั้นให้ทำการกำหนดสิว่า แต่ละส่วนจะเสร็จ หรือ DONE
ด้วยเงื่อนไขอะไร อย่างไรบ้าง เช่น
คำว่า Feature นี้มันเสร็จแล้ว น่าจะต้องประกอบไปด้วย
- Feature done คือ ต้องผ่านการทดสอบตาม Agile Testing Quadrant 3 และ 4 เช่น UAT, Exploratory, Performance และ Security testing เป็นต้น
- ทุก ๆ story ของ feature จะต้อง done คือ ต้องผ่านการทดสอบตาม Agile Testing Quadrant 1 และ 2 เช่น Unit, Integration และ Automated Acceptance testing เป็นต้น
5. Automate as you can
ความผิดปกติที่มักเกิดขึ้น คือ ระบบต้องทำงานแบบอัตโนมัติ 100%
การทดสอบก็เช่นกัน !!!
แต่เดี๋ยวก่อนนะ อะไรที่มันไม่สามารถทำแบบอัตโนมัติได้ ก็อย่าไปฝืนมันเลยนะ
You can not Automate anything .
Automate as you can
แต่สิ่งที่แปลกกว่า คือ ทีมส่วนใหญ่ยังทำงานแบบ Manual กันอยู่เลย !!
อาการที่มักพบเจอ
- ถ้าใช้ Scrum จะพบว่าเมื่อจบ Sprint แล้วไม่มีของส่ง หรือ Potentially Shippable Product
- ไม่มีใครบอกได้เลยว่า สิ่งที่สร้างขึ้นมามันกระทบระบบการทำงานเดิมหรือไม่
- ไม่ทำ regression testing ทุกวัน … น่าจะทำ manual testing อยู่มั้ง !!
- วัน ๆ Tester ทำแต่การทดสอบ และ retest
- Bug เดิม ๆ มันกลับมาอยู่อย่างเสมอ
- ไม่มีการทำ Exploratory testing เลย
ส่งผลให้เกิดปัญหา และ ความเสี่ยง เช่น
จมอยู่กับการทดสอบ แถมงานไม่คืบหน้าไหนอีก
ส่วนใหญ่จะต้องขอเวลาในการทดสอบเพิ่ม !!
ยังไม่พอนะ
ความผิดพลาดจากคน มันมีตลอดเวลา
และมากขึ้นตามความกดดัน และ ปริมาณ
อีกอย่าง คือ
ทีมไม่มีการเรียนรู้ technology ใหม่ ๆ
เพื่อมาช่วยเหลือ และ แก้ไข ปัญหาที่ตนเองเผชิญอยู่เลย
หรือว่าไม่รู้ว่ามีปัญหากันแน่ ?
ดังนั้นลองแก้ไขแบบนี้ก่อนดีไหม ?
- แบ่งปัญหาใหญ่ ๆ ออกเป็นปัญหาย่อย ๆ เพื่อทำให้แก้ไขได้ง่าย
- อะไรที่มักจะทำซ้ำ ๆ ก็ให้มันทำงานแบบอัตโนมัติซะ
- ในการออกแบบที่ดี คือ ทำให้สามารถทดสอบได้ง่าย ลองกลับไปดูว่าระบบคุณทดสอบได้ง่ายไหม
- ในการประเมินเวลาการทำงานของแต่ละ story ก็ให้เพิ่มเวลาการทำ automated ไปด้วย
- ให้ทำการเลือกเครื่องมือที่ทุกคนในทีมสามารถทำงานร่วมกันได้ ไม่ใช่เลือกในสิ่งที่เราชอบหรือเข้าใจคนเดียว มิเช่นนั้นจะเกิดปัญหาเดิม ๆ ตามมาอีก
การสร้าง Automated Testing นั้น
ให้ปฏิบัติตามแนวคิดของ Pyramid Testing เลย ดังรูป
สิ่งที่สำคัญมาก ๆ อีกอย่างคือ ควรให้เวลาในการทำ Exploratory Testing ด้วยล่ะ
มันคือการทดสอบในแบบนี้คุณไม่คาดคิด คาดฝัน
มันคือการเดินทางตาม workflow ในรูปแบบที่ต่างออกไป
มันคือการ hack ระบบงาน
มันคือการใช้ persona เพื่อกำหนดพฤติกรรมการทำงานของกลุ่มผู้ใช้งาน
มันคือการค้นหาความเสี่ยงในรูปแบบต่าง ๆ
ดังนั้น ต้องมีเวลามาทดสอบกันด้วยนะ
โดยรวมแล้ว
- มันคือการสร้าง Trust หรือ ความเชื่อมั่นระหว่างทีม และ ลูกค้า
- แสดงความคืบหน้าต่าง ๆ ของการทำงานความชัดเจน ทุกคนเห็น ไม่ปิดบังหรือซ่อนปัญหาไว้
- ทำงานกันเป็นทีม
- ให้ความเคารพซึ่งกันและกัน
- หลีกเลี่ยงการทำงานแบบ SILO และ functional team
- ให้พยายาม Build Quality In อยู่อย่างเสมอ
- สุดท้ายก็คือ ต้องทำด้วยความสนุก ( Fun and Enjoy )
ปิดท้ายด้วย
Testing in agile project is not easy.
But Let’s try to do and journey to find your way
ขอบคุณสำหรับงาน Meetup ดีๆ ครับ
มีเรื่องต้องกลับมาคิด มาทำ และ ปรับปรุงอีกมากมาย
