#priwreadbooks Agile Coaching — Chapter 10 — Driving Development with Tests (สรุป)

Photo by Alvaro Reyes on Unsplash

Previous chapter:

• Chapter 1 — Starting the Journey
• Chapter 2 — Working with People
• Chapter 3 — Leading Change
• Chapter 4 — Building an Agile Team
• Chapter 5 — Daily Standup
• Chapter 6 — Understanding What to Build
• Chapter 7 — Planning Ahead
• Chapter 8 — Keeping It Visible
• Chapter 9 — Getting to “Done”

ตรวจสอบให้แน่ใจว่าโค้ดผ่านการทดสอบอัตโนมัติ

เราพบกับทีมจำนวนมากที่บอกว่าพวกเขาเป็น Agile แต่ก็ยังต้องพึ่งพาการทดสอบด้วยตนเองเป็นอย่างมาก นักพัฒนาโยนซอฟต์แวร์ให้ผู้ทดสอบพบปัญหา จากนั้นผู้ทดสอบจะตีกลับอีกครั้งพร้อมรายงานข้อบกพร่องมากมาย วันเวลาผ่านไปในขณะที่นักพัฒนาและผู้ทดสอบทำงานกันเป็นวงกลม พยายามพัฒนาซอฟต์แวร์จนกว่าจะดีพอที่จะส่งมอบ

กระตุ้นให้ทีมลดความเครียดนี้โดยการทำ Test-Driven Development ทีมสามารถใช้การทดสอบอัตโนมัติเพื่อดูว่าโค้ดใช้งานได้หรือไม่ โดยใช้เวลาเป็นนาทีแทนที่จะเป็นชั่วโมงหรือเป็นวัน นักพัฒนาสามารถมั่นใจได้ว่าพวกเขากำลังสร้างรากฐานที่มั่นคง และผู้ทดสอบสามารถมุ่งเน้นไปที่กรณีที่เป็น edge cases แทนที่จะเสียเวลากับปัญหาเล็กน้อย

ซึ่งการนำ TDD มาใช้ จำเป็นต้องแก้ปัญหาทางเทคนิค การพัฒนาส่วนบุคคล และการทำงานเป็นทีม

Test-Driven Development (TDD)

นักพัฒนาซอฟต์แวร์จะเริ่มต้นด้วยการเขียนการทดสอบโค้ดที่ต้องการเขียน ทำการทดสอบเพื่อตรวจสอบว่าล้มเหลวจริงๆ เขียนโค้ดขั้นต่ำเพื่อให้ผ่านการทดสอบ หลังจากผ่านการทดสอบใหม่แต่ละครั้ง มองหาโอกาสในการรวบรวมโค้ดและขจัดความซ้ำซ้อน สร้างโค้ดโดยทำซ้ำขั้นตอนเหล่านี้

การพัฒนาโค้ดด้วยวิธีนี้กระตุ้นให้นักพัฒนาคิดเกี่ยวกับการแก้ปัญหาทีละเล็กทีละน้อย นอกจากนี้ยังช่วยให้นักพัฒนาทำงานจากภายนอกสู่ภายในมากขึ้น พวกเขาพิจารณาส่วนต่อประสานของโค้ดก่อน การใช้ TDD ทำให้นักพัฒนาสามารถตัดสินใจเกี่ยวกับการออกแบบเล็กๆ น้อยๆ ได้ตลอดเวลา บางครั้งจึงเรียกว่าการออกแบบที่ขับเคลื่อนด้วยการทดสอบ (test-driven design)

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

หากทีมกำลังเริ่มต้นในโครงการใหม่ ทีมนั้นสามารถกระโดดเข้าสู่ TDD เต็มรูปแบบได้ทันที ส่วนทีมอื่นๆ ส่วนใหญ่ที่มีโค้ดอยู่แล้วแต่ยังไม่มีการทดสอบอัตโนมัติ ความท้าทายแรกคือการหาวิธีรวมการทดสอบอัตโนมัติเข้ากับโค้ดดั้งเดิม ให้สมาชิกในทีมเริ่มเขียนการทดสอบอัตโนมัติ 2–3 รายการต่อวันก่อนที่จะพยายามขับเคลื่อนโค้ดด้วยการทดสอบ สิ่งนี้ทำให้พวกเขามีเวลาสร้างทักษะและโครงสร้างพื้นฐานในการทดสอบก่อนที่จะพยายามทำงานแบบ test-first

ใช้เวลาทำงานร่วมกับทีมเพื่อทำความเข้าใจสถานะที่แท้จริงของโค้ด ระดับประสบการณ์ของสมาชิกในทีม และความสนใจของแต่ละคนในการเปลี่ยนแปลงวิธีการทำงาน สามารถใช้ PrOpER เพื่อขจัดอุปสรรคในการนำ TDD ไปใช้

ความท้าทายทั่วไปบางประการที่คุณอาจพบ

• เมื่อคุณแนะนำ TDD ให้กับทีม ไม่ใช่แค่ความท้าทายทางเทคนิคเท่านั้นที่คุณต้องแก้ไข มีความท้าทายของมนุษย์ด้วย
• “ทีม” ไม่ได้ทำงานเป็นทีม พวกเขาทำงานในส่วนต่างๆ ของโค้ดด้วยแนวคิดที่แตกต่างกันมากเกี่ยวกับวิธีเขียนการทดสอบ ไม่มีใครทำการทดสอบที่เขียนโดยคนอื่น พวกเขาใช้ IDE ที่แตกต่างกัน ไม่มีการยอมใช้ TDD หรือสิ่งที่มีความหมายสำหรับทีม

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

ผู้เขียนค้นพบในภายหลังว่าเหตุผลที่ผู้จัดการฝ่ายพัฒนาต้องการให้ทีมนำ TDD มาใช้ก็เพราะผู้ทดสอบในโครงการมีมากเกินไป พวกเขาพบปัญหาเล็กน้อยเกี่ยวกับโค้ด ซึ่งอาจป้องกันได้โดยนักพัฒนาที่ทำการทดสอบโค้ดพื้นฐานของตนเอง แต่ผู้จัดการทีมล้มเหลวในการสื่อสารกับทีม ทีมจำเป็นต้องฟังเรื่องนี้จากเขาเพื่อทำความเข้าใจว่าเหตุใดพวกเขาจึงเข้ารับการฝึกอบรมและฝึกสอนใน TDD และให้เหตุผลบางอย่างแก่พวกเขาในการเปลี่ยนแปลง

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

รวมทีมเข้าด้วยกันเพื่อสร้างข้อตกลงเกี่ยวกับสิ่งที่พวกเขาสามารถกระทำได้ ระบุตัวขัดขวาง ขอแนวคิดในการแก้ไข ใช้การไล่ระดับของข้อตกลงเพื่อพิจารณาว่าการดำเนินการใดที่ทีมมีแรงที่จะทำก่อน

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

แนะนำพวกเขาให้รับการอบรมเมื่อพวกเขาเริ่มต้น อย่างไรก็ตาม หากไม่มีงบประมาณสำหรับการฝึกอบรม (หรือไม่มีหลักสูตรฝึกอบรมในภาษาโปรแกรมที่ใช้) ทีมจำเป็นต้องสอนตนเองถึงวิธีการเขียนแบบทดสอบอัตโนมัติ ช่วยพวกเขาตั้ง Coding dojo การเขียนโค้ดเป็นประจำเพื่อพัฒนาทักษะการเขียนแบบทดสอบ

ตอนที่พวกเขากำลังวางแผน เตือนทีมให้เผื่อเวลาในการเรียนรู้การเขียนแบบทดสอบอัตโนมัติ ทีมควรแจ้งให้ลูกค้าทราบล่วงหน้าว่าความเร็วของทีมมีแนวโน้มที่จะลดลงในขณะที่พวกเขาอยู่ในช่วงการเรียนรู้นี้

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

Coding Dojo

คือการนำนักพัฒนามารวมตัวกันเพื่อทำงานในความท้าทายด้านการเขียนโปรแกรมที่เตรียมไว้ แนวทางนี้ได้รับแรงบันดาลใจจาก code kata ของ Dave Thomas

การเลือกความท้าทายล่วงหน้าช่วยให้ผู้เข้าร่วมสามารถเตรียมตัวสำหรับโดโจได้

โดโจเริ่มต้นด้วยนักพัฒนาสองคนทำงานที่คอมพิวเตอร์ที่หน้าห้อง คอมพิวเตอร์เชื่อมต่อกับโปรเจ็กเตอร์เพื่อให้ทุกคนเห็นโค้ดขณะที่กำลังเขียน

ในขณะที่นักพัฒนาทำงาน พวกเขาพูดออกมาดังๆ เพื่ออธิบายสิ่งที่พวกเขากำลังทำอยู่และให้ความเห็นเกี่ยวกับวิธีการแก้ปัญหา หากกลุ่มไม่สามารถตามทัน ทั้งคู่จะต้องหยุดชั่วคราวเพื่ออธิบาย เพื่อให้ทุกคนมีส่วนร่วม ครึ่งหนึ่งของทั้งคู่จะถูกสลับออกทุกๆ ห้านาที แทนที่ด้วยหนึ่งในนักพัฒนาในห้อง และดำเนินต่อไปประมาณหนึ่งชั่วโมง สิ่งนี้ทำให้ทุกคนสามารถแสดงวิธีแก้ปัญหาการเขียนโค้ดได้

ตัวอย่าง http://codingdojo.org/ http://codekata.com/

ตกลงกลยุทธ์การทดสอบกับทีม

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

Unit Test Rules by Michael Feathers, Object Mentor

ผู้เขียนใช้กฎเหล่านี้กับทีมจำนวนมาก พวกเขาส่งเสริมการออกแบบที่ดีและข้อเสนอแนะอย่างรวดเร็ว และดูเหมือนว่าพวกเขาจะช่วยให้ทีมหลีกเลี่ยงปัญหามากมาย

การทดสอบจะไม่ใช่ Unit Test เมื่อ

• คุยกับฐานข้อมูล
• สื่อสารผ่านเครือข่าย
• สัมผัสกับระบบไฟล์
• ไม่สามารถทำงานได้อย่างถูกต้องในเวลาเดียวกันกับการทดสอบหน่วยอื่นๆ ของคุณ
• คุณต้องทำสิ่งพิเศษกับสภาพแวดล้อมของคุณ (เช่น แก้ไขไฟล์ปรับแต่ง) เพื่อเรียกใช้งาน

การทดสอบสิ่งเหล่านี้ไม่ใช่เรื่องแย่ สามารถเขียนได้ใน unit test อย่างไรก็ตามสิ่งสำคัญคือ ต้องสามารถแยกสิ่งเหล่านี้ออกจากการทดสอบ unit test จริง เมื่อใดก็ตามที่เราทำการเปลี่ยนแปลง เราสามารถทดสอบได้อย่างรวดเร็ว

เริ่มต้นด้วยกฎพื้นฐาน

พวกเขาจะเขียนการทดสอบโค้ดใหม่และการเปลี่ยนแปลงโค้ดที่มีอยู่ หารือเกี่ยวกับแนวทางนี้กับทีม และตรวจสอบว่าพวกเขายินดีที่จะทำสิ่งนี้ หากการทำตามกฎนี้มากเกินไป ให้ทำงานร่วมกับพวกเขาเพื่อตกลงเป้าหมายในการเขียนแบบทดสอบ 2–3 ข้อทุกวันเพื่อให้มีความคืบหน้าเล็กน้อย แจ้งให้ทีมทราบอย่างชัดเจนว่าการทดสอบเหล่านี้จะมีประโยชน์มากที่สุดหากครอบคลุมเส้นทางที่อาจล้มเหลว (พังหรือบั๊ก)

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

Continuous Integration (CI)

คุณอาจพบว่านักพัฒนาคุ้นเคยกับการทำงานแยกกัน ตรวจสอบโค้ดทุกๆ 2–3 วัน พวกเขาชะลอการรวมโค้ดเพราะใช้เวลานาน แต่ในขณะที่พวกเขาเลื่อนการรวมออกไป ยิ่งทิ้งระยะมากเท่าไหร่ การผสานโค้ดกันก็ยิ่งยากขึ้นเท่านั้น

การผสานรวมอย่างต่อเนื่อง (CI) เป็นการผสานรวมการเปลี่ยนแปลงโค้ดตั้งแต่เนิ่นๆ และบ่อยครั้ง การรวมแต่ละรายการมีขนาดเล็ก ด้วยวิธีนี้ โค้ดชิ้นเล็กๆ จากทั้งทีมล่าสุดจะพร้อมใช้งาน แทนที่จะเป็นก้อนใหญ่ก้อนเดียว

CI เชื่อมต่อกับการทำ TDD เพราะการทดสอบควรผ่านสำหรับโค้ดรวมทั้งหมด ไม่ใช่แค่ในคอมพิวเตอร์ของนักพัฒนาเท่านั้น ดังนั้น CI จึงไม่ใช่แค่การรวมโค้ดบ่อยๆ แต่การทดสอบทั้งหมดควรผ่านตลอดเวลาเช่นกัน

ดังที่เจมส์ ชอร์กล่าวไว้

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

เมื่อแนะนำ CI ให้กับทีม แนะนำให้พวกเขาเริ่มต้นด้วยการทำตามกระบวนการ CI แบบ synchronous (จังหวะเดียวกัน) ทุกครั้งที่นักพัฒนาตรวจสอบโค้ด พวกเขารันบิลด์และรอดูว่าการทดสอบทั้งหมดผ่านหรือไม่ก่อนที่จะดำเนินการพัฒนาโค้ดเพิ่มเติม หากการทดสอบไม่ผ่าน ผู้พัฒนาจำเป็นต้องแก้ไขปัญหา นักพัฒนาจำเป็นต้องหลีกเลี่ยงการเหยียบย่ำซึ่งกันและกันโดยพยายามผสานรวมการเปลี่ยนแปลงในเวลาเดียวกัน

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

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

กุญแจสำคัญคือ การปรับปรุงข้อเสนอแนะเกี่ยวกับสถานะการสร้าง เพื่อให้ทีมทราบโดยเร็วที่สุดว่าการสร้างใหม่เสียหายหรือไม่

หากทีมใช้เซิร์ฟเวอร์ CI ในการสร้างและแจ้งผลการทดสอบ นักพัฒนาเพียงตรวจสอบโค้ดของพวกเขาและดำเนินการต่อ เรื่องสำคัญคือทุกคนในทีมต้องได้รับการแจ้งเตือนเมื่อการสร้างเสีย เนื่องจากการเช็คอินครั้งล่าสุดอาจทำให้การทดสอบล้มเหลว

Enhancing the Build Page โดย Ivan Moore

เราเคยประสบปัญหางานที่สร้างพังโดยไม่มีใครรับผิดชอบซ่อม มีคนดัดแปลงเครื่องมือ CI ของเรา Build-o-matic เพื่อดูดข้อความคอมมิต ค้นหาชื่อหรือชื่อย่อของนักพัฒนา จับคู่กับรูปภาพเหล่านี้ และวางไว้ในหน้าผลลัพธ์

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

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

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

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบอย่างยั่งยืน

Ten-Minute Build

ทีมงานต้องการชุดทดสอบอัตโนมัติที่ทำงานได้อย่างรวดเร็ว มิฉะนั้น เมื่อการทดสอบใช้เวลานานในการดำเนินการ นักพัฒนาซอฟต์แวร์จะไม่รอให้การทดสอบผ่าน ให้ความสนใจกับเวลาที่ใช้ในการสร้างแอปพลิเคชันและเรียกใช้การทดสอบ เมื่อไรก็ตามที่เวลานี้เกินเกณฑ์สิบนาที ทีมจำเป็นต้องทุ่มเทเวลาเพื่อทำให้การทดสอบทำงานเร็วขึ้น

ผลกระทบของการทดสอบที่ทำงานช้า

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

ทีมงานไม่ได้พิจารณาว่าการผ่านการทดสอบการยอมรับนั้นเป็นส่วนหนึ่งของเรื่องราวของผู้ใช้ที่เสร็จสมบูรณ์หรือเป็นส่วนหนึ่งของคำจำกัดความของคำว่า “เสร็จสิ้น” เมื่อเวลาผ่านไป คุณภาพของโค้ดก็แย่ลงเรื่อยๆ เนื่องจากการทดสอบเริ่มล้มเหลวมากขึ้นเรื่อยๆ การทดสอบเพื่อการยอมรับไม่ได้เพิ่มคุณค่าใดๆ เพราะทำแล้วก็ไม่ผ่าน

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

วันหนึ่งมันแย่จนต้องทำอะไรซักอย่าง นักพัฒนาบางคนทำงานเพื่อแก้ไขการทดสอบที่เสียหาย ในขณะที่ทีมที่เหลือช่วยทีม QA ในการทดสอบผลิตภัณฑ์ จะไม่มีใครเพิ่มคุณสมบัติใหม่อีกจนกว่าการทดสอบที่มีอยู่จะผ่าน

การทดสอบได้รับการแก้ไขในวันนั้น อย่างไรก็ตามชุดการทดสอบยังคงทำงานช้า ดังนั้นในวันถัดไปการทดสอบจึงล้มเหลวอีกครั้ง และพวกเขายังคงพังทลายตลอดช่วงเวลาที่เหลือของโครงการ เมื่อเส้นตายใกล้เข้ามา ไม่มีใครรู้ว่าทีม “เสร็จ” ไปได้ไกลแค่ไหน

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

ทีมอาจต้องการการสนับสนุนและกำลังใจอย่างมากเพื่อขับเคลื่อนการพัฒนาด้วยการทดสอบ ระวังนักพัฒนาที่อ้างว่า “เป็นการเปลี่ยนแปลงเพียงบรรทัดเดียว” เพื่อเป็นข้ออ้างในการไม่เขียนแบบทดสอบ

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

ทำให้มองเห็น

ทีมที่ยังใหม่กับ TDD ให้ลองโพสต์จำนวนการทดสอบที่ผ่านและการทดสอบที่ล้มเหลวอย่างชัดเจนบนกระดานของทีม เราตรวจสอบตัวเลขใน daily standup เพื่อดูว่าทีมทำได้ดีเพียงใด สิ่งนี้ช่วยให้พวกเขานึกถึงการทดสอบ ทำสิ่งนี้เพียงหนึ่งเดือนหรือมากกว่านั้น จนกว่าทีมจะเก่งขึ้นและจดจำเพื่อให้แน่ใจว่าการทดสอบทั้งหมดผ่าน

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

อุปสรรคที่อาจเจอ

ไม่มีเครื่องมือทดสอบ

หากทีมพบว่าไม่มีเครื่องมือเชิงพาณิชย์หรือโอเพ่นซอร์สสำหรับการเขียนการทดสอบอัตโนมัติในภาษาการเขียนโปรแกรมที่พวกเขาใช้ มักจะเป็นไปได้ที่จะเขียนกรอบการทดสอบอัตโนมัติอย่างง่าย สนับสนุนให้พวกเขาพิจารณาการใช้เครื่องมือทดสอบของตนเอง

รักษาวินัยในการทดสอบครั้งแรก

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

หากนักพัฒนาในทีมคัดค้านอย่างมากกับการเขียนการทดสอบก่อน แต่เต็มใจที่จะเขียนการทดสอบอัตโนมัติ แนะนำให้ทีมอนุญาตให้ดำเนินการนี้ในช่วงทดลอง ตราบใดที่การทดสอบอัตโนมัติของเธอบรรลุผลการทดสอบในระดับที่ใกล้เคียงกับคนอื่นๆ ในทีม การทดสอบหลังการทำงานอาจเป็นไปได้ ระวังว่าวิธีการทำงานนี้สร้างปัญหาให้กับสมาชิกในทีมคนอื่นๆ หรือไม่ และนำเรื่องนี้มาคุยกันใน Retrospective

ทุกคนทำงานในสาขาของตนเอง

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

ประเด็นทั้งหมดของ CI คือการผสานรวมขนาดเล็กและบ่อยครั้งนั้นรวดเร็วและไม่เจ็บปวด และการยึดติดกับ CI ช่วยให้นักพัฒนาสามารถทำงานร่วมกันได้

หากคุณพบว่าทีมกำลังชะลอการผสานรวม เราขอแนะนำให้คุณหารือเกี่ยวกับปัญหาที่อาจเกิดขึ้นกับทีม กระตุ้นให้พวกเขาลองใช้ CI สักสองสามสัปดาห์และทบทวนกับทีมใน Retrospective